Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ENH: Support proj4 v5+ #1124

Merged
merged 11 commits into from
Oct 12, 2018
Merged

ENH: Support proj4 v5+ #1124

merged 11 commits into from
Oct 12, 2018

Conversation

QuLogic
Copy link
Member

@QuLogic QuLogic commented Sep 25, 2018

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_longitude option, 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 +over originally, 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.

@QuLogic QuLogic added this to the 0.17 milestone Sep 25, 2018
@QuLogic
Copy link
Member Author

QuLogic commented Sep 25, 2018

Oops, didn't try will 5.2 yet; will fix up then.

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.
@QuLogic QuLogic changed the title TST: Unpin proj4. ENH: Support proj4 v5+ Oct 3, 2018
@QuLogic
Copy link
Member Author

QuLogic commented Oct 3, 2018

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.
@dopplershift
Copy link
Contributor

So according to the devs:

Hence we have decided to decouple the name from the version number and from this version and onwards the product will simply be called PROJ.

Should the mentions of the library in this PR then not be Proj4?

@QuLogic
Copy link
Member Author

QuLogic commented Oct 6, 2018

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.

@dopplershift
Copy link
Contributor

Yeah. I was only talking about ones added in this PR really, but cool to clean up more.

@dopplershift
Copy link
Contributor

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.
@QuLogic
Copy link
Member Author

QuLogic commented Oct 6, 2018

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.
@QuLogic
Copy link
Member Author

QuLogic commented Oct 12, 2018

This should now cover all issues of the 5.y.z line from conda-forge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants