BlakeOrth commented on code in PR #8801:
URL: https://github.com/apache/arrow-rs/pull/8801#discussion_r2504903664
##########
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 {
+ Projjson(serde_json::Value),
+ Srid(u64),
+ Other(String),
+}
Review Comment:
Yes, this is following the Parquet CRS. I figured since it was in the
`parquet-geospatial` sub-crate the spec being `parquet` would be understood.
I'm glad you noted this, because it seems my assumption was incorrect. :smile:
Based on our previous conversation here
https://github.com/apache/arrow-rs/pull/8222#discussion_r2299035292 I thought
using the Parquet CRS seems like the safest option for users. Since the
GeoArrow CRS allows a truly unspecified/unknown option and Parquet does not,
it's not always safe to serialize GeoArrow as Parquet.
As a user, I think I would personally like to know and handle that case
rather than have some unspecified GeoArrow be serialized an blindly interpreted
as `OGC:CRS84`. This is, of course, just a personal preference. I know there
are plenty of real-world users who would probably prefer a "best effort"
approach and would like to just deal with incorrect metadata later. All that
being said, I would be willing to adopt a more lenient approach if we think
that's a better course of action.
--
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]
