[
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)
