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
