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:[email protected]] Sent: Sunday, January 28, 2018 6:56 PM To: [email protected] 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
