mapper
mapper copied to clipboard
OpenOrienteering
Georeferencing: Use direct CRS-to-CRS-transform
@pkturner This is how using modern PROJ, i.e. direct transformation between CRS, would look like, eliminating the need to commit to a particular geographic CRS for coordinate transformations, and even considering the area of interest.
This is just the principle. Creating the pipeline and area object for each single transformation is too expensive. But probably it is good enough for verification and experimentation.
In the end, we might turn Georeferencing into something which doesn't bind the projected CRS to WGS84 at all. We would instead have all secondary georeferencings (template, GPS, Lat/Lon display) provide a pipeline to the map's primary georeferencing.
On proj_create_crs_to_crs:
- https://proj.org/development/reference/functions.html#c.proj_create_crs_to_crs
- https://proj.org/operations/operations_computation.html
This code change would actually have acceptable efficiency, because the affected variant of toMapCoordF is only called when there's a change to georeferencing, such as when a map is imported.
This code change would actually have acceptable efficiency, because the affected variant of toMapCoordF is only called when there's a change to georeferencing, such as when a map is imported.
This is true for some template types, but for others where toMapCoordF is called for every map object, it is unacceptable to incur the overhead of constructing the direct CRS-to-CRS transform every time.
we might turn
Georeferencinginto something which doesn't bind the projected CRS to WGS84 at all. We would instead have all secondary georeferencings (template, GPS, Lat/Lon display) provide a pipeline to the map's primary georeferencing.
The changes underway in #1789 and #1814 bring the prospect of Mapper supporting geographic CRSes beyond WGS84. Ideally, Mapper would handle various geographic CRSes on an equal footing. Using the direct CRS-to-CRS transform efficiently is the essential step toward that goal.
@dg0yt I expect you already have an implementation structure in mind, and a code contribution from myself would not be much help.
This is true for some template types, but for others where
toMapCoordFis called for every map object, it is unacceptable to incur the overhead of constructing the direct CRS-to-CRS transform every time.
Yes. This is why it did't want to propose it for inclusion as is (cf. first comment).
The changes underway in #1789 and #1814 bring the prospect of Mapper supporting geographic CRSes beyond WGS84. Ideally, Mapper would handle various geographic CRSes on an equal footing. Using the direct CRS-to-CRS transform efficiently is the essential step toward that goal.
#1814 is somewhat independent, fixing inconsistencies and improving testing of existing code.
I'm close to updating #1789, making it ready for inclusion. This shall lead to direct transformations on loading data, independent of this PR here, and also independent of #1814 at least for OgrTemplate. I will try to include similar capabilities for TemplateTrack. This must be tested.