EPSG v10 update part 2: ingest DatumEnsemble from the database

[rouault]

This is a follow-up to #2370. It incorporates changes that have backward compatible challenges. That is with this pull request, CRS that depend on the WGS 1984 and ETRS89 datum, will know use a DatumEnsemble object instead of a Datum. The WKT:2019 export of such CRS could cause hick-ups to PROJ < 7.2 (assuming PROJ 7.2 will incorporate PR #2370) because it is not fully ready to deal with DatumEnsemble.

Only the few commits starting with 'When reading from database, possibly return Geographic/GeodeticCRS with a DatumEnsemble, typically for WGS 84 and ETRS89 ('breaking change')" are specific to this pull request.

With this pull request, WKT2:2019 output of EPSG:4326 will be

GEOGCRS["WGS 84",
    ENSEMBLE["World Geodetic System 1984 ensemble",
        MEMBER["World Geodetic System 1984 (Transit)"],
        MEMBER["World Geodetic System 1984 (G730)"],
        MEMBER["World Geodetic System 1984 (G873)"],
        MEMBER["World Geodetic System 1984 (G1150)"],
        MEMBER["World Geodetic System 1984 (G1674)"],
        MEMBER["World Geodetic System 1984 (G1762)"],
        ELLIPSOID["WGS 84",6378137,298.257223563,
            LENGTHUNIT["metre",1]],
        ENSEMBLEACCURACY[2.0]],
    PRIMEM["Greenwich",0,
        ANGLEUNIT["degree",0.0174532925199433]],
    CS[ellipsoidal,2],
        AXIS["geodetic latitude (Lat)",north,
            ORDER[1],
            ANGLEUNIT["degree",0.0174532925199433]],
        AXIS["geodetic longitude (Lon)",east,
            ORDER[2],
            ANGLEUNIT["degree",0.0174532925199433]],
    USAGE[
        SCOPE["Horizontal component of 3D system."],
        AREA["World."],
        BBOX[-90,-180,90,180]],
    ID["EPSG",4326]]

What I didn't do since I wasn't sure if we really needed it is to offer an option to emit WKT:2019 with old style DATUM[]. (but reiterating something mentionned in the part 1 pull request, if exporting to WKT < 2019, this will be done automatically)

Final fixes #2355

Funded by Safe software, GeoCue and Phoenix LiDAR Systems

[snowman2]

Nothing concerning from the failures in pyproj4/pyproj#717. Mostly changes the representation of the data based on database changes.

[snowman2]

Some interesting behavior:

Based on: proj_create_from_database using PJ_CATEGORY_DATUM:

>>> Datum.from_epsg(6326)
DATUM["World Geodetic System 1984",
    ELLIPSOID["WGS 84",6378137,298.257223563,
        LENGTHUNIT["metre",1]],
    ID["EPSG",6326]]

Based on proj_create:

>>> Datum.from_string("World Geodetic System 1984")
ENSEMBLE["World Geodetic System 1984 ensemble",
    MEMBER["World Geodetic System 1984 (Transit)",
        ID["EPSG",1166]],
    MEMBER["World Geodetic System 1984 (G730)",
        ID["EPSG",1152]],
    MEMBER["World Geodetic System 1984 (G873)",
        ID["EPSG",1153]],
    MEMBER["World Geodetic System 1984 (G1150)",
        ID["EPSG",1154]],
    MEMBER["World Geodetic System 1984 (G1674)",
        ID["EPSG",1155]],
    MEMBER["World Geodetic System 1984 (G1762)",
        ID["EPSG",1156]],
    ELLIPSOID["WGS 84",6378137,298.257223563,
        LENGTHUNIT["metre",1],
        ID["EPSG",7030]],
    ENSEMBLEACCURACY[2.0],
    ID["EPSG",6326]]

[rouault]

Some interesting behavior:

yes, this is intended. If you force instantiation of EPSG:6326 as a Datum (and not a DatumEnsemble), PROJ will instanciate it as such. This is mostly intended to be used internally by PROJ to be still able to export WKT < 2019. If you don't put constraint, it will return it as a DatumEnsemble.

[snowman2]

@rouault, I don't see a datum ensemble category, just a datum category:

PROJ/src/proj.h

Line 694 in a5dd7bb

PJ_CATEGORY_DATUM,

Are there plans to add one?

[snowman2]

Also, for:

>>> Datum.from_string("World Geodetic System 1984")
ENSEMBLE["World Geodetic System 1984 ensemble",

Thoughts on having proj_create differentiate between the ensemble and the regular datum by requiring ensemble at the end?

[rouault]

I don't see a datum ensemble category

just added one

Thoughts on having proj_create differentiate between the ensemble and the regular datum by requiring ensemble at the end?

I'm not super keen on adding special processing for that. proj_create("World Geodetic System 1984") returns ENSEMBLE["World Geodetic System 1984 ensemble"] because there is an alias in the database between both (and probably approximate string matching would also do it in that situation).

[snowman2]

Okay, that makes sense. Should the ensemble be preferred over the datum in general? Also, thanks for adding the category 👍

[rouault]

Should the ensemble be preferred over the datum in general?

Not sure if that answers your question, but reporting an ensemble as such is the nominal behaviour now in EPSG v10 / ISO-19111:2019. Returning it as a Datum is a kind of degraded / backward behaviour. But this is admittedly geodesic pedantry.

[snowman2]

Is PJ_CATEGORY_DATUM_ENSEMBLE something that would make sense to add to 7.2 or is it something only for 8?

[rouault]

Is PJ_CATEGORY_DATUM_ENSEMBLE something that would make sense to add to 7.2 or is it something only for 8?

I'd say only 8, as in 7.2 DatumEnsemble objects are not instanciated from the database