rdblue commented on code in PR #10981: URL: https://github.com/apache/iceberg/pull/10981#discussion_r1907680512
########## format/spec.md: ########## @@ -1633,3 +1652,27 @@ might indicate different snapshot IDs for a specific timestamp. The discrepancie When processing point in time queries implementations should use "snapshot-log" metadata to lookup the table state at the given point in time. This ensures time-travel queries reflect the state of the table at the provided timestamp. For example a SQL query like `SELECT * FROM prod.db.table TIMESTAMP AS OF '1986-10-26 01:21:00Z';` would find the snapshot of the Iceberg table just prior to '1986-10-26 01:21:00 UTC' in the snapshot logs and use the metadata from that snapshot to perform the scan of the table. If no snapshot exists prior to the timestamp given or "snapshot-log" is not populated (it is an optional field), then systems should raise an informative error message about the missing metadata. +## Appendix G: Geospatial Notes + +The Geometry and Geography class hierarchy and its WKT and WKB serializations (ISO supporting XY, XYZ, XYM, XYZM) are defined by [OpenGIS Implementation Specification for Geographic information – Simple feature access – Part 1: Common architecture](https://portal.ogc.org/files/?artifact_id=25355), from [OGC (Open Geospatial Consortium)](https://www.ogc.org/standard/sfa/). + +The version of the OGC standard first used here is 1.2.1, but future versions may also used if the WKB representation remains wire-compatible. + +Coordinate axis order is always (x, y) where x is easting or longitude, and y is northing or latitude. This ordering explicitly overrides the axis order specified in the CRS. Review Comment: I find it surprising that we would specify this. I think it will cause problems because people would easily not know about it and could easily have mixed WKB data values (some conforming to the CRS and some explicitly following this and not the CRS). What is the purpose of this? - If it is intended only for the points that we use for lower and upper bounds, then I think we should be strict in the binary representation we use for those points and not make a general statement. - If this is intended to apply to all WKB stored in Iceberg tables, then I think a better option is to disallow CRS definitions that use a different axis order. However, I don't see a reason why we would restrict the axis order because WKB is already opaque to Iceberg. @mkaravel, what do you think? -- 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
