[jira] [Commented] (SEDONA-312) Issue with st_transform function

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

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

Martin Desruisseaux commented on SEDONA-312:
--------------------------------------------

I'm not a Sedona maintainers, but there is some tips.

First a word of caution: The [http://epsg.io|http://epsg.io/] website is not authoritative. Despite its name, that web site is unrelated to EPSG or IOGP organizations. Some CRS definitions on [http://epsg.io|http://epsg.io/] are wrong, and it is not uncommon to receive false bug reports based on epsg.io definitions that appeared to be inaccurate (the last time on my side was last week). An EPSG maintainer told me that they would consider taking legal action against epsg.io if EPSG was not a not-for-profit organization. The official EPSG web site is [http://epsg.org|http://epsg.org/].

Unfortunately the official [http://epsg.org|http://epsg.org/] web site does not provide coordinate transformation services as far as I know. However the authoritative way to check if a coordinate transformation is correct or not is not to compare with [http://epsg.io|http://epsg.io/], but to check if the software passes the [Geospatial Integrity of Geoscience Software|https://gigs.iogp.org/] (GIGS) tests. Those tests are designed by the EPSG authors themselves. The status of GeoTools (the transformation engine used by Sedona) in this regard is unknown. The fact that GeoTools has a package name conflict with the OGC GeoAPI standard prevents the execution of GIGS tests on GeoTools.

A quick check on my side shows that the transformation between EPSG:2154 and EPSG:27572 should involve a datum shift between the _"Reseau Geodesique Francais 1993"_ and _"Nouvelle Triangulation Francaise (Paris)"_ datums, which is done by the _"Geocentric translation by Grid Interpolation (IGN)"_ operation method. One possible cause for the discrepancies observed in this issue may be that this datum shift is not applied. It can be verified by printing the Well Known Text (WKT) of the {{CoordinateOperation}} (not the {{{}CoordinateReferenceSystem{}}}). It should contain something like below (exact syntax may vary):
{code:java}
Method["Geocentric translation by Grid Interpolation (IGN)"],
  Parameter["Geocentric translation file", "gr3df97a.txt"],
  Parameter["Interpolation CRS code", 4171],
  Parameter["Standard CT code", 1651],
{code}
If above block is absent and if there is no substitute (for example based on NTv2 instead of geocentric translation), then there is two possible explanations:
 * _"Geocentric translation by Grid Interpolation (IGN)"_ may be unsupported by GeoTools (I do not know if this is the case or not).
 * The operation is supported but the {{"gr3df97a.txt"}} file (or is substitute) is absent.

Note: some users requested that the coordinate transformation library should download the datum shift grid file automatically when requested. This discussion is still ongoing. A recent OGC work, the [Gridded Geodetic data eXchange Format|https://github.com/opengeospatial/CRS-Gridded-Geodetic-data-eXchange-Format] (GGXF), is a step in that direction.

> Issue with st_transform function
> --------------------------------
>
>                 Key: SEDONA-312
>                 URL: https://issues.apache.org/jira/browse/SEDONA-312
>             Project: Apache Sedona
>          Issue Type: Bug
>            Reporter: sana
>            Priority: Urgent
>
> Hello,
> We are encountering an issue with the st_transform function in Apache Sedona when using the following query:
> {code:java}
> ST_Transform(ST_Point(1203119.502, 6077637.153), 'epsg:2154', 'epsg:27572', true){code}
> The result we are obtaining is:
> {code:java}
> POINT (1158991.8427439178 1648676.1678296784){code}
> However, when verifying the result using [https://epsg.io/transform#s_srs=2154&t_srs=27572&x=1203119.5020000&y=6077637.1530000], the expected result should be:
> {code:java}
> POINT (1159055.4831757052 1648321.6317446362){code}
> This issue has a significant impact on our geospatial applications. The incorrect transformation result affects the accuracy and reliability of our data. It hinders our ability to rely on Apache Sedona's st_transform function for our geospatial processing needs.
> Your prompt attention to this matter is greatly appreciated. Let me know if there is any additional information or assistance required.
> Thank you!



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