ENH: Support proj4 v5+ #1124
ENH: Support proj4 v5+ #1124
Conversation
|
Oops, didn't try will 5.2 yet; will fix up then. |
QuLogic
force-pushed
the
proj4-update
branch
5 times, most recently
from
43c35d0
to
cc66a65
Compare
However, keep using 4.9.1 on the non-latest builds. Though we do support back to 4.9.0, that version is not available in conda.
This is a known bug fix in proj.4 5.0.0, wherein lat_0=0 used to erroneously multiply results by 2. See OSGeo/PROJ#194
If using exactly central_longitude+/-180, one boundary will now wrap around and produce the position of the opposite one. So subtract a small epsilon from that boundary to prevent wrap-around. This produces something on the tenth of a millimetre difference, but that probably won't be visible when plotted.
|
This is now working on both old and latest proj.4; see updated description for details. |
Seems like those releases were a bit buggy, since it goes back to the previous result in 5.1.0.
|
So according to the devs:
Should the mentions of the library in this PR then not be Proj4? |
|
Yes, that is true. I've renamed all the safe places to drop the superfluous 4. Code will have to remain the same, and I think if we want to do that, it can be in a separate PR with relevant deprecations and the like. |
|
Yeah. I was only talking about ones added in this PR really, but cool to clean up more. |
|
The tests really want you to update the copyright years in those files now. UGH. |
That is, any comments, documentation, or output, now drops the '4'. Names in code have not been changed to preserve backwards-compatibility.
|
Oh right; we should commit more things so I don't have to remember this 3/4 of the way into a year. |
It does not work correctly in 5.0.0 <= proj4 < 5.1.0.
The Google Mercator projection seems to come out slightly smaller than it should.
|
This should now cover all issues of the 5.y.z line from conda-forge. |
There doesn't seem to be any problems using it, but let's see what CI says.There are a couple of improvements to projections, so that requires a couple test updates.
For projections with a
central_longitudeoption, one of the boundaries will now be wrapped. So we have to fuzz that one a bit by subtracting a small epsilon. I tried using+overoriginally, as suggested in the upstream ticket OSGeo/PROJ#1135, but that caused everything to not wrap, so I went with the epsilon instead. It's not exactly symmetric, but only differs in the tenth of a millimetre, so probably not noticeable on a plot.Fixes #1045.
Fixes #1071.
Fixes #1097.