Should the structure of GeogCitationGeoKey (GeodeticCitationGeoKey) content be standardized ?

[rouault]

GDAL has a mechanism to store the names of the Geodetic CRS, datum, ellipsoid, prime meridian and angular unit (or any subset of them) in the GeogCitationGeoKey in a structured way, by using a "key = value|" structure

This was added in GDAL 1.7 (~10 years ago), following a contribution by ESRI

For example

GTModelTypeGeoKey (Short,1): ModelTypeGeographic
GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
GeographicTypeGeoKey (Short,1): User-Defined
GeogCitationGeoKey (Ascii,55): "GCS Name = my CRS|Datum = My datum|Ellipsoid = my ellipsoid|Primem = Greenwich|AUnits = my degree|"
GeogGeodeticDatumGeoKey (Short,1): User-Defined
GeogAngularUnitSizeGeoKey (Double,1): 0.0174532925199433
GeogEllipsoidGeoKey (Short,1): User-Defined
GeogSemiMajorAxisGeoKey (Double,1): 6378135          
GeogInvFlatteningGeoKey (Double,1): 298.26           
GeogPrimeMeridianLongGeoKey (Double,1): 0

Should that be standardized ?

[joanma747]

The only "critical" item in the citation is the "datum name" because there is no other way to characterize it.

[joanma747]

Original intention of the GeogCitationGeoKey key: "this is provided to give an ASCII reference to published documentation on the overall configuration of this GeoTIFF file"

Name is mandatory in OGC 19111

My particular proposal is to fragment it.
GeographicTypeGeoKey (Short,1): User-Defined
GeographicTypeGeoNameKey (Ascii,??): "my CRS"
GeogGeodeticDatumGeoKey (Short,1): User-Defined
GeogGeodeticDatumNameGeoKey (Ascii,??): "My datum"
GeogAngularUnitSizeGeoKey (Double,1): 0.0174532925199433
GeogAngularUnitNameGeoKey (Ascii,1): "my degree"
GeogEllipsoidGeoKey (Short,1): User-Defined
GeogEllipsoidNameGeoKey (Ascii,??): "my ellipsoid"
GeogPrimeMeridianLongGeoKey (Double,1): 0
GeogPrimeMeridianNameGeoKey (Ascii,??): "Greenwich"

The same for ProjectedCRSName and VerticalCRSName.

[desruisseaux]

Note: GeoTIFF specification already uses that convention in §F.3.4 Spherical Moon Example.

[desruisseaux]

In the planetary working group, there is a need for aliases because names or identifiers of some asteroids (for example) can change. The ISO 19111 specification already supports aliases, but not GeoTIFF. A possible approach would be as below:

• Adopt the current practice (e.g. "GCS Name = my CRS|Datum = My datum|Ellipsoid = my ellipsoid|Primem = Greenwich|AUnits = my degree|"). This is less clean than the fragmentation proposal in above comment (current practice is an encoding inside the encoding), but if this practice is applied by both GDAL and ESRI for 10 years, then this is a large established base. GeoTIFF is already a patchy format anyway, with many levels of encoding inside encoding (GeoKeys in TIFF tags, XML documents, COG conventions, etc.).
• Add the following amendment: keys can be repeated. If a key is repeated (not necessarily consecutively), all occurrences after the first one are aliases. For example in "GCS Name = my CRS|Datum = My datum|Ellipsoid = my ellipsoid|Datum = My Datum alias|", "My datum" would be the primary datum name and "My datum alias" would be an alias for that datum.

[rouault]

there is a need for aliases because names or identifiers of some asteroids (for example) can change

Thinking out loud: shouldn't that be the job of a geodetic CRS database to cope with the possible aliases ? Typically the EPSG database conveys a table with alias names. Requesting a CRS definition to convey several aliases seems messy. Typically a WKT representation doesn't allow this (although it does allow multiple ID[] per object)

The practical problem is on the reader that may receive (old) files using old names, and files using new names. If it works nominally with the new names, it would use the alias table of its database to figure out that the old file uses an old name.

[desruisseaux]

Indeed, aliases should be declared in an EPSG-like registry as much as possible and used as explained in above comment for interoperability between an old and a new file. But a registry may not be always sufficient. This is similar to the use of WKT for CRS that are included in the EPSG database. The WKT is redundant but can be a safety in case the reading software does not have an EPSG database (e.g. for licensing reasons), or is an old version with an EPSG dataset that didn't included yet the CRS. Another reason may be that some research groups may have their own internal names, for example for more fine grain identification than what is provided in the registry.

Anyway this is not necessarily a "must have" feature, only a proposal if considered sufficiently non-disruptive.