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:[email protected]]
Sent: Friday, January 26, 2018 7:34 PM
To: [email protected]
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
