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)
