Geographical Coordinates in a Carmenta Engine workflow
Geographical data and map views are defined in a Coordinate Reference Systems (CRS). There are many different coordinate systems, which can be used for different purposes. It is for example very common to use a Mercator coordinate projection for visualization of worldwide data on a map. In contrast, Mercator is not recommended for calculations or data storage, because of risk for lack of precision, especially near the poles.
An application often needs to handle geodata in different CRSs or visualize it in another CRS than the CRS of the data source. This means that the data needs to be reprojected at some point. These projections can both affect performance and cause a loss of accuracy if they are not performed efficiently.
Carmenta Engine has in-depth support for efficient coordinate transformations. In this article, we will describe how geographical coordinates are generally handled in the Carmenta Engine workflow, as well as go into some more advanced use cases and best practices.
Basic workflow
Coordinates are in most cases automatically transformed in Carmenta Engine configurations. In this article, the examples will be taken from Carmenta Studio, but keep in mind that the behavior is exactly the same when working with the Carmenta Engine API.
The following chart shows a basic Carmenta Studio example.
The ReadOperator reads Feature objects from the DataSet (MemoryDataSet0). These features are defined in the CRS of the DataSet, in this case WGS84 Longitude Latitude (Wgs84LongLat).
After the data is returned by the ReadOperator, the Features typically pass through additional operators, such as a VisualizationOperator, and an OrdinaryLayer, before arriving to the View. At this point, Carmenta Engine reprojects the data on-the-fly from its current CRS to the CRS of the View (Wgs84MercatorWeb in this example), if they differ from each other.
Note: Generally, Coordinates should be transformed as late as possible, after any filtering, to avoid unnecessary calculations and achieve the best performance. In the general case, especially when for very dynamic data that can’t benefit from caching, it is preferable to use the same CRS for both the DataSet and the View. This will avoid unnecessary frequent reprojections.
Advanced use cases
Because not all applications are that simple and there are also some exceptions, there is a more complex scenario below. The single use cases which potentially need more attention are marked with an orange symbol. Let’s consider here that every DataSet has a different CRS.
Case A: Multiple data in different CRSs as input to the View
All input sources will be automatically reprojected to the View CRS.
Case B: Data passing through a unary operator
Carmenta Engine provides many operators which can perform geodetic/geometric calculations, filtering, or similar processes. A unary operator has only one data input. In the typical case, no projection is needed, and operators work out-of-the-box.
Note: In some cases, the CRS of the data is not suitable for the operation, such as special analysis calculations. It could also be that the operator has a different output or behavior based on different CRSs, such as RectangleClipOperator which can depend on the View CRS.
Hints: First have a look at the documentation for the operator, to check if it has a property to specify which CRS to use for the operation. An alternative is to use a ProjectOperator to reproject the features to the desired CRS, before the operation is applied.
Best Practice: An early projection of the whole data source is more expensive than letting Carmenta Engine project it for displaying on the View, so make sure to use the ProjectOperator only when needed.
Case C: Multiple data in different CRSs as input of an operator
When operators have multiple inputs, the data in each input can have a different CRS. In that case, projection is usually done automatically within the operator. The target CRS, which will be applied to the output, is chosen by the operator.
Note: It is possible that the CRS automatically chosen by the operator is not always the best. Operators are also sometimes unable to perform certain projections automatically; for example, the VerticalProfileOperator needs all its inputs to use the same CRS, in order to transform them into the special NonGeoreferenced CRS.
Hints: Like in case B, the first step is to check the documentation of the operator and its inputs for special treatment of the CRS. If necessary, the next step is to use a ProjectOperator.
Best Practice: Transforming rasters is particularly costly. When working with elevation data, for example, it is better to reproject the non-raster data, such as the vertical profile source line, rather than reprojecting the elevation data.
Case D: DataSet
Usually, the CRS is automatically read by the DataSet from the metadata in the source files or the source database.
Note: Some user-specific CRSs could be read incorrectly, or sometimes no CRS is available in the metadata.
Hints: You can manually specify the CRS property on the DataSet. Have a look at this article to find out find out more: Letting a DataSet read its CRS from data files. There are also many ways to construct a CRS, such as from an EPSG code, from Well Known Text, or from the area of use. For more info, have a look at the Crs class (Crs construction) in the documentation.
References:
