dannycjones commented on code in PR #2933: URL: https://github.com/apache/iceberg-rust/pull/2933#discussion_r4040069547
########## 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: Thanks for taking the time to explain this - that example is compelling. I can imagine anything talking Arrow passing record batches to Iceberg Rust which should then be able to commit the record batches to the table. The consequence I am worried about is that if iceberg-rust canonicalizes the schema some table mapping `EPSG:4326` to `OGC:CRS84`, it would not longer be possible to write into that table from another library that doesn't perform any canonicalization or equivalence and expects a column with `EPSG:4326`. I think there's two things conflated here also: the Iceberg schema representation itself in `metadata.json`, and the Arrow schemas used when reading and writing data. Given there's nothing in the spec discussing equivalence or canonicalization, I'm inclined to leave both out of the first geo PRs and instead just implement simply pass through with basic normalization (i.e. `geometry(OGC:CRS84)` might become `geometry(ogc:crs84)`, or `geometry` becomes `geometry(ogc:crs84)`). I'd rather see a follow-up with Iceberg community consensus to both treat these as equivalent, but also to (optionally?) canonicalize. In the meantime, I think we can move forward with the simple case passing through with basic normalization so the PR isn't blocked. -- 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]
