desruisseaux commented on code in PR #10981: URL: https://github.com/apache/iceberg/pull/10981#discussion_r1960782392
########## format/spec.md: ########## @@ -228,6 +230,30 @@ Notes: For details on how to serialize a schema to JSON, see Appendix C. +[1001]: <https://portal.ogc.org/files/?artifact_id=25355> "OGC Simple feature access" + +##### CRS + +For `geometry` and `geography` types, the parameter C refers to the CRS (coordinate reference system), a mapping of how coordinates refer to locations on Earth. + +The default CRS value `OGC:CRS84` means that the objects must be stored in longitude, latitude based on the WGS84 datum. + +Custom CRS values can be specified by a string of the format `type:identifier`, where `type` is one of the following values: + +* `srid`: [Spatial reference identifier](https://en.wikipedia.org/wiki/Spatial_reference_system#Identifier), `identifier` is the SRID itself. Review Comment: I think that it may be safer to only said that the default is OGC:CRS84, without saying that it is equivalent to EPSG:4326 with axis order overridden. Overriding the axis order is deprecated by [OGC directive 14](https://portal.ogc.org/public_ogc/directives/directives.php#14) because it is ambiguous. It works for the most common CRS, but is an impediment to interoperability with less common CRS such as South-orientated or polar projections. The practice of overriding axis order in a specification was established in old standards such as GeoTIFF and Simple Features. Then, it became a self-sustaining problem, with some (fortunately not all) newer standards citing Simple Features as a precedent, despite OGC directive 14 explicitly asking us to stop doing so. Note that the problem is not the desire to have (_x_, _y_) axis order. The problem is in the way to achieve that goal, when that order is enforced by the specification. OGC directive 14 proposes a choice between 3 other ways to obtain the same result without the ambiguity of the "specification overrides authoritative definition" approach. In the case of OGC:CRS84, that definition is non-ambiguous regarding axis order, so it is okay as a default value. OGC:CRS84 is ambiguous regarding the datum however, which means that (longitude, latitude) coordinates in OGC:CRS84 have an uncertainty of about 2 meters. I think this uncertainty would have been worth a note, and I think that the sentence "EPSG:4326 and OGC:CRS84 are equivalent with respect to this specification" should be omitted in order to be more quiet about this deprecated practice. -- 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
