jiayuasu opened a new issue, #3150: URL: https://github.com/apache/sedona/issues/3150
## Expected behavior GeoParquet column CRS metadata should preserve the PROJJSON field names exactly as stored. When a top-level PROJJSON `id` declares an EPSG identifier, Sedona should restore that positive SRID without requiring the CRS object to contain every field needed to instantiate a projection. ## Actual behavior `GeoParquetMetaData.parseKeyValueMetaData` recursively camelizes the parsed metadata before extracting each geometry column. This also rewrites nested PROJJSON keys such as `base_crs`, `semi_major_axis`, `inverse_flattening`, `conversion_factor`, and `coordinate_system`. `GeoParquetMetaData.extractSridFromCrs` then constructs a projection to recover the declared authority and code. Besides doing unnecessary work, this requires a complete executable CRS definition even though GeoParquet only needs the top-level identifier to restore the geometry SRID. With the current proj4sedona behavior, GeoParquet round trips using a non-default SRID can consequently fail or lose the SRID. ## Steps to reproduce the problem 1. Create a geometry column with a non-default SRID such as EPSG:32632. 2. Write it as GeoParquet so Sedona generates PROJJSON CRS metadata. 3. Parse the written `geo` metadata or read the GeoParquet file. 4. Observe that nested PROJJSON keys have been converted to camel case and that SRID recovery depends on successfully constructing the full projection. ## Settings Sedona version = `1.9.1-SNAPSHOT` at `70881d6ef9f1` Apache Spark version = 3.4 Apache Flink version = N/A API type = Scala Scala version = 2.12 JRE version = 11.0.29 Python version = N/A Environment = Standalone macOS -- 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]
