[ 
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}

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.

  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:

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

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. The proposed fix 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}
> 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.



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

Reply via email to