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.

[desruisseaux]

The GeoTIFF specification seems to already implies this convention. All requirements related to units of measurement are like below (example with requirement 16.7):

A GeogLinearUnitsGeoKey value of 32767 SHALL be a user-defined linear unit. If the value is 32767 (User-Defined) then the GeodeticCitationGeoKey and the GeogLinearUnitSizeGeoKey SHALL be populated

The reason why the citation shall be populated is not given in that section. But latter, in the User-defined geographic 2D CRS section, the specification said:

• (…snip…)
  • user-defined angle unit name (through the GeodeticCitationGeoKey) and scaling from SI base unit of radian (through the GeogAngularUnitSizeGeoKey); and
• (…snip…)
  • user-defined length unit name (through the GeodeticCitationGeoKey) and scaling from SI base unit of meter (through the GeogLinearUnitSizeGeoKey).

So the specification clearly suggests that the unit name is encoded in the citation, but does not said how.

[desruisseaux]

Open questions

What should be the rule for deciding if a CitationKey uses the multi-names syntax or not?

• Should it be the presence of | and = characters anywhere in the string?
  • If yes, does it means that those characters should be forbidden in names?
• Should it be the presence of a trailing | character?
  • This trailing character seems present in the examples I have seen so far.

What is the list of allowed keys? I have this so far, but I suspect that it is incomplete (missing linear units, and I guess that keys are different for ProjectedCitationGeoKey and VerticalCitationGeoKey):

Key name	Description
GCS Name	Name of the geodetic CRS
Datum	Name of the datum
Ellipsoid	Name of the ellipsoid
Primem	Name of the prime meridian
AUnits	Name of the angular unit of measurement

[desruisseaux]

Proposal available at https://github.com/opengeospatial/geotiff/pull/122/commits/31af2c5f39967e862bc5a52841b8eb4986de4059 as part of #122.

[desruisseaux]

Implicit generalization to other objects?

In GeoTIFF specification, requirement 25.5 said: If the VerticalDatumGeoKey value is 32767 (User-Defined) then the VerticalCitationGeoKey SHALL be populated. This requirement seems to imply that the GeodeticCitationGeoKey structure discussed in this issue should apply to VerticalCitationGeoKey as well. Maybe with GCS Name renamed into something else.

Likewise, requirement 27.5 said: if the ProjectionMethodGeoKey value is 32767 (User-Defined) then the ProjectedCitationGeoKey shall be populated. It also seems to imply that ProjectedCitationGeoKey needs to follow the same structure.

[desruisseaux]

An outcome of Testbed-19 is that the datum name is practically mandatory for EngineeringCRS, because datum names or identifiers are the only ways to identify if two datums are the same. We need that information for making possible to connect a GeoTIFF image in space to a chain of coordinate operations. So a generalization (above comment) may be necessary.