Open rouault opened 5 years ago
The only "critical" item in the citation is the "datum name" because there is no other way to characterize it.
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.
Note: GeoTIFF specification already uses that convention in §F.3.4 Spherical Moon Example.
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:
"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.)."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.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.
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.
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.
What should be the rule for deciding if a CitationKey
uses the multi-names syntax or not?
|
and =
characters anywhere in the string?
|
character?
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 |
Proposal available at https://github.com/opengeospatial/geotiff/pull/122/commits/31af2c5f39967e862bc5a52841b8eb4986de4059 as part of #122.
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.
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.
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
Should that be standardized ?