Thank you
It does work using your method.
I was wondering, I got this operation string, how do you know from this
operation string whether longitude or latitude is first? I would have
assumed longitude is first from the string.
CoordinateOperation["AGD66 to GDA94 (11)",
SourceCRS[GeodeticCRS["AGD66",
Datum["Australian Geodetic Datum 1966",
Ellipsoid["Australian National Spheroid", 6378160.0, 298.25]],
CS[ellipsoidal, 2],
Axis["Geodetic longitude (Lon)", east],
Axis["Geodetic latitude (Lat)", north],
Unit["degree", 0.017453292519943295]]],
TargetCRS[GeodeticCRS["GDA94",
Datum["Geocentric Datum of Australia 1994",
Ellipsoid["GRS 1980", 6378137.0, 298.257222101]],
CS[ellipsoidal, 2],
Axis["Geodetic longitude (Lon)", east],
Axis["Geodetic latitude (Lat)", north],
Unit["degree", 0.017453292519943295]]],
Method["NTv2"],
Parameter["Latitude and longitude difference file", "A66 National
(13.09.01).gsb"],
OperationAccuracy[0.1],
Scope["0.1m accuracy."],
Area["Australia - Australian Capital Territory; New South Wales; Northern
Territory; Queensland; South Australia; Tasmania; Western Australia;
Victoria."],
BBox[-43.70, 112.85, -9.86, 153.69],
Remark["Replaces AGD66 to GDA94 variants 6, 7 and 10 (codes 1506 1507
1596). Input expects longitudes to be positive west; EPSG GeogCRS AGD66
(code 4202) and GDA94 (code 4283) both have longitudes positive east. May
be used as tfm to WGS 84 - see code 15786."]]
On Sun, Dec 8, 2019 at 10:48 AM Martin Desruisseaux <
[email protected]> wrote:
> Hello Thierry
>
> I had a chance to test. The GIGS 5207 test passed on my machine providing
> that we apply the following 2 or 3 modifications on the test code:
>
> 1) As shown by System.out.println(operation) line, that coordinate
> operation expects coordinates in (latitude, longitude) order. The results
> are also produced in that order, so the change applied to 6 places.
> Expected code:
>
> - new DirectPosition2D(inputLat, inputLong) (2 occurrences)
> - assertEquals(inputLat, coordinate[0], 0.001) (2 occurrences)
> - assertEquals(inputLong, coordinate[1], 0.001) (2 occurrences)
>
> 2) Another change is that coordinates in Australia are in the East
> hemisphere, so the longitudes need to be positive. I saw that the GIGS
> Excel files put negative values, but I think it is because they applied the
> change described in cell A33, which said "The NTv2 routine requires
> longitudes to be positive west. The application being tested is expected to
> be able to handle the change of sign". Expected code:
>
> - double inputLong = 115;
> - double resultLong = 115.001261388889; // from GIGS Test5207
>
> 3) A last change is in the order of coordinates given to
> DefaultGeographicBoundingBox constructor, which is not the same than in
> WKT BBOX element (GeographicBoundingBox follows the order used by ISO
> 19115). It should be as below (however this change has no effect on the
> result in this case):
>
> - new DefaultGeographicBoundingBox(lng, lng, lat, lat)
>
> With those changes, the test passed on my machine. Please let me know if
> it is not the case on your side.
>
> Regards,
>
> Martin
>
> P.S.: during the tests, a noticed a SIS bug in the coordinate operation
> name. This bug happens only in some cases and has no incidence on the
> numerical results however: https://issues.apache.org/jira/browse/SIS-483
>
>
>
