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