[ 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)