dannycjones commented on code in PR #2933: URL: https://github.com/apache/iceberg-rust/pull/2933#discussion_r3956195981
########## crates/iceberg/src/spec/datatypes.rs: ########## @@ -43,6 +43,8 @@ pub const MAP_VALUE_FIELD_NAME: &str = "value"; pub(crate) const MAX_DECIMAL_BYTES: u32 = 24; pub(crate) const MAX_DECIMAL_PRECISION: u32 = 38; +const DEFAULT_GEOSPATIAL_CRS: &str = "OGC:CRS84"; +const EQUIVALENT_DEFAULT_GEOSPATIAL_CRS: &str = "EPSG:4326"; Review Comment: I've been digging into this a bit more. I found that the Iceberg, Arrow, and Parquet specs all agree that the ordering is lon,lat irrespective of the CRS specified. However, I don't see any guidance on if and when CRS should be normalized. If I have a query engine and I provide one data source that uses `ESPG:4326` and then I try to read data I thought was `ESPG:4326` from my Iceberg table, those CRS would no longer match. In my mind, it should be a query engine responsibility to determine that these are equivalent. In my mind, these types are opaque to Iceberg. We should simply know that the data is of type geometry/geography, and attach CRS and edge algorithm as metadata when record batches are streamed to the engine. I don't think we should do anything else. Happy to be convinced otherwise! Given there's so little on this topic that I can find, perhaps this can be a follow-up and we implement iceberg-rust with no interference on the provided values in the first iteration. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
