sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Desruisseaux (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SIS-433) Replace unit parsed from WKT by unit declared in EPSG database
Date Wed, 17 Oct 2018 10:33:00 GMT

     [ https://issues.apache.org/jira/browse/SIS-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Martin Desruisseaux updated SIS-433:
------------------------------------
    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:

{quote}
British chain (Sears 1922) = (792 / 39.370147) metres ≈ 20.116765121552632 metres
{quote}

Which is formatted in WKT as below (note: we should opportunistically fix the unit name, but
it does not impact this issue):

{noformat}
Unit["20.116765121552632⋅m", 20.116765121552632]
{noformat}

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.

h2. 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.

  was:
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:

{quote}
British chain (Sears 1922) = (792 / 39.370147) metres ≈ 20.116765121552632 metres
{quote}

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.


> Replace unit parsed from WKT by unit declared in EPSG database
> --------------------------------------------------------------
>
>                 Key: SIS-433
>                 URL: https://issues.apache.org/jira/browse/SIS-433
>             Project: Spatial Information Systems
>          Issue Type: Task
>          Components: Referencing
>            Reporter: Martin Desruisseaux
>            Priority: Minor
>
> 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:
> {quote}
> British chain (Sears 1922) = (792 / 39.370147) metres ≈ 20.116765121552632 metres
> {quote}
> Which is formatted in WKT as below (note: we should opportunistically fix the unit name,
but it does not impact this issue):
> {noformat}
> Unit["20.116765121552632⋅m", 20.116765121552632]
> {noformat}
> 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.
> h2. 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.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message