Hi Martin, Your proposal sound plausible to me.
Regards, Gerd Gerd Müller-Schramm Software Developer, GeoMedia Smart Client Kommunal T: +49 (0) 89 96 106 4117 E: [email protected]<mailto:[email protected]> HxGN Safety & Infrastructure GmbH Wittenberger Straße 15B 04129 Leipzig, Germany hexagon.com<http://www.hexagon.com/> HxGN SI is part of HEXAGON<http://www.hexagon.com/> From: Martin Desruisseaux <[email protected]> Sent: Donnerstag, 27. August 2020 01:10 To: [email protected] Subject: Re: Transformation from EPSG:2154 to EPSG:28992 This email is not from Hexagon’s Office 365 instance. Please be careful while clicking links, opening attachments, or replying to this email. Hello Gerd But how is accuracy determined? I've tried two other CRS: 31467 and 25832 and the accuracy is also 3000 although there areas overlap. The EPSG dataset provides an accuracy estimation for all transformations defined in the database. So currently the rules implemented in Apache SIS are as below: * If a transformation is found in the EPSG database for a given pair of CRS, uses the accuracy declared by EPSG. Those values range from a few centimetres to a few tenths of metres. * Otherwise if Bursa-Wolf parameters can be applied directly for the given pair of CRS, arbitrarily declare an accuracy of 25 metres. This value corresponds to the largest accuracy I found in the EPSG database, so I took it as a "worst case" scenario. * Otherwise (no Bursa-Wolf parameters applied, either because not specified or because they do not provide a direct path), arbitrarily declare an accuracy of 3 km. This value corresponds to the largest error I found empirically by comparing transformations with and without Bursa-Wolf parameters. I found that maximal error on Réunion Island. I'm thinking to amend above rules with the following: * If an indirect path is found (typically A → WGS84 → B), then: * If the domains of validity of both CRS intersect, arbitrarily declare an accuracy of 100 metres. I take the "worst case" scenario of two CRS with Bursa-Wolf (25 metres + 25 metres), and double the result by paranoia because we have no reference like EPSG who have done the accuracy analysis. * Otherwise apply the indirect path anyway, but declares an accuracy of 3 km (i.e. the same amount as if no Bursa-Wolf parameters were available) because we do not know if doing "A → WGS84 → B" in such case is valid. What do you think of above proposal? Regarding your question about a safeguard for CRS that are too far apart: wouldn’t there be some kind of out of range exception if the coordinate to transform is too far away from the area of the target CRS? A difficulty is to define "too far". Another issue is that doing this check at MathTransform.transform(…) invocation time would have performance penalty. I was thinking to apply a check like that at CRS.findOperation(…) invocation time, but have not yet figured out a reliable way. A difficulty is that the domain of validity is often unspecified, e.g. when the CRS was declared by WKT. Maybe we can revisit the "safeguard" question another time, if someone come with an idea. Regards, Martin
