[
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: 1.0
> 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.0
>
>
> 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)
