[SIS-365] CRS.findOperation(…) should take current locale in account when there is ambiguity - ASF JIRA

Attach files

Attach Screenshot

Add vote

Voters

Watch issue

Watchers

Create sub-task

Link

Clone

Update Comment Author

Replace String in Comment

Update Comment Visibility

Delete Comments

XML

Word

Printable

JSON

Details

Type: Task
Status: Open
Priority: Minor
Resolution: Unresolved
Affects Version/s: 0.7, 0.8, 1.0, 1.1
Fix Version/s: None
Component/s: Referencing
Labels:
None

Description

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.