You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@sis.apache.org by MUELLER-SCHRAMM Gerd <ge...@hexagon.com> on 2020/08/25 12:42:38 UTC
Transformation from EPSG:2154 to EPSG:28992
Hi,
I’m trying to transform the coordinates from EPSG:2154 to EPSG:28992 but it seems that I don’t get a correct result.
E.g. for (926713.7022916666, 7348947.025885417) it should be (220798.684126, 577583.800638) according to several online transformation tools and Proj4J.
But even the Apache SIS 1.0 I get (220762.48670102577, 577396.039844773).
Is this a bug or do I something wrong? I’ve attached a small test program.
Thanks and regards,
Gerd
Gerd Müller-Schramm
Software Developer, GeoMedia Smart Client Kommunal
T: +49 (0) 89 96 106 4117
E: gerd.mueller-schramm@hexagon.com<ma...@hexagongeospatial.com>
HxGN Safety & Infrastructure GmbH
Wittenberger Straße 15B
04129 Leipzig, Germany
hexagon.com<http://www.hexagon.com/>
HxGN SI is part of HEXAGON<http://www.hexagon.com/>
Re: Transformation from EPSG:2154 to EPSG:28992
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 01/09/2020 à 09:38, MUELLER-SCHRAMM Gerd a écrit :
> Thanks for the fix. I've tried it and it works nice.
>
Thanks for letting us know. I forgot to add that the fix will report an
accuracy of 3000 metres instead of 100 metres if the EPSG database is
not installed, because otherwise it has no way to know the datum domain
of validity (unless WKT 2 is used instead of WKT 1).
Martin
RE: Transformation from EPSG:2154 to EPSG:28992
Posted by MUELLER-SCHRAMM Gerd <ge...@hexagon.com>.
Hi Matrin,
Thanks for the fix. I've tried it and it works nice.
Regards,
Gerd
Gerd Müller-Schramm
Software Developer, GeoMedia Smart Client Kommunal
Hexagon Geospatial
Hexagon
T: +49 (0) 89 96 106 4117
E: gerd.mueller-schramm@hexagon.com
Office: HxGN Safety & Infrastructure GmbH
Wittenberger Straße 15B
04129 Leipzig
Germany
hexagon.com
-----Original Message-----
From: Martin Desruisseaux <ma...@geomatys.com>
Sent: Montag, 31. August 2020 23:12
To: user@sis.apache.org
Subject: Re: Transformation from EPSG:2154 to EPSG:28992
This email is not from Hexagon’s Office 365 instance. Please be careful while clicking links, opening attachments, or replying to this email.
Hello Gerd
The proposed fix has been pushed. It can be tested with SIS 1.1-SNAPSHOT on the following Maven repository:
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Fgroups%2Fsnapshots%2F&data=02%7C01%7C%7C89ad2ec3a346494cc7b508d84df29192%7C1b16ab3eb8f64fe39f3e2db7fe549f6a%7C0%7C0%7C637345051522319770&sdata=oTg4vi9H1cWVlpLw99BqsLwB5%2F4NQWfEgQ17om12Lo0%3D&reserved=0
Regards,
Martin
Re: Transformation from EPSG:2154 to EPSG:28992
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello Gerd
The proposed fix has been pushed. It can be tested with SIS 1.1-SNAPSHOT
on the following Maven repository:
https://repository.apache.org/content/groups/snapshots/
Regards,
Martin
Re: Transformation from EPSG:2154 to EPSG:28992
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 27/08/2020 à 14:37, MUELLER-SCHRAMM Gerd a écrit :
> Your proposal sound plausible to me.
>
Thanks for the feedback. If no other comments, I will apply it this
weekend. I will cherry-pick the fix on Apache SIS master branch, so it
should be testable with a "mvn install" command if desired.
Martin
RE: Transformation from EPSG:2154 to EPSG:28992
Posted by MUELLER-SCHRAMM Gerd <ge...@hexagon.com>.
Hi Martin,
Your proposal sound plausible to me.
Regards,
Gerd
Gerd Müller-Schramm
Software Developer, GeoMedia Smart Client Kommunal
T: +49 (0) 89 96 106 4117
E: gerd.mueller-schramm@hexagon.com<ma...@hexagongeospatial.com>
HxGN Safety & Infrastructure GmbH
Wittenberger Straße 15B
04129 Leipzig, Germany
hexagon.com<http://www.hexagon.com/>
HxGN SI is part of HEXAGON<http://www.hexagon.com/>
From: Martin Desruisseaux <ma...@geomatys.com>
Sent: Donnerstag, 27. August 2020 01:10
To: user@sis.apache.org
Subject: Re: Transformation from EPSG:2154 to EPSG:28992
This email is not from Hexagon’s Office 365 instance. Please be careful while clicking links, opening attachments, or replying to this email.
Hello Gerd
But how is accuracy determined? I've tried two other CRS: 31467 and 25832 and the accuracy is also 3000 although there areas overlap.
The EPSG dataset provides an accuracy estimation for all transformations defined in the database. So currently the rules implemented in Apache SIS are as below:
* If a transformation is found in the EPSG database for a given pair of CRS, uses the accuracy declared by EPSG. Those values range from a few centimetres to a few tenths of metres.
* Otherwise if Bursa-Wolf parameters can be applied directly for the given pair of CRS, arbitrarily declare an accuracy of 25 metres. This value corresponds to the largest accuracy I found in the EPSG database, so I took it as a "worst case" scenario.
* Otherwise (no Bursa-Wolf parameters applied, either because not specified or because they do not provide a direct path), arbitrarily declare an accuracy of 3 km. This value corresponds to the largest error I found empirically by comparing transformations with and without Bursa-Wolf parameters. I found that maximal error on Réunion Island.
I'm thinking to amend above rules with the following:
* If an indirect path is found (typically A → WGS84 → B), then:
* If the domains of validity of both CRS intersect, arbitrarily declare an accuracy of 100 metres. I take the "worst case" scenario of two CRS with Bursa-Wolf (25 metres + 25 metres), and double the result by paranoia because we have no reference like EPSG who have done the accuracy analysis.
* Otherwise apply the indirect path anyway, but declares an accuracy of 3 km (i.e. the same amount as if no Bursa-Wolf parameters were available) because we do not know if doing "A → WGS84 → B" in such case is valid.
What do you think of above proposal?
Regarding your question about a safeguard for CRS that are too far apart: wouldn’t there be some kind of out of range exception if the coordinate to transform is too far away from the area of the target CRS?
A difficulty is to define "too far". Another issue is that doing this check at MathTransform.transform(…) invocation time would have performance penalty. I was thinking to apply a check like that at CRS.findOperation(…) invocation time, but have not yet figured out a reliable way. A difficulty is that the domain of validity is often unspecified, e.g. when the CRS was declared by WKT.
Maybe we can revisit the "safeguard" question another time, if someone come with an idea.
Regards,
Martin
Re: Transformation from EPSG:2154 to EPSG:28992
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello Gerd
> But how is accuracy determined? I've tried two other CRS: 31467 and
> 25832 and the accuracy is also 3000 although there areas overlap.
>
The EPSG dataset provides an accuracy estimation for all transformations
defined in the database. So currently the rules implemented in Apache
SIS are as below:
* If a transformation is found in the EPSG database for a given pair
of CRS, uses the accuracy declared by EPSG. Those values range from
a few centimetres to a few tenths of metres.
* Otherwise if Bursa-Wolf parameters can be applied directly for the
given pair of CRS, arbitrarily declare an accuracy of 25 metres.
This value corresponds to the largest accuracy I found in the EPSG
database, so I took it as a "worst case" scenario.
* Otherwise (no Bursa-Wolf parameters applied, either because not
specified or because they do not provide a direct path), arbitrarily
declare an accuracy of 3 km. This value corresponds to the largest
error I found empirically by comparing transformations with and
without Bursa-Wolf parameters. I found that maximal error on Réunion
Island.
I'm thinking to amend above rules with the following:
* If an indirect path is found (typically A → WGS84 → B), then:
o If the domains of validity of both CRS intersect, arbitrarily
declare an accuracy of 100 metres. I take the "worst case"
scenario of two CRS with Bursa-Wolf (25 metres + 25 metres), and
double the result by paranoia because we have no reference like
EPSG who have done the accuracy analysis.
o Otherwise apply the indirect path anyway, but declares an
accuracy of 3 km (i.e. the same amount as if no Bursa-Wolf
parameters were available) because we do not know if doing "A →
WGS84 → B" in such case is valid.
What do you think of above proposal?
> Regarding your question about a safeguard for CRS that are too far
> apart: wouldn’t there be some kind of out of range exception if the
> coordinate to transform is too far away from the area of the target CRS?
>
A difficulty is to define "too far". Another issue is that doing this
check at MathTransform.transform(…) invocation time would have
performance penalty. I was thinking to apply a check like that at
CRS.findOperation(…) invocation time, but have not yet figured out a
reliable way. A difficulty is that the domain of validity is often
unspecified, e.g. when the CRS was declared by WKT.
Maybe we can revisit the "safeguard" question another time, if someone
come with an idea.
Regards,
Martin
RE: Transformation from EPSG:2154 to EPSG:28992
Posted by MUELLER-SCHRAMM Gerd <ge...@hexagon.com>.
Hi Martin,
In my code I've tried the following approach: if accuracy of direct transformation A -> B is smaller than accuracy(A -> WGS84) + accuracy(WGS84 -> B) then I use the direct transformation. This works well for my case.
But how is accuracy determined? I've tried two other CRS: 31467 and 25832 and the accuracy is also 3000 although there areas overlap.
Regarding your question about a safeguard for CRS that are too far apart: wouldn’t there be some kind of out of range exception if the coordinate to transform is too far away from the area of the target CRS?
Regards,
Gerd
Gerd Müller-Schramm
Software Developer, GeoMedia Smart Client Kommunal
T: +49 (0) 89 96 106 4117
E: gerd.mueller-schramm@hexagon.com
HxGN Safety & Infrastructure GmbH
Wittenberger Straße 15B
04129 Leipzig, Germany
hexagon.com
HxGN SI is part of HEXAGON
-----Original Message-----
From: Martin Desruisseaux <ma...@geomatys.com>
Sent: Dienstag, 25. August 2020 17:19
To: MUELLER-SCHRAMM Gerd <ge...@hexagon.com>
Cc: user@sis.apache.org
Subject: Re: Transformation from EPSG:2154 to EPSG:28992
This email is not from Hexagon’s Office 365 instance. Please be careful while clicking links, opening attachments, or replying to this email.
Hello Gerd!
Le 25/08/2020 à 14:42, MUELLER-SCHRAMM Gerd a écrit :
> I’m trying to transform the coordinates from EPSG:2154 to EPSG:28992
> but it seems that I don’t get a correct result.E.g. for
> (926713.7022916666, 7348947.025885417) it should be (220798.684126,
> 577583.800638) according to several online transformation tools and
> Proj4J.But even the Apache SIS 1.0 I get (220762.48670102577,
> 577396.039844773).
>
> Is this a bug or do I something wrong? I’ve attached a small test program.
>
Thanks for the test, I just investigated. This issue has a little bit of history. The test performs a coordinate transformation between datum of
2 different countries:
Source:
Réseau Géodésique Français 1993 (EPSG:6171)
Domain of validity: France - onshore and offshore, mainland and Corsica.
Target:
Amersfoort (EPSG:6289)
Domain of validity: Netherlands - onshore, including Waddenzee,
Dutch Wadden Islands and 12-mile offshore coastal zone.
The EPSG database does not define coordinate transformation between those two countries. In such case, Apache SIS or PROJ have to guess what the coordinate transformation may be. The WKTs in the test contain
TOWGS84 elements, but WGS84 is not the datum of any of the CRS involved in this coordinate operation. In other words, the TOWGS84 elements in this test do not define a *direct* transformation. They could be used for an indirect transformation however, as below:
EPSG:6171 → WGS84 → EPSG:6289
Actually Apache SIS was applying such indirect transformation in a previous version. This feature has been removed in October 2013 because it was considered "dangerous" (more on it below) and had (at that time) undesirable effects like taking precedence over the more direct transformations defined in EPSG database. On the other side, PROJ4J and PROJ versions before PROJ 6 applies the indirect transformation systematically (without querying EPSG database) even if a direct transform exists, which causes other problems. Removing that systematic use of WGS84 was one of the main purposes of PROJ 6 effort.
I just tried to reintroduce support for indirect transformation (through
WGS84) when no direct transformation is found and I got the same results than PROJ4J / online tools. I can commit this change (I think the above-cited interaction problem with EPSG database does not occur anymore). The "danger" however is to give a false sense of accuracy.
"EPSG:6171 → WGS84" may be valid for coordinates inside the EPSG:6171 domain of validity, and "WGS84 → EPSG:6289" may be valid for coordinates inside the EPSG:6289 domain of validity, but the "EPSG:6171 → WGS84 → EPSG:6289" chain may be invalid if those domains of validity do not intersect. In this particular case the result may be not too bad because the two countries are not too far apart, but the transformation result may be erratic if an indirect transformation is applied between local datum separated by a large distance.
The Apache SIS policy after October 2013 became to not use Bursa-Wolf parameters if not defined in a direct transformation. Instead, SIS declares a large coordinate operation uncertainty. It can be verified with the following code:
CoordinateOperation op = CRS.findOperation(epsg2154, epsg28992, null);
System.out.println(CRS.getLinearAccuracy(op));
Which prints 3000 meters when no Bursa-Wolf parameters have been applied
(3 km error is the worst case scenario I have observed). The errors observed in this test are within that range. However I agree that applying the indirect transformation may be a "less bad" strategy, but I do not know which uncertainty to declare in that case. The PROJ4J results are not "correct"; they are within some distance of the real value, and I do not know what this distance is.
So to summarize, I propose to reintroduce the use of indirect transformation (of the form A → WGS84 → B) when Apache SIS did not found a better path, but we need to decide:
* Which accuracy to declare.
* Do we need safeguard against CRS that should not be connected (i.e.
disallow "A → WGS84 → B" when A and B are too far apart)?
Martin
Re: Transformation from EPSG:2154 to EPSG:28992
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello Gerd!
Le 25/08/2020 à 14:42, MUELLER-SCHRAMM Gerd a écrit :
> I’m trying to transform the coordinates from EPSG:2154 to EPSG:28992
> but it seems that I don’t get a correct result.E.g. for
> (926713.7022916666, 7348947.025885417) it should be (220798.684126,
> 577583.800638) according to several online transformation tools and
> Proj4J.But even the Apache SIS 1.0 I get (220762.48670102577,
> 577396.039844773).
>
> Is this a bug or do I something wrong? I’ve attached a small test program.
>
Thanks for the test, I just investigated. This issue has a little bit of
history. The test performs a coordinate transformation between datum of
2 different countries:
Source:
Réseau Géodésique Français 1993 (EPSG:6171)
Domain of validity: France - onshore and offshore, mainland and Corsica.
Target:
Amersfoort (EPSG:6289)
Domain of validity: Netherlands - onshore, including Waddenzee,
Dutch Wadden Islands and 12-mile offshore coastal zone.
The EPSG database does not define coordinate transformation between
those two countries. In such case, Apache SIS or PROJ have to guess what
the coordinate transformation may be. The WKTs in the test contain
TOWGS84 elements, but WGS84 is not the datum of any of the CRS involved
in this coordinate operation. In other words, the TOWGS84 elements in
this test do not define a *direct* transformation. They could be used
for an indirect transformation however, as below:
EPSG:6171 → WGS84 → EPSG:6289
Actually Apache SIS was applying such indirect transformation in a
previous version. This feature has been removed in October 2013 because
it was considered "dangerous" (more on it below) and had (at that time)
undesirable effects like taking precedence over the more direct
transformations defined in EPSG database. On the other side, PROJ4J and
PROJ versions before PROJ 6 applies the indirect transformation
systematically (without querying EPSG database) even if a direct
transform exists, which causes other problems. Removing that systematic
use of WGS84 was one of the main purposes of PROJ 6 effort.
I just tried to reintroduce support for indirect transformation (through
WGS84) when no direct transformation is found and I got the same results
than PROJ4J / online tools. I can commit this change (I think the
above-cited interaction problem with EPSG database does not occur
anymore). The "danger" however is to give a false sense of accuracy.
"EPSG:6171 → WGS84" may be valid for coordinates inside the EPSG:6171
domain of validity, and "WGS84 → EPSG:6289" may be valid for
coordinates inside the EPSG:6289 domain of validity, but the "EPSG:6171
→ WGS84 → EPSG:6289" chain may be invalid if those domains of
validity do not intersect. In this particular case the result may be not
too bad because the two countries are not too far apart, but the
transformation result may be erratic if an indirect transformation is
applied between local datum separated by a large distance.
The Apache SIS policy after October 2013 became to not use Bursa-Wolf
parameters if not defined in a direct transformation. Instead, SIS
declares a large coordinate operation uncertainty. It can be verified
with the following code:
CoordinateOperation op = CRS.findOperation(epsg2154, epsg28992, null);
System.out.println(CRS.getLinearAccuracy(op));
Which prints 3000 meters when no Bursa-Wolf parameters have been applied
(3 km error is the worst case scenario I have observed). The errors
observed in this test are within that range. However I agree that
applying the indirect transformation may be a "less bad" strategy, but I
do not know which uncertainty to declare in that case. The PROJ4J
results are not "correct"; they are within some distance of the real
value, and I do not know what this distance is.
So to summarize, I propose to reintroduce the use of indirect
transformation (of the form A → WGS84 → B) when Apache SIS did not
found a better path, but we need to decide:
* Which accuracy to declare.
* Do we need safeguard against CRS that should not be connected (i.e.
disallow "A → WGS84 → B" when A and B are too far apart)?
Martin