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

rouault · 2020-10-08T19:38:55Z

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.

…r dynamic datums, but not yet used

…xxx, WGS 84 (Gxxxx), etc.) when possible

… epsg.org WKT export

…them)

… remove one hack

…erit from ObjectUsage as mandated by ISO 19111:2019

to allow exporting DatumEnsemble to WKT < 2019.

…n creating from text_definition

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.

…OSGeo/PROJ#2370 / PROJ 7.2

jmckenna · 2020-10-08T19:44:50Z

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

snowman2 · 2020-10-09T13:59:04Z

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 · 2020-10-13T14:36:45Z

@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 · 2020-10-16T16:26:03Z

Merging this

OSR: make it robust to dealing with datum ensemble objects. Depends on OSGeo/PROJ#2370 / PROJ 7.2

kbevers · 2020-10-18T16:16:51Z

@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!

rouault added 16 commits October 6, 2020 23:48

Database: "minimal" update to EPSG v10.003

a9b6f39

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.

Database: add a reference_frame_epoch column to the geodetic_datum fo…

4c99203

…r dynamic datums, but not yet used

Database: instanciate DynamicGeodeticReferenceFrame (things like ITRF…

2cfdd6f

…xxx, WGS 84 (Gxxxx), etc.) when possible

Database: use extended description for extent/area of use, as done by…

3ed9a61

… epsg.org WKT export

getCRSInfoList(): make it use area description

ecf9cf0

Database: import datum ensemble accuracy and members (but do not use …

ff9a386

…them)

Database: avoid importing duplicated alias names

e51a7db

Database: add aliases for 'old' names of WGS84 and ETRS89 datums, and…

fece8a6

… remove one hack

Add a AuthorityFactory::createDatumEnsemble() method, and make it inh…

b5369cc

…erit from ObjectUsage as mandated by ISO 19111:2019

Add DatumEnsemble::asDatum() and use it in exportToWkt()

9dc3bf5

to allow exporting DatumEnsemble to WKT < 2019.

Make CRS identification work with CRS with DatumEnsemble

53672bd

Make createOperations() work with DatumEnsemble

492c95c

createGeodeticCRS(): more DatumEnsemble compatibility in the case whe…

4049f4c

…n creating from text_definition

Make proj_create_crs_to_crs() / cs2cs work with CRS with DatumEnsemble

67af1d5

Make GeographicCRS::is2DPartOf3D() work with DatumEnsemble

acd1cf3

rouault added this to the 7.2.0 milestone Oct 8, 2020

rouault added a commit to rouault/gdal that referenced this pull request Oct 8, 2020

OSR: make it robust to dealing with datum ensemble objects. Depends on …

87bc645

…OSGeo/PROJ#2370 / PROJ 7.2

rouault mentioned this pull request Oct 8, 2020

OSR: make it robust to dealing with datum ensemble objects. Depends on https://github.com/OSGeo/PROJ/pull/2370 / PROJ 7.2 OSGeo/gdal#3033

Merged

rouault mentioned this pull request Oct 8, 2020

EPSG v10 update part 2: ingest DatumEnsemble from the database #2371

Merged

This was referenced Oct 8, 2020

Datum Ensemble Support pyproj4/pyproj#714

Closed

TST: Test EPSG 10 PROJ changes pyproj4/pyproj#716

Closed

rouault added 3 commits October 11, 2020 19:50

Database: add a frame_reference_epoch column in vertical_datum to be …

ad80dc8

…able to handle dynamic vertical datums, and instanciate them properly from database

Database query: add AuthorityFactory::ObjectType::DYNAMIC_GEODETIC_RE…

d1a0d95

…FERENCE_FRAME and DYNAMIC_VERTICAL_REFERENCE_FRAME, and make corresponding C API work

C API: add proj_dynamic_datum_get_frame_reference_epoch()

6867134

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

Merge pull request #3033 from rouault/datum_ensemble

754bf9b

OSR: make it robust to dealing with datum ensemble objects. Depends on OSGeo/PROJ#2370 / PROJ 7.2

snowman2 mentioned this pull request Oct 17, 2020

TST: Update to EPSG 10 pyproj4/pyproj#725

Merged

rsbivand referenced this pull request in r-spatial/sf Jan 24, 2022

fixes #1804

30cccf5

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

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

rouault commented Oct 8, 2020 •

edited

jmckenna commented Oct 8, 2020

snowman2 commented Oct 9, 2020

rouault commented Oct 13, 2020

rouault commented Oct 16, 2020

kbevers commented Oct 18, 2020

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

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

Conversation

rouault commented Oct 8, 2020 • edited

jmckenna commented Oct 8, 2020

snowman2 commented Oct 9, 2020

rouault commented Oct 13, 2020

rouault commented Oct 16, 2020

kbevers commented Oct 18, 2020

rouault commented Oct 8, 2020 •

edited