Using Shared Resources

When creating a Carmenta Engine based application, it is quite common to use multiple different Views. For example, switching between a 2D view, a 3D view, or a vertical profile view. Multiple views could also display the same region side-by-side.

In these scenarios, it is practical to reuse shared data in all views to avoid storing multiple copies of the same data in memory.

This article presents tools used to create shared public objects that can be used by multiple different configuration files and only exist as a single instance in memory. We call these shared resources.

This archive contains the solution to the practical example described in this article.

Setting up shared resources

To enabled shared resources, you must first create a PX file that will hold all the shared resources. Inside this PX file, click on the background part of the workspace to open the configuration settings. Here, check the Shared tick box.

Any resources that are placed in this PX file will need to be made public.

To use the resources in a different configuration, open both configurations and then drag and drop (using right click) the resources from the shared resources file into the appropriate location in the main file. Be sure to select Create Reference Here from the multiple choice dialog. You can repeat this process to use the same resource in other configurations too.

Practical example: Lake Tahoe – 2D vs 3D

When creating shared resources, remember that Carmenta Engine uses relative paths, having all the files in the same directory helps a ton.

In this scenario we have two maps, one in 3D and one in 2D. The maps will display Lake Tahoe, Sierra Nevada, USA. The goal is to share as much data as possible between the two views in order to minimize memory usage and increase performance. To follow along, the two sample configurations, 3d_tahoe.px and line_of_sight.px, are included in the Carmenta Engine SDK.

The 3D map visualizes the region using elevation data while the 2D map uses the same elevation data to calculate a line-of-sight viewshed. These elevations are data that can be shared between the two views. In addition to that, we can also share the land cover raster data which is present in both configurations.

Preparations

We start by placing both configurations in the same folder, then we create a subfolder called SharedResources. Inside this folder, we generate a new PX file with the name Shared.px.

Into Shared.px, we move the two ReadOperators of interest, Elevation and LandCover.

Sharing the resources

Next, we follow the steps already mentioned. First, we click on the background of the PX file to access the configuration settings window. There we check the Shared tick box. On each of the ReadOperators, we check the Public tick box. Now we have correctly setup Shared.px.

To finish up, we open up Shared.px file together with the two other PX files.

Hint: You can quickly view all open configurations at once using these buttons in Carmenta Studio:

Drag and drop (using right click) the shared ReadOperators to the appropriate locations and select Create Reference Here.

The end result could look something like this:

Now we can view the PX files individually in Carmenta Explorer and compare memory usage etc. Only one instance of the data should exist in memory and is defined in the Shared.px file, also simplifying future updates.

Conclusion

Using shared resources is practical for a number of reasons, including:

• smaller memory footprint due to resource reuse
• more efficient data access due to cache reuse
• less maintenance work due to less configuration duplication

Along the way, we’ve seen how to work with multiple configuration files in Carmenta Studio, as well as using right-click-and-drag to create references in configurations.

Today, we have only used this for geodata, but just imagine the possibilities that open up when this is applied to other types of objects!

• Layers: reuse a whole visualization or processing chain
• Colors: define an organized color scheme in a separate file and just reuse where needed
• Conditions: make a shared repository of filter and/or layer conditions for easy reuse
• Expressions: collect (and name!) expression strings so they can be more easily changed and bugfixed
• Script strings: reuse ScriptOperator scripts for less maintenance workload
• AttributeSets: reusable collections of user properties, update attributes or feature attributes
• Constants: define a shared set of scale breakpoints or rendering control constants
• …