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] [Created] (SIS-365) CRS.findOperation(…) should take current locale in account when there is ambiguity
Date Sun, 20 Aug 2017 15:38:00 GMT
Martin Desruisseaux created SIS-365:
---------------------------------------

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


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
(v6.4.14#64029)

Mime
View raw message