Handle orthographic projections compatibly #2092
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add a map that uses an orthographic projection, such as Mapper sets up for an import from OpenStreetMap. Test that a track template is positioned correctly. Behavior of PROJ with +proj=ortho changes at version 7.2. A change in alignment within a map is undesirable. OpenOrienteeringGH-2016
Add the trySetOrthoSpheroidal method which will change a PROJ spec string that uses the 'ortho' projection into one which is explicitly spheroidal, with 0 flattenting, by ensuring that '+f=0' is part of the spec string.
With PROJ 7.2, 'ortho' supports ellipsoidal variation of the projection, changing the meaning of some spec strings, and upsetting the map's georeferencing. Generally, this makes the georeferencing's scale factor properties inconsistent with the new interpretation of the projection. In this change, the 'validate_georeferencing' method is extended to detect this situation and add "+f=0" to the spec string. "+f=0" makes explicit that the projection is spheroidal, restoring the effective projection to what it was when the map was originally georeferenced with an earlier version of PROJ.
The 'validateGeoreferencing' method checks for inconsistent scale factors that arise from a change to PROJ that appeared in version 7.2. This change suppresses that check if this Mapper was built with an earlier version of PROJ. The PROJ version is identified by CMake and passed to the compiler in the PROJ_PULL_2361 macro.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PROJ is changing the way it handles '+proj=ortho' in spec strings, as of version 7.2. Previously, that projection performed a spheroidal calculation, even with the WGS84 datum. With the change, PROJ uses the precise ellipsoidal shape when projecting.
I encountered and reported this in #2016, because I build Mapper on Linux where PROJ has been at version 7.2 for several months. The new PROJ alters the geographic coordinates of map objects, changing their alignment in relation to georeferenced templates.
This PR includes a regression test of a GPX track template that fails with the latest PROJ due to the track becoming misaligned with the map. It also addresses the problem, by detecting maps having '+proj=ortho' in the CRS, that were created with an older version of PROJ. It prevents misalignment by inserting '+f=0' into the spec string. The revised CRS spec performs identically to the way older versions of Mapper handled the original CRS spec.
This solution does not have the drawback mentioned in solution #2020. It supports the ellipsoidal orthographic projection by passing the spec string directly to PROJ.
In this code change, detection of maps that need the spheroidal version is 99.98% effective. It works because the grid scale factor can be inferred from a saved map file. The spheroidal and ellipsoidal projections generally have different grid scale factors, leading to an inconsistency that is evident when Mapper loads a map with a 'ortho' projection that is spheroidal, but not explicitly so. [The grid scale factors are close enough between latitudes 45.05° and 45.06° that the discrepancy is not detected. This exception affects parts of Minneapolis and Turin.]