Kontinuation commented on issue #941: URL: https://github.com/apache/sedona/issues/941#issuecomment-1710981065
`RS_FromGeoTiff` reads CRS metadata from the GeoTiff file, and the resulting raster value will have that CRS property. You can retrieve the EPSG code of the CRS using `RS_SRID` (if it has one). `RS_FromGeoTiff` is using GeoTools GeoTiff reader under the hood. However, I've not found any documentation describing the limitation of GeoTools GeoTiff reader. The limitation I am aware of is that it does not support user defined Model CRS type (GTModelTypeGeoKey = 32767, see [Requirements Class GTModelTypeGeoKey](https://docs.ogc.org/is/19-008r4/19-008r4.html#_requirements_class_gtmodeltypegeokey)). For vector data, the default SRID is 0, which indicates that the geometry does not have a defined CRS. `ST_GeomFromGeoJSON` does not support parsing the crs member in GeoJSON, and the resulting geometries always have SRID = 0. SRID is the EPSG code of coordinate reference systems. The CRS is forced to easting/northing or lon/lat axis order since https://github.com/apache/sedona/pull/963, which will be released with 1.5.0. For any released versions of Apache Sedona, the CRS uses the original axis order defined by EPSG. I think explicitly documenting the behaviors related to CRS would be beneficial. As we integrate raster support into Apache Sedona, this aspect is gaining increasing significance. -- 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]
