BlakeOrth commented on code in PR #8801:
URL: https://github.com/apache/arrow-rs/pull/8801#discussion_r2505021540
##########
parquet-geospatial/src/crs.rs:
##########
@@ -0,0 +1,97 @@
+use std::{collections::HashMap, sync::Arc};
+
+use arrow_schema::{Schema, SchemaBuilder};
+use serde_json::{Value, json};
+
+#[derive(Debug)]
+pub enum Crs {
Review Comment:
I agree your proposed struct definition would better unify the parquet and
arrow CRS definitions. I believe this is exactly what @kylebarron has in
`geoarrow-rs` as well. Using that CRS struct definition could also get us some
"free" serialization/deserialization if we leveraging `serde` traits, which
could be nice.
While I agree the conversion code isn't any more clear (perhaps the
opposite, really), using the `enum` does buy us some additional safety. Users
of the enum get compile time checks that they've handled all possible cases,
and it's "impossible" (outside of a glaring bug) to accidentally have a
mismatch between the `crs_type` and the actual `crs`data. We also get some
additional strong typing of the crs data, which I personally prefer. Again,
this is mostly my preferred way of working with data, so if we end up thinking
a less rigorous approach is more broadly appealing I'm happy to change course!
--
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]
