paleolimbot commented on code in PR #2933: URL: https://github.com/apache/iceberg-rust/pull/2933#discussion_r3960340899
########## 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: In SedonaDB (my PR) we have the ability to implement equality checks between arbitrary CRS representations, so it's fine to keep the original CRS representation. You don't have that here, so your users are going to have a hard time if you don't normalize on write. The Parquet files that get written will have both of those CRSes normalized (as per arrow-rs's conversion), as will any that go through Arrow C++'s writer (or DuckDB's), so you'll have an iceberg schema that doesn't match the Parquet files being written. Basically this is picking between two less than perfect pieces of making pieces of the spatial domain iceberg-rust's problem: you can normalize the most common form of incompatible CRSes that both map to the default, or you can implement CRS equivalence (or allow injecting a proper implementation of it). -- 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]
