desruisseaux commented on issue #10260:
URL: https://github.com/apache/iceberg/issues/10260#issuecomment-2254563957
A CRS as a string field is fine. I suggest to limit the allowed formats to
the following:
* WKT 2 as defined by ISO 19162
* SRID in the following forms:
* HTTP URL such as `http://www.opengis.net/def/crs/epsg/0/4326`
* URN such as `urn:ogc:def:crs:EPSG::4326`
* Maybe `AUTHORITY:CODE` as a shortcut for above URN with implicit
`urn:ogc:def:crs:` prefix and no version number.
* If Iceberg wants to handle 3D or 4D data, maybe allow compound SRID.
Example for (latitude, longitude) with height above Mean Sea Level:
* `urn:ogc:def:crs,crs:EPSG::4326,crs:EPSG::5714`
*
`http://www.opengis.net/def/crs-compound?1=http://www.opengis.net/def/crs/epsg/0/4326&2=http://www.opengis.net/def/crs/epsg/0/5714`
I suggest to avoid PROJJSON for now. It is not a standard, and if a slightly
different CRS JSON standard is added later, allowing the 2 formats in the same
field may create ambiguities. This is a risk that the OGC CRS working group
will try to avoid, but it is yet safer to not add PROJJSON too soon. Some
issues with PROJJSON are:
* Its model is based on a mix of WKT 2 and ISO 19111, which means that
PROJJSON inherits some of the compromise done in WKT 2 for historical reasons.
As a new format, it would have been nice to derive it more directly from the
ISO 19111 model, unless there is good reasons for departure.
* CRS definition contains at least 3 elements inherited from the ISO 19115
metadata standard: `Citation`, `Extent` and `PositionalAccuracy`. The encoding
of those elements in JSON is being defined by ISO and will be the [ISO
19115-4](https://www.iso.org/standard/86968.html) international standard. A CRS
JSON standard should not invent a different encoding. If we (implementers) have
to write a parser for ISO 19115-4, we want to use the same parser for at least
the metadata elements inside a CRS JSON.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
For additional commands, e-mail: issues-h...@iceberg.apache.org
