You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by HRUDA Steve <st...@hexagongeospatial.com> on 2018/01/26 17:35:34 UTC
RE: Transformation differences between Apache SIS version 0.7 and 0.8
Hi,
I recognized that Apache SIS 0.8 produces different transformation results if I compare them with 0.7.
You can find at GitHub a sample program which verifies the transformation between WGS84 and another EPSG code.
https://github.com/shruda/sis-examples/blob/master/ApacheSisTest
* CrsResult - https://github.com/shruda/sis-examples/blob/master/ApacheSisTest/src/test/java/org/apache/sis/CrsResult.java
The static main method of CrsResults can be used to generated a new results.json.
It iterates over all EPSG codes and generates 16 different WGS84 coordinates based on the GeographicBoundingBox of the CRS.
In addition it tries to transforms the WGS84 coordinates to the EPSG definition. The CrsResult's of an EPSG code will be serialized to results.json if all transformations were correct.
* TransformVerificationTest - https://github.com/shruda/sis-examples/blob/master/ApacheSisTest/src/test/java/org/apache/sis/TransformVerificationTest.java
This JUnit test verifies that the transformation in both directions (from WGS84 and back to WGS84) works as expected by considering a predefined accuracy.
The expected accuracy in case of projected coordinate systems is 1e-2f metre and in case of geographic coordinate systems is 1 metre.
I know my code must/can be improved ... because I use the same delta for both transformations...
In the end the test adds the EPSG code to a "successful.json" if the transformation doesn't throws an exception and meets my accuracy.
The goal of this test is, the verification of Apache SIS. I want determine if an update of the framework causes changed at the transformation results.
If a new version of Apache SIS will be released, then I execute the test again the old results. If the changes are explainable, then I will replace the old results.json with a new version of the results.json and the lastsuccessful.json with the latest successful.json.
So, now to some counts - Please note, that I always used the non-free sis-epsg package:
Apache SIS 0.7:
I was able to add 4695 of 5343 EPSG codes to the successful.json. Version 0.7 produced consistent transformation results for all of them by considering by "quality-criteria".
Yes, it's clear for me that such a test is not meaningful because I use the same system for the verification but I was also able to generated roughly the same transformation results for 4666 EPSG codes by using proj4 in combination with the BursaWolfParameters which where picked out by Apache SIS from the EPSG database.
Apache SIS 0.8:
If I use no the results.json and lastsuccessful.json from Version 0.7 and execute the same test with Version 0.8, then I get:
* 37 errors e.g. because of "NoSuchIdentifierExceptions"
* And 278 Failures e.g. if I try to transform the wgs84 position lat=50.562000000000005 lon=-57.68 to EPSG:2009, then X has a difference of 3 meter and Y about 200 metre.
Apache SIS 0.7: [362898.07866302336, 5602902.724452476]
Apache SIS 0.8: [362895.4984923999, 5603136.138981682]
epsg.io means that the result of 0.7 is correct:
https://epsg.io/transform#s_srs=4326&t_srs=2009&x=-57.6800000&y=50.5620000
The master branch of my Git Repository uses Apache SIS 0.7:
https://github.com/shruda/sis-examples/tree/master/ApacheSisTest
I did the upgrade to Apache SIS 0.8 at:
https://github.com/shruda/sis-examples/tree/0.8/ApacheSisTest
I didn't found any hints at the release notes and JIRA which helps me to identify the issue.
Has anyone an idea?
Best Regards,
Steve
Re: Transformation differences between Apache SIS version 0.7 and 0.8
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 20/02/2018 à 17:58, HRUDA Steve a écrit :
> Okay, the second is the case:
>
> * Maybe EPSG::8241 was defined before, but evolution of SIS causes
> SIS 0.8 to follow this specification while SIS 0.7 ignored it.
>
>
>
> org.opengis.util.NoSuchIdentifierException: No operation method found
> for name or identifier “Madrid to ED50 polynomial”.
>
So in conclusion, the new failure is an accidental side-effect of
improvements in the use of EPSG geodetic dataset by Apache SIS. There is
two possible fixes:
1. When an operation method is not implemented in SIS, ignore it like
SIS 0.7 did and declare an accuracy of 3 km (this is an arbitrary
value based on the worst case scenario I have seen so far).
2. Do not change current behaviour (i.e. continue to try to follow
strictly EPSG path) and finish implementations of coordinate
operation methods listed at
https://issues.apache.org/jira/browse/SIS-212 (with addition of
“Madrid to ED50 polynomial” to this list if not already there).
I would prefer option 2, but it may take some time and I do not know how
important are the operations that currently fail?
Martin
RE: Transformation differences between Apache SIS version 0.7 and 0.8
Posted by HRUDA Steve <st...@hexagongeospatial.com>.
Okay, the second is the case:
* Maybe EPSG::8241 was defined before, but evolution of SIS causes SIS 0.8 to follow this specification while SIS 0.7 ignored it.
org.opengis.util.NoSuchIdentifierException: No operation method found for name or identifier “Madrid to ED50 polynomial”.
at org.apache.sis.referencing.operation.transform.DefaultMathTransformFactory.getOperationMethod(DefaultMathTransformFactory.java:396)
at org.apache.sis.referencing.operation.transform.DefaultMathTransformFactory.createParameterizedTransform(DefaultMathTransformFactory.java:1008)
at org.apache.sis.referencing.factory.sql.EPSGDataAccess.createCoordinateOperation(EPSGDataAccess.java:3000)
at org.apache.sis.referencing.factory.AuthorityFactoryProxy$34.create(AuthorityFactoryProxy.java:512)
at org.apache.sis.referencing.factory.AuthorityFactoryProxy$34.create(AuthorityFactoryProxy.java:510)
at org.apache.sis.referencing.factory.ConcurrentAuthorityFactory.create(ConcurrentAuthorityFactory.java:1659)
at org.apache.sis.referencing.factory.ConcurrentAuthorityFactory.createCoordinateOperation(ConcurrentAuthorityFactory.java:1570)
at org.apache.sis.referencing.factory.sql.EPSGDataAccess.createCoordinateOperation(EPSGDataAccess.java:2980)
at org.apache.sis.referencing.factory.AuthorityFactoryProxy$34.create(AuthorityFactoryProxy.java:512)
at org.apache.sis.referencing.factory.AuthorityFactoryProxy$34.create(AuthorityFactoryProxy.java:510)
at org.apache.sis.referencing.factory.ConcurrentAuthorityFactory.create(ConcurrentAuthorityFactory.java:1659)
at org.apache.sis.referencing.factory.ConcurrentAuthorityFactory.createCoordinateOperation(ConcurrentAuthorityFactory.java:1570)
From: Martin Desruisseaux [mailto:martin.desruisseaux@geomatys.com]
Sent: Tuesday, February 20, 2018 10:00 AM
To: HRUDA Steve <st...@hexagongeospatial.com>; dev@sis.apache.org
Subject: Re: Transformation differences between Apache SIS version 0.7 and 0.8
Hello Steve
Le 19/02/2018 à 11:36, HRUDA Steve a écrit :
I use the following Geodetic dataset in case of:
* Apache SIS 0.7
* EPSG dataset version 8.9 on “Apache Derby” version 10.11.
* Apache SIS 0.8
* EPSG geodetic dataset version 9.1 on “Apache Derby” version 10.11.
Apache SIS 0.7 is able to do transformations from EPSG:4326 to EPSG:2062 by using an accuracy of 3000m
The accuracy of 3 km means that SIS 0.7 did not found or did not used coordinate operation path explicitly defined in the EPSG database (3 km is the default accuracy reported by SIS in those situations). At least in latest EPSG database, there is an explicit transformation path between those CRS with an accuracy of 10 metres:
http://epsg-registry.org/?display=entity&urn=urn:ogc:def:coordinateOperation:EPSG::8241
Reasons why SIS 0.7 did not used it while SIS 0.8 tries to use it could be:
* Maybe EPSG::8241 was not defined in EPSG 8.9 - I did not verified.
* Maybe EPSG::8241 was defined before, but evolution of SIS causes SIS 0.8 to follow this specification while SIS 0.7 ignored it.
We can verify by execution the following code with SIS 0.7:
CoordinateOperationAuthorityFactory opFactory = ((CoordinateOperationAuthorityFactory) CRS.getAuthorityFactory("EPSG"));
System.out.println(opFactory.createCoordinateOperation("EPSG::8241"));
If you get something like "No such coordinate operation", this means that EPSG::8241 was not defined in EPSG 8.9. If you get something like "No method found for Matrid to ED50 polynomial", this means that EPSG::8241 was defined in EPSG 8.9 but SIS 0.7 ignored it. The only thing sure is that "Matrid to ED50 polynomial" has never been implemented yet in SIS.
Regards,
Martin
Re: Transformation differences between Apache SIS version 0.7 and 0.8
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello Steve
Le 19/02/2018 à 11:36, HRUDA Steve a écrit :
> I use the following Geodetic dataset in case of:
>
>
>
> * Apache SIS 0.7
> o EPSG dataset version 8.9 on “Apache Derby” version 10.11.
> * Apache SIS 0.8
> o EPSG geodetic dataset version 9.1 on “Apache Derby” version 10.11.
>
>
>
> Apache SIS 0.7 is able to do transformations from EPSG:4326 to
> EPSG:2062 by using an accuracy of 3000m
>
The accuracy of 3 km means that SIS 0.7 did not found or did not used
coordinate operation path explicitly defined in the EPSG database (3 km
is the default accuracy reported by SIS in those situations). At least
in latest EPSG database, there is an explicit transformation path
between those CRS with an accuracy of 10 metres:
http://epsg-registry.org/?display=entity&urn=urn:ogc:def:coordinateOperation:EPSG::8241
Reasons why SIS 0.7 did not used it while SIS 0.8 tries to use it could be:
* Maybe EPSG::8241 was not defined in EPSG 8.9 - I did not verified.
* Maybe EPSG::8241 was defined before, but evolution of SIS causes SIS
0.8 to follow this specification while SIS 0.7 ignored it.
We can verify by execution the following code with SIS 0.7:
CoordinateOperationAuthorityFactory opFactory = ((CoordinateOperationAuthorityFactory) CRS.getAuthorityFactory("EPSG"));
System.out.println(opFactory.createCoordinateOperation("EPSG::8241"));
If you get something like "No such coordinate operation", this means
that EPSG::8241 was not defined in EPSG 8.9. If you get something like
"No method found for Matrid to ED50 polynomial", this means that
EPSG::8241 was defined in EPSG 8.9 but SIS 0.7 ignored it. The only
thing sure is that "Matrid to ED50 polynomial" has never been
implemented yet in SIS.
Regards,
Martin
RE: Transformation differences between Apache SIS version 0.7 and 0.8
Posted by HRUDA Steve <st...@hexagongeospatial.com>.
Hi Martin,
Sorry - I made a typing mistake … I mean EPSG: 2062 and not EPSG:2026.
I use the following Geodetic dataset in case of:
* Apache SIS 0.7
* EPSG dataset version 8.9 on “Apache Derby” version 10.11.
* Apache SIS 0.8
* EPSG geodetic dataset version 9.1 on “Apache Derby” version 10.11.
Apache SIS 0.7 is able to do transformations from EPSG:4326 to EPSG:2062 by using an accuracy of 3000m
Longitude: -1.714
Latitude: 37.524
-> 774435.6600803932,327313.6768732136
CoordinateOperation.toString() returns in case of Apache SIS 0.7 the following:
ConcatenatedOperation["Geographic2D[“WGS 84”] → ProjectedCRS[“Madrid 1870 (Madrid) / Spain”]",
SourceCRS[GeodeticCRS["WGS 84",
Datum["World Geodetic System 1984",
Ellipsoid["WGS 84", 6378137.0, 298.257223563]],
CS[ellipsoidal, 2],
Axis["Geodetic latitude (Lat)", north],
Axis["Geodetic longitude (Lon)", east],
Unit["degree", 0.017453292519943295],
Id["EPSG", 4326, "8.9"]]],
TargetCRS[ProjectedCRS["Madrid 1870 (Madrid) / Spain",
BaseGeodCRS["Madrid 1870 (Madrid)",
Datum["Madrid 1870 (Madrid)",
Ellipsoid["Struve 1860", 6378298.3, 294.73]],
PrimeMeridian["Madrid", -3.687938888888889],
Unit["degree", 0.017453292519943295]],
Conversion["Spain",
Method["Lambert Conic Conformal (1SP)"],
Parameter["Latitude of natural origin", 40.0],
Parameter["Longitude of natural origin", 0.0],
Parameter["Scale factor at natural origin", 0.9988085293],
Parameter["False easting", 600000.0],
Parameter["False northing", 600000.0]],
CS[Cartesian, 2],
Axis["Easting (X)", east],
Axis["Northing (Y)", north],
Unit["metre", 1],
Id["EPSG", 2062, "8.9"],
Remark["Replaced by ED50 / UTM after 1966."]]],
CoordinateOperationStep["Ellipsoid change",
Method["Affine"],
Parameter["num_row", 3],
Parameter["num_col", 3],
OperationAccuracy[3000.0]],
CoordinateOperationStep["Spain",
Method["Lambert Conic Conformal (1SP)"],
Parameter["semi_major", 6378298.3, Unit["metre", 1]],
Parameter["semi_minor", 6356657.142669561, Unit["metre", 1]],
Parameter["Latitude of natural origin", 40.0, Unit["degree", 0.017453292519943295]],
Parameter["Longitude of natural origin", 0.0, Unit["degree", 0.017453292519943295]],
Parameter["Scale factor at natural origin", 0.9988085293, Unit["unity", 1]],
Parameter["False easting", 600000.0, Unit["metre", 1]],
Parameter["False northing", 600000.0, Unit["metre", 1]]],
Area["Spain - mainland onshore."],
BBox[35.95, -9.37, 43.82, 3.39]]
Warnings:
• Can not represent “Ellipsoid change” in a strictly standard-compliant WKT format.
• Can not represent “Spain” in a strictly standard-compliant WKT format.
• Can not represent “Geographic2D[“WGS 84”] → ProjectedCRS[“Madrid 1870 (Madrid) / Spain”]” in a strictly standard-compliant WKT format.
Best Regards,
Steve
From: Martin Desruisseaux [mailto:martin.desruisseaux@geomatys.com]
Sent: Friday, February 16, 2018 7:59 PM
To: HRUDA Steve <st...@hexagongeospatial.com>; dev@sis.apache.org
Subject: Re: Transformation differences between Apache SIS version 0.7 and 0.8
Hello Steve
Le 16/02/2018 à 17:03, HRUDA Steve a écrit :
Examples for 0.8 throws an exception and 0.7 not:
- org.opengis.util.NoSuchIdentifierException: No operation method found for name or identifier “Madrid to ED50 polynomial” (…snip…)
- No operation method found for name or identifier “Molodensky-Badekas (CF geog2D domain)”
Those two operations ("Matrid to ED50 polynomial" and "Molodensky-Badekas") are not yet implemented in Apache SIS. Maybe this difference in behaviour come from different versions of EPSG geodetic dataset? For performing a coordinate transformation, Apache SIS first looks in the "epsg_coordoperation" table. If an entry is found for a given (sourceCRS, targetCRS) pair, SIS will use it. It may happen that EPSG 8.8 or 9.1 (the two versions used by Apache SIS 0.7 and 0.8 respectively) had no entries for, say, EPSG:2026 to EPSG:4326 transformation, but that EPSG 9.2 added such entry. In such case, Apache SIS will try to use that entry which may result in a failure if that new entry uses an unimplemented operation, for example Molodensky-Badekas.
Which version of EPSG geodetic dataset are you using? You can see it with the following Java code:
import org.apache.sis.setup.About;
(...)
System.out.println(About.configuration());
Only the "Geodetic database" line (near the top) is of interest. On my computer I get:
EPSG geodetic dataset version 9.1 on “Apache Derby” version 10.11.
Martin
Re: Transformation differences between Apache SIS version 0.7 and 0.8
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello Steve
Le 16/02/2018 à 17:03, HRUDA Steve a écrit :
> Examples for 0.8 throws an exception and 0.7 not:
> - org.opengis.util.NoSuchIdentifierException: No operation method found for name or identifier “Madrid to ED50 polynomial” (…snip…)
> - No operation method found for name or identifier “Molodensky-Badekas (CF geog2D domain)”
Those two operations ("Matrid to ED50 polynomial" and
"Molodensky-Badekas") are not yet implemented in Apache SIS. Maybe this
difference in behaviour come from different versions of EPSG geodetic
dataset? For performing a coordinate transformation, Apache SIS first
looks in the "epsg_coordoperation" table. If an entry is found for a
given (sourceCRS, targetCRS) pair, SIS will use it. It may happen that
EPSG 8.8 or 9.1 (the two versions used by Apache SIS 0.7 and 0.8
respectively) had no entries for, say, EPSG:2026 to EPSG:4326
transformation, but that EPSG 9.2 added such entry. In such case, Apache
SIS will try to use that entry which may result in a failure if that new
entry uses an unimplemented operation, for example Molodensky-Badekas.
Which version of EPSG geodetic dataset are you using? You can see it
with the following Java code:
import org.apache.sis.setup.About;
(...)
System.out.println(About.configuration());
Only the "Geodetic database" line (near the top) is of interest. On my
computer I get:
EPSG geodetic dataset version 9.1 on “Apache Derby” version 10.11.
Martin
RE: Transformation differences between Apache SIS version 0.7 and 0.8
Posted by HRUDA Steve <st...@hexagongeospatial.com>.
Hi Martin,
sorry for the late response. I always try to transform EPSG:4326 coordinates.
Examples for 0.8 throws an exception and 0.7 not:
- org.opengis.util.NoSuchIdentifierException: No operation method found for name or identifier “Madrid to ED50 polynomial”.
- - EPSG:2026, EPSG:4903,
- org.opengis.util.NoSuchIdentifierException: No operation method found for name or identifier “Molodensky-Badekas (CF geog2D domain)”.
- - EPSG:2096, EPSG:2097, EPSG:2098, EPSG:2169, EPSG:2317, EPSG:3986, EPSG:3987, EPSG:3988, EPSG:4162, EPSG:4181, EPSG:4162, EPSG:4229, EPSG:4247, EPSG:4415, EPSG:4695, EPSG:5132, EPSG:5197, EPSG:5168, EPSG:5169, EPSG:5170, EPSG:5171, EPSG:5172, EPSG:5173, EPSG:5174, EPSG:5175, EPSG:5176, EPSG:5177, EPSG:5178, EPSG:22991, EPSG:22992, EPSG:22993, EPSG:22994, EPSG:24718, EPSG:24719, EPSG:24720
Best Regards,
Steve
-----Original Message-----
From: Martin Desruisseaux [mailto:martin.desruisseaux@geomatys.com]
Sent: Sunday, January 28, 2018 6:56 PM
To: dev@sis.apache.org
Subject: Re: Transformation differences between Apache SIS version 0.7 and 0.8
Hello Steve
I added a JIRA task, to be added in the release notes:
https://issues.apache.org/jira/browse/SIS-390
Le 28/01/2018 à 11:22, HRUDA Steve a écrit :
> 37 NoSuchIdentifierExceptions: I double checked it and the difference
> between 0.7 and 0.8 is, that 0.7 logged a warning if it was unable to
> find the CoordinateOperation but it was able to transform the
> coordinates. 0.8 throws now an Exception if the CoordinateOperation
> can't be found.
>
I would be interested to have an example if you have one at hand; I would like to check why this behaviour changed.
> transformation differences: Thank you for the hints, I will do some
> further analyzations and come back to you if something is unclear for
> me and if it is ok for you ;-)
>
Sure. One investigation I should have done but didn't is to transform coordinates from (EPSG:2009 or EPSG:4609) to EPSG:4326 using the CGQ77-98.gsb datum shift file, and check which one of Apache SIS 0.7 or
0.8 is closer. It would tell us if, in absence of datum shift information, it is better to do nothing or still apply the ellipsoid change, at least in the EPSG:4609 case. If it appears that it is better to do nothing, we could consider reverting SIS-390.
Thanks,
Martin
Re: Transformation differences between Apache SIS version 0.7 and 0.8
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello Steve
I added a JIRA task, to be added in the release notes:
https://issues.apache.org/jira/browse/SIS-390
Le 28/01/2018 à 11:22, HRUDA Steve a écrit :
> 37 NoSuchIdentifierExceptions: I double checked it and the difference
> between 0.7 and 0.8 is, that 0.7 logged a warning if it was unable to
> find the CoordinateOperation but it was able to transform the
> coordinates. 0.8 throws now an Exception if the CoordinateOperation
> can't be found.
>
I would be interested to have an example if you have one at hand; I
would like to check why this behaviour changed.
> transformation differences: Thank you for the hints, I will do some
> further analyzations and come back to you if something is unclear for
> me and if it is ok for you ;-)
>
Sure. One investigation I should have done but didn't is to transform
coordinates from (EPSG:2009 or EPSG:4609) to EPSG:4326 using the
CGQ77-98.gsb datum shift file, and check which one of Apache SIS 0.7 or
0.8 is closer. It would tell us if, in absence of datum shift
information, it is better to do nothing or still apply the ellipsoid
change, at least in the EPSG:4609 case. If it appears that it is better
to do nothing, we could consider reverting SIS-390.
Thanks,
Martin
RE: Transformation differences between Apache SIS version 0.7 and 0.8
Posted by HRUDA Steve <st...@hexagongeospatial.com>.
Hi Martin,
thank you for the quick response and the detailed analyzation!
* 37 NoSuchIdentifierExceptions:
I double checked it and the difference between 0.7 and 0.8 is, that 0.7 logged a warning if it was unable to find the CoordinateOperation but it was able to transform the coordinates.
0.8 throws now an Exception if the CoordinateOperation can't be found.
* transformation differences
Thank you for the hints, I will do some further analyzations and come back to you if something is unclear for me and if it is ok for you ;-)
Best Regards,
Steve
-----Original Message-----
From: Martin Desruisseaux [mailto:martin.desruisseaux@geomatys.com]
Sent: Friday, January 26, 2018 7:34 PM
To: dev@sis.apache.org
Subject: Re: Transformation differences between Apache SIS version 0.7 and 0.8
Hello Steve
(jumping to the core issue)
Le 26/01/2018 à 18:35, HRUDA Steve a écrit :
> If I use no the results.json and lastsuccessful.json from Version 0.7
> and execute the same test with Version 0.8, then I get:
>
> * 37 errors e.g. because of "NoSuchIdentifierExceptions"
> * And 278 Failures e.g. if I try to transform the wgs84 position
> lat=50.562000000000005 lon=-57.68 to EPSG:2009, then X has a
> difference of 3 meter and Y about 200 metre.
>
Are those 37 NoSuchIdentifierExceptions the same than in SIS 0.7, or are they new? If SIS 0.8 throws this exception were SIS 0.7 was used to pass, it may be a bug.
About the 278 transformation differences, taking the transformation from
EPSG:4326 to EPSG:2009 as an example:
> Apache SIS 0.7: [362898.07866302336, 5602902.724452476] Apache SIS
> 0.8: [362895.4984923999, 5603136.138981682]
EPSG:2009 ("NAD27(CGQ77) / SCoPQ zone 3") is a ProjectedCRS. To understanding what is happening here, we need to look at its base GeographicCRS, which is EPSG:4609 ("NAD27(CGQ77)") - see for example the EPSG registry at [1] and click on "Base Geographic CRS". That geographic CRS uses the Clarke 1866 ellipsoid, which is different than the WGS 84 ellipsoid. The transformation between those two CRS should involve a datum shift. Looking in the EPSG geodetic database, I found 4 non-deprecated operations (and 3 deprecated operations) having EPSG:4609 as its source. The only coordinate operation having EPSG:4326 as its destination is EPSG:1691 [2]. That operation requires the CGQ77-98.gsb datum shift file, which may not be installed.
Now the problem is what to do if Apache SIS can not perform the datum shift, either because there is no coordinate operation for a given pair of CRS in the EPSG database, or because the operation requires a datum shift file which is not present? Apache SIS 0.7 did nothing. Apache SIS
0.8 takes at least the change of ellipsoid in account. You can see the difference if you add the following at line 120 of
TransformVerificationTest:
System.out.println(toWgs84);
In Apache SIS 0.8, the output should contain the following fragment which is absent from Apache SIS 0.7:
Param_MT["Abridged Molodensky",
Parameter["dim", 2],
Parameter["src_semi_major", 6378137.0, Unit["metre", 1]],
Parameter["src_semi_minor", 6356752.314245179, Unit["metre", 1]],
Parameter["tgt_semi_major", 6378206.4, Unit["metre", 1]],
Parameter["tgt_semi_minor", 6356583.8, Unit["metre", 1]],
Parameter["X-axis translation", 0.0, Unit["metre", 1]],
Parameter["Y-axis translation", 0.0, Unit["metre", 1]],
Parameter["Z-axis translation", 0.0, Unit["metre", 1]],
Parameter["Semi-major axis length difference", 69.4, Unit["metre", 1]],
Parameter["Flattening difference", 3.726463918114448E-5, Unit["unity", 1]]]
The (X,Y,Z) translations are zero; we don't perform any geocentric translation since we don't know it. But since SIS 0.8 we still take in account the ellipsoid change. There is a change of 69 meters in the semi-major axis length and 169 meters in the semi-minor axis length.
Note that the accuracy is conservatively reported as 3 km (as we can see if we print the WKT of the CoordinateOperation instead than the MathTransform).
> epsg.io means that the result of 0.7 is correct:
> https://epsg.io/transform#s_srs=4326&t_srs=2009&x=-57.6800000&y=50.562
> 0000
This suggests that epsg.io choose to not do anything when it has no datum shift information, like SIS 0.7 does. Notes:
* I'm not sure that taking the ellipsoid change in account as SIS 0.8
does is the best thing to do. I'm not aware of a recommendation
about what to do when there is lack of information. SIS 0.8 tries to
use more information at hands (ellipsoid axis length), but this is
not guarantees to be preferable. No matter what we do, the
inaccuracy is high.
* Despite its name, http://epsg.io is unrelated to the IOGP
organisation that maintains the EPSG geodetic database. We should be
careful with epsg.io results.
> I didn't found any hints at the release notes and JIRA which helps me
> to identify the issue.
>
Indeed, this is missing - thanks for pointing that. I will try to add a JIRA for it. Opinions about what should be do when we don't have datum shift information that we can apply are welcome.
Martin
[1] http://epsg-registry.org/?display=entity&urn=urn:ogc:def:crs:EPSG::2009
[2] http://epsg-registry.org/?display=entity&urn=urn:ogc:def:coordinateOperation:EPSG::1691
Re: Transformation differences between Apache SIS version 0.7 and 0.8
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello Steve
(jumping to the core issue)
Le 26/01/2018 à 18:35, HRUDA Steve a écrit :
> If I use no the results.json and lastsuccessful.json from Version 0.7
> and execute the same test with Version 0.8, then I get:
>
> * 37 errors e.g. because of "NoSuchIdentifierExceptions"
> * And 278 Failures e.g. if I try to transform the wgs84 position
> lat=50.562000000000005 lon=-57.68 to EPSG:2009, then X has a
> difference of 3 meter and Y about 200 metre.
>
Are those 37 NoSuchIdentifierExceptions the same than in SIS 0.7, or are
they new? If SIS 0.8 throws this exception were SIS 0.7 was used to
pass, it may be a bug.
About the 278 transformation differences, taking the transformation from
EPSG:4326 to EPSG:2009 as an example:
> Apache SIS 0.7: [362898.07866302336, 5602902.724452476]
> Apache SIS 0.8: [362895.4984923999, 5603136.138981682]
EPSG:2009 ("NAD27(CGQ77) / SCoPQ zone 3") is a ProjectedCRS. To
understanding what is happening here, we need to look at its base
GeographicCRS, which is EPSG:4609 ("NAD27(CGQ77)") - see for example the
EPSG registry at [1] and click on "Base Geographic CRS". That geographic
CRS uses the Clarke 1866 ellipsoid, which is different than the WGS 84
ellipsoid. The transformation between those two CRS should involve a
datum shift. Looking in the EPSG geodetic database, I found 4
non-deprecated operations (and 3 deprecated operations) having EPSG:4609
as its source. The only coordinate operation having EPSG:4326 as its
destination is EPSG:1691 [2]. That operation requires the CGQ77-98.gsb
datum shift file, which may not be installed.
Now the problem is what to do if Apache SIS can not perform the datum
shift, either because there is no coordinate operation for a given pair
of CRS in the EPSG database, or because the operation requires a datum
shift file which is not present? Apache SIS 0.7 did nothing. Apache SIS
0.8 takes at least the change of ellipsoid in account. You can see the
difference if you add the following at line 120 of
TransformVerificationTest:
System.out.println(toWgs84);
In Apache SIS 0.8, the output should contain the following fragment
which is absent from Apache SIS 0.7:
Param_MT["Abridged Molodensky",
Parameter["dim", 2],
Parameter["src_semi_major", 6378137.0, Unit["metre", 1]],
Parameter["src_semi_minor", 6356752.314245179, Unit["metre", 1]],
Parameter["tgt_semi_major", 6378206.4, Unit["metre", 1]],
Parameter["tgt_semi_minor", 6356583.8, Unit["metre", 1]],
Parameter["X-axis translation", 0.0, Unit["metre", 1]],
Parameter["Y-axis translation", 0.0, Unit["metre", 1]],
Parameter["Z-axis translation", 0.0, Unit["metre", 1]],
Parameter["Semi-major axis length difference", 69.4, Unit["metre", 1]],
Parameter["Flattening difference", 3.726463918114448E-5, Unit["unity", 1]]]
The (X,Y,Z) translations are zero; we don't perform any geocentric
translation since we don't know it. But since SIS 0.8 we still take in
account the ellipsoid change. There is a change of 69 meters in the
semi-major axis length and 169 meters in the semi-minor axis length.
Note that the accuracy is conservatively reported as 3 km (as we can see
if we print the WKT of the CoordinateOperation instead than the
MathTransform).
> epsg.io means that the result of 0.7 is correct:
> https://epsg.io/transform#s_srs=4326&t_srs=2009&x=-57.6800000&y=50.5620000
This suggests that epsg.io choose to not do anything when it has no
datum shift information, like SIS 0.7 does. Notes:
* I'm not sure that taking the ellipsoid change in account as SIS 0.8
does is the best thing to do. I'm not aware of a recommendation
about what to do when there is lack of information. SIS 0.8 tries to
use more information at hands (ellipsoid axis length), but this is
not guarantees to be preferable. No matter what we do, the
inaccuracy is high.
* Despite its name, http://epsg.io is unrelated to the IOGP
organisation that maintains the EPSG geodetic database. We should be
careful with epsg.io results.
> I didn't found any hints at the release notes and JIRA which helps me
> to identify the issue.
>
Indeed, this is missing - thanks for pointing that. I will try to add a
JIRA for it. Opinions about what should be do when we don't have datum
shift information that we can apply are welcome.
Martin
[1] http://epsg-registry.org/?display=entity&urn=urn:ogc:def:crs:EPSG::2009
[2] http://epsg-registry.org/?display=entity&urn=urn:ogc:def:coordinateOperation:EPSG::1691