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:
o 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.
o 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
