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
