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-365) CRS.findOperation(…) should take current locale in account when there is ambiguity
Date Fri, 20 Jul 2018 10:44:00 GMT

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

Martin Desruisseaux updated SIS-365:
------------------------------------
    Fix Version/s:     (was: 1.0)
                   1.1

> CRS.findOperation(…) should take current locale in account when there is ambiguity
> ----------------------------------------------------------------------------------
>
>                 Key: SIS-365
>                 URL: https://issues.apache.org/jira/browse/SIS-365
>             Project: Spatial Information Systems
>          Issue Type: Task
>          Components: Referencing
>    Affects Versions: 0.7, 0.8
>            Reporter: Martin Desruisseaux
>            Priority: Minor
>             Fix For: 1.1
>
>
> The {{CRS.findOperation(…)}} method expects 3 arguments: a source CRS, a target CRS,
and an optional area of interest (as a geographic bounding box). The area of interest is sometime
necessary because more than one operation may exists for the same pair of CRS, depending on
the area of interest. For example the EPSG database contains about 85 different operations
between NAD27 and WGS84. There is an operation for East of Texas, an other operation (with
different parameters) for West of Texas, one operation for the continental USA as a whole,
one operation for Canada as a whole,_etc._
> If the user does not provide any area of interest, then Apache SIS default behavior is
to select the operation which is valid in the widest area. However, this criterion means that
when asking for a transformation from NAD27 to WGS84, Apache SIS will select by default the
operation for Canada because it covers a wider geographic area than the operation for continental
USA. This may not be the default choice than many users would expect.
> We can try to improve this situation by taking the locale in account. If no geographic
area is specified, then:
> * If the default locale is {{Locale.US}}, give precedence to the operation for USA.
> * If the default locale is {{Locale.CANADA}}, give precedence to the operation for Canada.
> * For any other locale, keep the current behavior (select widest area).
> While we used USA and Canada as an example, we actually want to apply the same approach
for any country. Technically, we can use the {{Area}} table in the EPSG database. That table
contains 3 columns for ISO codes: one for the two-letters codes, one for the three-letters
codes and another one for numerical codes. The approach is:
> * When creating a {{GeographicExtent}} from EPSG database, include ISO codes (if present)
as identifiers.
> * When searching for a coordinate operation, if and only if the users did not specified
explicitly a geographic area, use the ISO codes associated with {{GeographicExtent}}.



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

Mime
View raw message