desruisseaux commented on issue #10260: URL: https://github.com/apache/iceberg/issues/10260#issuecomment-2249997624
To summarize: Next to the _"Coordinate Reference System, ie mapping of how coordinates refer to precise locations on earth"_ sentences, it may be worth to said that OGC:CRS84 has an [accuracy of 2 meters](https://epsg.org/datum_6326/World-Geodetic-System-1984-ensemble.html) for avoiding the impression that "precise location" means "unlimited" accuracy. I would not recommend PROJJSON, unless there is a requirement to use JSON in text fields. PROJJSON is not a standard, it is specific to one particular project. A standard CRS JSON encoding is planed, but may not be ready before 2 years. In the meantime, the most widely supported CRS encoding is [ISO 19162](https://www.iso.org/standard/86172.html) (a.k.a. "WKT 2"). The latter is supported by PROJ, Apache SIS and ESRI software, to name only the ones that I know. JTS is a popular library, but I would recommend to nevertheless keep a degree of freedom for allowing the co-existence of different libraries. Because: * JTS is designed for Cartesian coordinate systems, while "GeoIceberg" phase 1 uses an ellipsoidal coordinate system (OGC:CRS84). Ignoring that fact and using JTS with latitudes and longitudes anyway is a common practice, but risky. Calculations (including interpolations) may look plausible on screen, but with higher risk of being at odd with reality compared to using the right library with the right coordinate system. Even `ST_Intersects` can be wrong near the edges. * The need to have 2 coexisting libraries is real. For example, JTS for projected CRS and Google S2 for geographic CRS. * Alternative libraries such as [ESRI geometry API](https://github.com/Esri/geometry-api-java) should not be neglected given ESRI importance in governments. * Every software has bugs. We also use JTS for most of our work on our side, but nevertheless sometimes need to switch to another library for some calculations where JTS have issues. Hence, the possibility to use Apache SIS with either JTS, ESRI or Java2D (still useful for Bezier curves), at user's choice. * OGC Moving Features is becoming more and more important. For example, [MobilityDB](https://mobilitydb.com/) is a PostGIS extension for moving features. In this context, geometries like "line string" become "trajectory" with new set of operations. JTS can store _z_ and _m_ coordinates, but the handling of time in a moving feature is more than just storing the coordinate values. Maybe JTS will support Moving Feature operations in a future version, or maybe not. -- 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: issues-unsubscr...@iceberg.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org For additional commands, e-mail: issues-h...@iceberg.apache.org
