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

RFC 73: Integration of PROJ6 for WKT2, late binding capabilities, time-support and unified CRS database #1185

Merged
merged 1 commit into from
Jan 31, 2019

Conversation

rouault
Copy link
Member

@rouault rouault commented Jan 8, 2019

@rouault rouault force-pushed the gdalbarn branch 2 times, most recently from 955f600 to 186c858 Compare January 12, 2019 08:43
@hobu
Copy link
Contributor

hobu commented Jan 13, 2019

🎊 congratulations to get this far @rouault! I'm excited we can start filing super miserable and intricate coordinate system bug reports now 😄

I do not think that GDAL 2.5 having a hard requirement of PROJ6 is going to be such a bad thing, but it is likely to have a consequence of delaying or elongating the adoption curve of GDAL 2.5 quite significantly as people wait for their packaging platforms to catch up to PROJ6. PROJ 5.0 -> 5.2 -> 6.0 pretty aggressively dropped the older API, so packagers are in a spot because there are likely to be a number of packages that have not caught up to PROJ 5+ compatible APIs. I think we should discuss having a couple of 2.4 maintenance releases of bug content for this situation to ease the pain without bending over backwards to provide a very difficult PROJ compatibility effort. Did you have any thoughts on this? @rouault @kbevers

@kbevers
Copy link
Member

kbevers commented Jan 13, 2019

@hobu I don't have any thoughts regarding GDAL. It is my impression that most dependencies on PROJ primarily rely on the proj_api.h API which will be around for version 6 as well. As far as I can tell the big hit happens when we go to PROJ 7 (which drops proj_api.h). We can schedule maintenance release of PROJ 6 alongside PROJ 7 releases if that is helpful to package maintainers. Or we can wait a bit to go to PROJ 7 to let downstream projects catch up. It is hard to get a feel for what is the best way forward when very few dependent projects engage in the discussions on this topic.

@hobu
Copy link
Contributor

hobu commented Jan 13, 2019

rely on the proj_api.h API which will be around for version 6 as well

Oops, I thought 6 was the cut-off for this. That certainly lessens the blow. As long as we are clearly communicating when things happen I don't think there should be any problem.

@kbevers
Copy link
Member

kbevers commented Jan 13, 2019

As long as we are clearly communicating when things happen I don't think there should be any problem

It's been mentioned in release notes, is written on the PROJ website and has been mentioned multiple times on the mailing list. You will also have to define ACCEPT_USE_OF_DEPRECATED_PROJ_API_H to be able to use proj_api.h with PROJ 6. This should raise the flag for anyone who hadn't already gotten the news. Not sure if there's more we can do that will make a positive difference.

@rouault
Copy link
Member Author

rouault commented Jan 14, 2019

I think we should discuss having a couple of 2.4 maintenance releases of bug content

Yes, 2.4.x will certainly be maintained a bit more after 2.5.0 release

@rouault rouault force-pushed the gdalbarn branch 2 times, most recently from 1509ec4 to fdfd5e7 Compare January 21, 2019 18:41
@rouault rouault force-pushed the gdalbarn branch 2 times, most recently from 8682dfe to ff3b1e4 Compare January 25, 2019 18:51
…ities, time-support and unified CRS database
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants