Ticket #68 (closed defect: fixed)

Opened 3 years ago

Last modified 3 years ago

Coordinates in geometry literals (strdf:WKT, geo:wktLiteral) are not interpeted in the correct order as implied by their associated CRS

Reported by: charnik Owned by: pyravlos-team
Priority: critical Milestone: Strabon v3.2.11
Component: generaldb Version: 3.2.9
Keywords: coordinates, axis order, CRS Cc:

Description (last modified by charnik) (diff)

We have hit the well known axis ordering confusion/problem that is frequently encountered between geographers and software engineers.

When geographers employ the CRS EPSG:4326 or WGS84, they interpret a given point on the surface of the Earth (a, b) by mapping "a" to latitude and "b" to longitude. Now, if you think of the meaning of latitude (parallels) and longitude (meridians) and bring into your mind a traditional coordinate system with axes X and Y, placing "a" on X and "b" on Y, then you end-up having South-North on the X axis and West-East on the Y axis.

Now, when software engineers are to interpet a point (a, b) on the surface of the Earth, they find reasonable to map the South-North direction to the Y axis and the West-East direction to the X axis. By doing so, they interpret "a" as longitude and "b" as latitude. Therefore, the definitions for CRS EPSG:4326 found in GIS software consider longitude as the first coordinate and latitude as the second one.

Now, the default CRS for strdf:WKT geometries is EPSG:4326. According to the official EPSG registry, EPSG:4326 (http://www.epsg-registry.org/report.htm?type=selection&entity=urn:ogc:def:crs:EPSG::4326&reportDetail=long&title=WGS%2084&style=urn:uuid:report-style:default-with-code&style_name=OGP%20Default%20With%20Code) has an axis ordering of latitude/longitude. However, since we are using PostGIS, which defines CRS EPSG:4326 with a longitude/latitude order, we end up storing such literals wrongly, since the latitude coordinate of such a literal is stored as longitude in the database and the longitude coordinate as latitude. Spatialreference.org defines EPSG:4326 with a long/lat ordering (like PostGIS): http://spatialreference.org/ref/epsg/wgs-84/.

Digital map providers such as Google Maps, Bing Maps, Yahoo Maps and the like, interpret EPSG:4326 coordinates correctly, that is, first latitude and then longitude. Interestingly enough, if one checks the KML file corresponding to a point interpreted as latitude/longitude by Google Maps, he will find out that the coordinates are reversed in the file. So, Google while it complies to the standards at the "interface" level, it does not opt for maintaining this at the implementation level. This is fair. But, now think of Strabon and suppose that we need to display on Google Maps a point expressed in strdf:WKT (lat/long). How are we going to reverse the coordinates? Currently, the KML writer uses the JTS transform function with the target CRS being EPSG:4326. But that should be officially lat/long and we need long/lat, and such as CRS does not exist, and GeoTools? respect the standards, so its definition for EPSG:4326 considers a lat/long ordering. We are not going to parse the dumm thing on our own!

Now, the default CRS for geo:wktLiteral geometries is CRS84 (this is an OGC naming of the WGS84 CRS that has the coordinates in reverse order, that is first longitude, then latitude). And guess what, CRS84 is EPSG:4326 of PostGIS, spatialreference.org, Oracle spatial, KML, epsg.io, QGIS (yes, I have confirmed that). So, the team preparing the GeoSPARQL standard knew pretty well what they were doing, when going at the opposite direction of EPSG. The were going in line with what all people use on a daily basis in their software. And they played well. They used an OGC CRS, that is specially crafted for the purpose of the problem, and thus they avoided further confusion. In the meantime, they had the support of the implementation at their hands, since all systems use a long/lat EPSG:4326 instead of the correct and standard-complint lat/long EPSG:4326 of EPSG.

In a nutshell:

  • If we use PostGIS's EPSG:4326 as the CRS of geo:wktLiteral, then we are OK for the default CRS of geo:wktLiteral. In the Strabon level, this corresponds to using the CoordinateReferenceSystem? DefaultGeographicCRS.WGS84 of GeoTools? (so we are OK).
  • For strdf:WKT, in Strabon we should use CRS.decode("EPSG:4326") in Geotools, which returns EPSG:4326 with a lat/long ordering (but, we should use the gt-epsg-hsql jar and certainly not the gt-epsg-wkt jar, which is currently the case). But, when we store such literals in PostGIS, they should be transformed to PostGIS 4326 (long/lat).
  • For the KML writer, we should use as a target CRS in JTS.transform() the CRS DefaultGeographicCRS.WGS84 of Geotools.
  • And we should also get rid of the forceXY call for GeoTools?.

All set (I think).

Ahh, we are working with SRIDs in Strabon, like 4326. This should change as well, because we will lose track of which 4326 of the two we are using.

This bug should be resolved before or together with Bug #67.

Change History

comment:1 Changed 3 years ago by charnik

  • Description modified (diff)

comment:2 Changed 3 years ago by charnik

As an alternative, we could consider CRS84 instead of EPSG:4326 as the default CRS for strdf:WKT and thus be also compliant with GeoSPARQL and the software industry. I think that this is the most wise thing to do.

comment:3 Changed 3 years ago by charnik

  • Status changed from new to closed
  • Resolution set to fixed

Please see the notes of changeset 1411:137486888a68.

Briefly:

  1. We keep a long/lat semantics for EPSG:4326.
  2. That makes it equivalent to OGC CRS84, but reversed with respect to map providers like Google Maps, Yahoo, and Bing Maps, geographers, and the EPSG registry.
  3. The reason is that PostGIS defines some of its functions (like ST_Buffer) by transforming in a hardcoded way the passed geometry to 4326, so we can not change its semantics in table

spatial_ref_sys.

  1. Another consequence of this choice is that from now on, there is no point in generating geo:wktLiteral prefixed with the EPSG:4326 URI. However, the order should stay the same.
Note: See TracTickets for help on using tickets.