jiayuasu opened a new issue, #3103: URL: https://github.com/apache/sedona/issues/3103
## Expected behavior `RS_CRS(raster, "proj")` should be idempotent: exporting a raster's CRS to a PROJ string, re-importing it with `RS_SetCRS`, and re-exporting should yield the identical PROJ string (the property `CrsRoundTripComplianceTest.assertProjRoundTrip` checks as `export2 == export3`). ## Actual behavior For several projected CRSs the second and third exports disagree, because Sedona's raster CRS bridge (`CrsNormalization` / `RasterAccessors.crs` + `RasterEditors.setCrs`) takes **two different export paths** depending on the shape of the CRS string being imported — a `+datum=` code vs an explicit `+towgs84=` list, and an EPSG-backed CRS vs a raw PROJ string. The two paths format the ellipsoid/datum differently, so the round trip is not byte-stable. This was latent and masked while the project depended on proj4sedona 0.0.8: both export paths produced the same (coarser) output. proj4sedona 0.1.0 improved PROJ-string serialization (short projection codes, PROJ-canonical `+datum=`/`+towgs84=` in human units — arc-seconds/ppm), which made the two paths diverge and surfaced the pre-existing routing inconsistency. **Coordinate transforms are unaffected** — `FunctionsProj4Test` passes 43/43 including a new WGS84↔EPSG:5880 case; this is purely about the stability of the exported CRS *string*. Two distinct symptoms: **A. towgs84 emitted in internal units by one path.** EPSG:27700 (also 28992, 3111): ``` export1: +proj=tmerc ... +ellps=airy +datum=OSGB36 +no_defs export2: +proj=tmerc ... +ellps=airy +towgs84=446.448,-125.157,542.06,7.28E-7,1.197E-6,4.083E-6,0.999979511 +no_defs # radians + scale multiplier (internal units) export3: +proj=tmerc ... +ellps=airy +towgs84=446.448,-125.157,542.06,0,0,0,1.000001 +no_defs # proj4sedona serializer, human units ``` Importing `+datum=OSGB36` expands the datum to a 7-parameter towgs84; one export path writes those parameters in proj4sedona's internal units (rotations in radians, scale as a multiplier), while proj4sedona's own serializer writes them in PROJ's human units (arc-seconds/ppm). The two never agree. **B. WKT method name and dropped standard parallels for `+proj=aea`.** EPSG:5070 (also 3577): ``` export1: +proj=aea +lat_0=23 +lon_0=-96.0 +lat_1=29.5 +lat_2=45.5 +ellps=GRS80 +datum=NAD83 +no_defs export2: +proj=Albers_Conic_Equal_Area +lat_0=23 +lon_0=-96.0 +ellps=GRS80 +datum=NAD83 +no_defs # WKT method name as +proj=, +lat_1/+lat_2 dropped export3: (throws) Cannot parse CRS string ... Input: +proj=Albers_Conic_Equal_Area ... ``` Re-exporting a parsed `+proj=aea` CRS produces `+proj=Albers_Conic_Equal_Area` (the WKT/GeoTools operation-method name, not the PROJ short code `aea`) and drops the two required standard parallels, yielding a string proj4sedona cannot re-parse. ## Steps to reproduce the problem With proj4sedona 0.1.0 (PR apache/sedona#3102): ```java GridCoverage2D base = RasterConstructors.makeEmptyRaster(1, 4, 4, 0, 0, 1); GridCoverage2D r1 = RasterEditors.setCrs(base, "EPSG:27700"); String e1 = RasterAccessors.crs(r1, "proj"); String e2 = RasterAccessors.crs(RasterEditors.setCrs(base, e1), "proj"); String e3 = RasterAccessors.crs(RasterEditors.setCrs(base, e2), "proj"); // e2 != e3 (towgs84 internal units vs human units) ``` `CrsRoundTripComplianceTest` covers 27700, 28992, 3111 (symptom A) and 5070, 3577 (symptom B). Likely fix area: `common/.../raster/CrsNormalization.java` — route CRS export through a single path (proj4sedona's `CRSSerializer`) regardless of whether the source CRS came from an EPSG code, a `+datum=` string, or a raw PROJ string, so the ellipsoid/datum/towgs84 formatting is consistent. ## Settings Sedona version = 1.9.0-SNAPSHOT (master), surfaced by the proj4sedona 0.0.8 → 0.1.0 bump (apache/sedona#3102) Apache Spark version = all (failure is in the `common` module, Spark-independent) API type = Java JRE version = 11 and 17 (all CI combinations) Environment = CI (GitHub Actions) and local -- 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]
