libproj: fix longtitude estimation for PJ_AREA#2476
Merged
metzm merged 1 commit intoOSGeo:mainfrom Jul 3, 2022
Merged
Conversation
metzm
added a commit
that referenced
this pull request
Jul 3, 2022
This is a partial fix for reprojections across the anti-meridian, where crossing 180W or 180E need to be handled differently, depending on the involved CRS's.
metzm
added a commit
that referenced
this pull request
Jul 3, 2022
This is a partial fix for reprojections across the anti-meridian, where crossing 180W or 180E need to be handled differently, depending on the involved CRS's.
metzm
added a commit
that referenced
this pull request
Jul 3, 2022
This is a partial fix for reprojections across the anti-meridian, where crossing 180W or 180E need to be handled differently, depending on the involved CRS's.
ninsbl
pushed a commit
to ninsbl/grass
that referenced
this pull request
Oct 26, 2022
This is a partial fix for reprojections across the anti-meridian, where crossing 180W or 180E need to be handled differently, depending on the involved CRS's.
ninsbl
pushed a commit
to ninsbl/grass
that referenced
this pull request
Feb 17, 2023
This is a partial fix for reprojections across the anti-meridian, where crossing 180W or 180E need to be handled differently, depending on the involved CRS's.
neteler
pushed a commit
to nilason/grass
that referenced
this pull request
Nov 7, 2023
This is a partial fix for reprojections across the anti-meridian, where crossing 180W or 180E need to be handled differently, depending on the involved CRS's.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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 likes to have longitudes in the range [-180, 180] which causes problems with geometries crossing the anti-meridian at either -180 or 180, also with the PROJ-specific PJ_AREA object required by PROJ to select the correct PROJ pipeline(s).
Tests with areas crossing the antimeridian and reprojecting these to UTM zone 60 or UTM zone 1 were successful. However, reprojecting back to a latlong location does not work out of the box. The user has to manually add the PROJ
+overswitch to the transformation pipeline, e.g.to successfully reproject an area back from UTM zone 1 to latlong: round trip latlong - > UTM zone -> latlong.
Unfortunately, there is no straightforward way (also not in the PROJ API) to automatically inject the
+overswitch at the correct place(s) in a PROJ projection pipeline.