When are things reprojected?
The most efficient design is when your View and your DataSet use the same Coordinate Reference System (Crs), so that nothing needs to be reprojected.
But this design is impossible if your view displays features from several datasets that use different Coordinate Reference Systems: then, at least some of the features must be reprojected. Another reason for reprojection is that many datasets use a Crs based on LongLat, while a View.Crs based on LongLat would display an ugly map (except near the equator).
Usually, the necessary reprojections occur automatically, and you do not have to know where: just that they occur somewhere between the view and the dataset. But sometimes, it is useful to know exactly where they occur. A simplified answer is that things are reprojected as late as possible.
Basic Example
The picture below shows a simple configuration with a single layer, with some intermediate operators between the OrdinaryLayer and ReadOperator. When the view is updated, the request from the view flows rightward (see top of picture). The request contains the View.Area (see the ViewInfo class in the Carmenta Engine SDK documentation for more details), which is a rectangle expressed in the View.Crs (the coordinate reference system of the view). In this example, the View.Crs uses a conical map projection. The layer and the intermediate operators do not need to reproject the View.Area, so it is passed on unmodified to the ReadOperator.
 |
Now look at the bottom right of the picture. The ReadOperator reads from a dataset whose Crs is based on Projection.LongLat, so the dataset must be queried with a Projection.LongLat rectangle. However, the blue View area is not rectangular in Projection.LongLat, so the ReadOperator must reproject it from the conical map projection to Projection.LongLat. The result is the red area, which is the smallest Projection.LongLat rectangle that covers the blue area. Then, the dataset will retrieve all features that intersect the red area. You can see that in the east, it has to retrieve some polygons that are not really needed by the view.
The retrieved features will flow leftward, and will stay in LongLat as long as possible. They might be reprojected explicitly by a ProjectOperator but otherwise, it is the duty of the OrdinaryLayer to reproject them to the View.Crs (see bottom left of the picture).
Reasons for a ProjectOperator
A ProjectOperator will reproject features to a given Crs (the default is the View.Crs). It can be useful for many reasons.
A common case is when an operator combines features from several datasets, which will usually require the features to be in the same Crs. Most operators will then automatically reproject them to a single Crs, but the operators may not always choose the best Crs, and there are some operators, for example the VerticalProfileOperator, that cannot do automatic reprojection. If you use an explicit ProjectOperator, you can also add a ProjectParameters object that controls some details of how the reprojection shall be done; this control is not available when the reprojection is implicit.
Another common case is when you are doing your own geometric calculations in a ScriptOperator or custom object. Such calculations can be much easier if the features are expressed in a sensible meter-based map projection instead of LongLat, so a ProjectOperator can be useful.
There is one common operator that often needs a ProjectOperator, even if all data comes from a single dataset. This is the RectangleClipOperator, which we shall study in more detail.
Loose Rectangle Clipping
The RectangleClipOperator is often used to clip away unnecessary parts of features as early as possible, in order to improve performance. By default, the clip rectangle is the area of the current update request, which is usually the same as the entire view area.
But as the previous example showed, the view area is a rectangle that is expressed in the view Crs. So what should the RectangleClipOperator do if its incoming features are expressed in a different Crs? When the operator was designed, there were two alternatives:
The operator could reproject the features to the view Crs, since this must be done sooner or later. This alternative would give a tight clipping.
The operator could reproject the view area rectangle to the feature Crs, since this is a cheaper operation. This alternative can give a loose clipping, since the reprojected rectangle can be larger.
It was the 2nd alternative that was chosen, for reasons of efficiency. Although it is true that the features must be reprojected sooner or later anyway, it is better to do it later, because the RectangleClipOperator can often discard many feature parts cheaply, so that fewer points needs to be reprojected. (Reprojection is usually slower than rectangle clipping.)
The image below is modified from the previous example. The operator just to the left of the ReadOperator is now a RectangleClipOperator, which clips by the red rectangle. You can see that the operator discards many, but not all, of the unnecessary feature parts.
 |
Although usually harmless, the loose clipping is a problem for some kinds of visualization. For example, you may want to display each country name in the middle of the country polygon, by using PointVisualizer.AtCenter = True. If you do not use any rectangle clipping at all, the center of a polygon could be outside the view area. In these cases, you probably want the text at the center of the visible part of the polygon, and this is what rectangle clipping does for you - except that it is done imperfectly when the clipping is loose. In our example above, the resulting text visualization would be like this:
 |
The names of Slovakia and Hungary appear at the center of their clipped polygons. This is better than the center of their unclipped polygons, but not very good, since the names are partially outside the view area (the blue rectangle).
Tight Rectangle Clipping
To improve the visualization, we can clip tightly against the view area, by inserting a ProjectOperator that reprojects the features into the view Crs before they arrive to the RectangleClipOperator:
 |
This gives tight clipping, and the text visualization would now be like this:
 |
The combined behavior is the same as for the design alternative 1 that we discussed above for the RectangleClipOperator. So, we get the performance drawback of alternative 1: many points are reprojected although they are not really needed by the view.
To improve the performance a little, we can try to insert yet another RectangleClipOperator:
 |
The rightmost one, RectangleClipOperator1, would do the loose clipping efficiently, so that there is less work for the ProjectOperator0. This can improve the performance if the loose clipping will remove large parts of features (happens when many features are large compared to the view area), and if the reprojection requires complicated formulas (depends on the view Crs and the dataset Crs).
See also the map configuration sample rectangle_clipping.px.
Previous: Calculating with coordinates
Up: Coordinate Systems: Contents
Next: Letting a DataSet read its CRS from data files