Details
-
Task
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
None
-
None
-
None
Description
In the EPSG geodetic database, units of measurement are defined by a b/c ratio. But when parsing a WKT, the UNIT element is defined only by a scale factor which is the result of above division. This result is a slight lost of precision. Example with EPSG::9042 unit:
British chain (Sears 1922) = (792 / 39.370147) metres ≈ 20.116765121552632 metres
Which is formatted in WKT as below (note: we should opportunistically fix the unit name, but it does not impact this issue):
Unit["20.116765121552632⋅m", 20.116765121552632]
Unit conversions in Apache SIS internally use ratios for better accuracy. Consequently CRS objects created from the EPSG database get slightly different unit conversion factors than equivalent CRS objects parsed from WKT. This very small difference cascades in non-linear computations up to a point where two CRS objects are considered not equal, even in ComparisonMode.APPROXIMATIVE way (see SIS-434 for more in-depth description of that problem). The proposed improvement is to use the EPSG code of coordinate parameter values for fetching the unit of measurement from EPSG database. This work is described in SIS-210; fixing that later issue should help fixing this issue.
Test case for debugging
In core/sis-referencing/src/test/java/org/apache/sis/test/integration/ConsistencyTest.java, put a @Test annotation on the debug() method and temporarily disable other tests.
If we want to opportunistically fix the unit name issue, it may be done in EPSGDataAccess by invoking ConventionalUnit.forSymbol(String), maybe with the help of an interface defined in an internal package.