[jira] [Commented] (SEDONA-356) Change CRS transformation from lat/lon to lon/lat order

["Martin Desruisseaux (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SEDONA-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753970#comment-17753970 ] 

Martin Desruisseaux commented on SEDONA-356:
--------------------------------------------

We may need to be careful about that one. It depends on the context. If the CRS is specified by an EPSG code, it should generally be handled with axis order as specified by EPSG. It is sometime (lat,lon), sometime (lon,lat), sometime more exotic. This not necessarily chaos, we should see that as localization in the same way that the (year/month/day) fields in a date appear in different order depending on the country.

If the geometries come from a PostGIS-like database, then the CRS codes are not EPSG codes, but rather {{"spatial_ref_sys"}} codes. Even if they are numerically the same, they are not semantically the same. This is not the same column in the {{"spatial_ref_sys"}} table. So what we often call {{"EPSG:4326"}} is actually {{"PostGIS:4326"}} (with {{"PostGIS"}} invented in this comment. I'm not aware of a well-established practice for meaning _"the primary key of the {{spatial_ref_sys}} table"_ instead of _"the EPSG authority"_). Those PostGIS codes are indeed (lon,lat). This is okay, as long as they are not confused with EPSG.

If the CRS come from a GeoTIFF file, that format indeed uses explicitly EPSG codes forced to (lon,lat) axis order. This is that way for historical reasons (the OGC GeoTIFF specification has an annex about that) but not something that OGC would like to see replicated in new formats. For example, when the GeoJSON format was invented by the open source community, that community replicated the GeoTIFF approach (EPSG codes forced to lon,lat axis order). At OGC, it was considered problematic for a new standard. So the compromise has been to remove CRS definition from GeoJSON for now (better to have a hole that we will try to fill later than to have something broken becoming impossible to fix).

In summary, it is okay to use (lon,lat) axis order as long as we do not pretend that they are EPSG definitions. They may be PostGIS or GeoTIFF definitions. Or we may call them _"Derived from EPSG"_. This is similar to Apache licensing policy, where a user modifying an Apache software may call it _"Derived from Apache Foo"_ but not _"Apache Foo"_ anymore.

h2. Note on other axis properties
Axis order is not the only issue. There is also axis directions and units. Some geographic CRS in Australia and in Africa have latitudes oriented toward south instead of north. Some historical CRS in USA have longitude oriented toward west instead of east. At the north pole all axes are oriented toward south, and at the south pole all axes are oriented toward north. Some historical CRS in France uses grads instead of degrees. The EPSG database describes all this complexity. It is legitimate to want to normalize to (east, north) directions with degrees unit in some cases, but this is not always a good description of reality (especially at poles) or practice. The important thing is that those modified CRS are not confused with EPSG CRS. I would also recommend that, even if normalized (east, north) axes are used for computational purposes, to use EPSG axis order, direction and units in Graphical User Interfaces. This is because EPSG definitions correspond to what pilot or geographer users of the CRS country would expect.

> Change CRS transformation from lat/lon to lon/lat order
> -------------------------------------------------------
>
>                 Key: SEDONA-356
>                 URL: https://issues.apache.org/jira/browse/SEDONA-356
>             Project: Apache Sedona
>          Issue Type: Task
>            Reporter: Jia Yu
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> This task to make the behavior of ST_Transform be consistent with other libraries. With this solved, ST_Transform/CRStransform will follow lon/lat order, instead of lat/lon order.
>  
> Users no longer need to use flipCoordinates to workaround.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)