[ 
https://issues.apache.org/jira/browse/SIS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martin Desruisseaux updated SIS-442:
------------------------------------
    Description: 
Calls to {{CRS.findOperation(sourceCRS, targetCRS, areaOfInterest)}} currently 
cache the {{CoordinateOperation}} only when {{areaOfInterest}} is null. It is 
hard to implement a general cache mechanism for all non-null area of interest, 
but we can implement an intermediate solution:

# When {{EPSGFactory}} or {{CoordinateOperationRegistry}} detects that there is 
only one {{CoordinateOperation}} for given source and target CRS, it 
automatically adds some sentinel value in {{PositionalAccuracy}} metadata. It 
could be some internal sub-class.
# When {{DefaultCoordinateOperationFactory}} sees above sentinel values, it 
allows caching even if {{areaOfInterest}} is non-null. Otherwise caching is 
enabled only if {{areaOfInterest}} is null, as today.
# After this optimization has been implemented, we should search for 
occurrences of {{factory()}} in {{Envelopes}} and replace them by calls to 
{{Envelope.findOperation(Envelope, Envelope)}}.

We could also take this opportunity for adding an information message if we 
detected may transformations for the same pair of CRS. Something like _"Note: 
many transformations are defined for this pair of referencing systems in 
different domains of validity."_


  was:
Calls to {{CRS.findOperation(sourceCRS, targetCRS, areaOfInterest)}} currently 
cache the {{CoordinateOperation}} only when {{areaOfInterest}} is null. It is 
hard to implement a general cache mechanism for all non-null area of interest, 
but we can implement an intermediate solution:

1. When {{EPSGFactory}} or {{CoordinateOperationRegistry}} detects that there 
is only one {{CoordinateOperation}} for given source and target CRS, it 
automatically adds some sentinel value in {{PositionalAccuracy}} metadata. It 
could be some internal sub-class.
2. When {{DefaultCoordinateOperationFactory}} sees above sentinel values, it 
allows caching even if {{areaOfInterest}} is non-null. Otherwise caching is 
enabled only if {{areaOfInterest}} is null, as today.

We could also take this opportunity for adding an information message if we 
detected may transformations for the same pair of CRS. Something like _"Note: 
many transformations are defined for this pair of referencing systems in 
different domains of validity."_



> Cache CRS.findOperation(…, areaOfInteret) when area of interest is non null
> ---------------------------------------------------------------------------
>
>                 Key: SIS-442
>                 URL: https://issues.apache.org/jira/browse/SIS-442
>             Project: Spatial Information Systems
>          Issue Type: Task
>          Components: Referencing
>    Affects Versions: 0.7, 0.8
>            Reporter: Martin Desruisseaux
>            Priority: Major
>             Fix For: 1.1
>
>
> Calls to {{CRS.findOperation(sourceCRS, targetCRS, areaOfInterest)}} 
> currently cache the {{CoordinateOperation}} only when {{areaOfInterest}} is 
> null. It is hard to implement a general cache mechanism for all non-null area 
> of interest, but we can implement an intermediate solution:
> # When {{EPSGFactory}} or {{CoordinateOperationRegistry}} detects that there 
> is only one {{CoordinateOperation}} for given source and target CRS, it 
> automatically adds some sentinel value in {{PositionalAccuracy}} metadata. It 
> could be some internal sub-class.
> # When {{DefaultCoordinateOperationFactory}} sees above sentinel values, it 
> allows caching even if {{areaOfInterest}} is non-null. Otherwise caching is 
> enabled only if {{areaOfInterest}} is null, as today.
> # After this optimization has been implemented, we should search for 
> occurrences of {{factory()}} in {{Envelopes}} and replace them by calls to 
> {{Envelope.findOperation(Envelope, Envelope)}}.
> We could also take this opportunity for adding an information message if we 
> detected may transformations for the same pair of CRS. Something like _"Note: 
> many transformations are defined for this pair of referencing systems in 
> different domains of validity."_



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to