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

Update to EPSG 10.003 and make code base robust to dealing with WKT CRS with DatumEnsemble #2370

Merged
merged 19 commits into from Oct 16, 2020

Conversation

rouault
Copy link
Member

@rouault rouault commented Oct 8, 2020

This pull request incorporates changes that, in my opinion, can and should be part of PROJ 7.2, since they are greatly backward compatible for downstream users. There will be a follow-up pull request that incorporates the few changes with obvious backward incompatibility challenges that would rather be material for PROJ 8.

So the executive summary of this pull request is:

  • import EPSG v10.003 content into proj.db. Despite structural changes, it has very very few content changes compared to EPSG v9.9 (which is a good thing here!)
  • for very few CRS, multiple USAGE (a SCOPE + EXTENT) can now be returned (an exemple is EPSG:2393 "KKJ / Finland Uniform Coordinate System"). This should have little/none backward incompatibility when ingesting this in older PROJ >= 6 versions
  • for dynamic datum & CRS (like "WGS 84 (Gxxxx)", "ITRFxxxx"), ingest the frame reference epoch from the database and emit it in WKT. No/little backward compatibility issue foreseen.
  • to align with epsg.org WKT output, emits the longer description of an extent/area of use, instead of the shorter one. The rationale for this change given by IOGP is that the shorter description doesn't include country names, and sometimes users need to have the full list of countries, to have an informed decision if a CRS / CoordinateOperation apply to them. Modest backward compatibility issue foreseen (required only minor adjustment to GDAL autotest suite, which was too sensitive. But GDAL autotest suite has to be amended from time to time to be robust to proj.db changes, so nothing new here)
  • datum ensembles... This is the most annoying part. The "World Geodetic System 1984" and "European Terrestrial Reference System 1989" datum have now in EPSG 10 a " ensemble" suffix in their names to reflect the new nature of those objects. In this pull request, datum ensembles will not show up as such when reading from the database. Instead old-style datum objects will still be emitted for the WGS 1984 and ETRS89 datums. So there's a hack (that will be removed in the follow-up pull request) to strip off the " ensemble" suffix for those 2 ones to continue emitting WKT similar to what we did before.
  • when a DatumEnsemble object (only coming from WKT:2019 input in the context of this pull request) must be exported to WKT < 2019, turn it into a classic Datum object for backward compatibility
  • make many parts of the code base robust to dealing with DatumEnsemble: identification of CRS to known CRS, equivalence comparison between CRS, createOperations() logic. The idea is that PROJ 7.2 will be able to process nominally WKT that PROJ 8 or new epsg.org can emit that include DatumEnsemble.
  • add new C API so that downstream users (GDAL in particular) can deal properly with CRS using DatumEnsemble rather than Datum.

Summary of the summary: this prepares for the future and makes it possible in the 7.x series to potentially update to later EPSG releases.

Fixes #2355

Funded by Safe software, GeoCue and Phoenix LiDAR Systems

Content mostly unchanged since v9.9

This update is "minimal" in that it mostly reflects the removal of the 'area'
table, replaced now by 'extent', 'scope' and 'usage'

Other new aspects of EPSG v10 are left aside.
…erit from ObjectUsage

as mandated by ISO 19111:2019
to allow exporting DatumEnsemble to WKT < 2019.
Add:
- proj_crs_get_datum_ensemble()
- proj_crs_get_datum_forced()
- proj_datum_ensemble_get_member_count()
- proj_datum_ensemble_get_accuracy()
- proj_datum_ensemble_get_member()

Make proj_create_geographic_crs_from_datum() and
proj_create_geocentric_crs_from_datum() accept a datum ensemble.
@jmckenna
Copy link
Contributor

jmckenna commented Oct 8, 2020

Great work @rouault Happy to see it possibly targeted for users of 7.2.0

@snowman2
Copy link
Contributor

snowman2 commented Oct 9, 2020

Nothing concerning from the failures here: pyproj4/pyproj#716. Mostly related to changes in the names from the database.

…able to handle dynamic vertical datums, and instanciate them properly from database
…FERENCE_FRAME and DYNAMIC_VERTICAL_REFERENCE_FRAME, and make corresponding C API work
@rouault
Copy link
Member Author

rouault commented Oct 13, 2020

@kbevers Are you OK for this to be merged in master for 7.2 ? I've a GDAL fix that depends on this to be merged

@rouault
Copy link
Member Author

rouault commented Oct 16, 2020

Merging this

@rouault rouault merged commit 82b496f into OSGeo:master Oct 16, 2020
2 checks passed
rouault added a commit to OSGeo/gdal that referenced this pull request Oct 16, 2020
OSR: make it robust to dealing with datum ensemble objects. Depends on OSGeo/PROJ#2370 / PROJ 7.2
@kbevers
Copy link
Member

kbevers commented Oct 18, 2020

@kbevers Are you OK for this to be merged in master for 7.2 ? I've a GDAL fix that depends on this to be merged

Sorry for not getting back earlier, I've been on vacation. Yes, I am okay with this merge!

rsbivand referenced this pull request in r-spatial/sf Jan 24, 2022
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.

Database: upgrade to EPSG version 10 data model
4 participants