-
Notifications
You must be signed in to change notification settings - Fork 791
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
Database: update to EPSG v9.6.1, IGNF v3.0.3, ESRI 10.7.0 and add operation_version column #1368
Conversation
…pper node This is the standard logic, that is now possible since ID is allowed in BASEGEOGCRS and similar node
… upper node This is a particular logic allowed by paragraph 7.3.3 Identifier of OGC 18-010r6
even if there is one on upper node This is a particular logic allowed by paragraph 7.3.3 Identifier of OGC 18-010r6
Maybe a topic for discussion on the mailing list? My immediate thoughts are that it is probably safe to do a backport right now but it may cause problems for people in the future. In the future we may very well see people that are interfacing with the database directly. |
Discussion started in https://lists.osgeo.org/pipermail/proj/2019-March/008376.html |
👍 to this being done at this time. It is still quite early in the 6.0 cycle and people are just getting acclimated. |
Backport #1368 on 6.0: Database: update to EPSG v9.6.1, IGNF v3.0.3, ESRI 10.7.0 and add operation_version column
Only the 4 last commits are specific to this PR, the other ones come from #1366
I'm not sure what our policy regarding backport is for that case. There's no API change, but we change database content and structure.