sis-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Desruisseaux <>
Subject Re: Transformation from EPSG:2154 to EPSG:28992
Date Wed, 26 Aug 2020 23:09:38 GMT
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

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.



View raw message