[jira] [Updated] (SIS-162) Provide an AbstractCRS.subCRS(int lower, int upper) method
[
https://issues.apache.org/jira/browse/SIS-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-162:
Fix Version/s: (was: 1.1)
1.2
> Provide an AbstractCRS.subCRS(int lower, int upper) method
> --
>
> Key: SIS-162
> URL: https://issues.apache.org/jira/browse/SIS-162
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Referencing
>Reporter: Martin Desruisseaux
>Priority: Major
> Fix For: 1.2
>
>
> We need some way to get the components of a spatio-temporal CRS over a range
> of indices. In Geotk we were used to provide a static {{CRS.getSubCRS(…)}}
> method. For Apache SIS, we should consider a member method in the
> {{AbstractCRS}} class instead. Reasons are:
> * Would allow caching (by generalizing the existing {{derived}} private map).
> * Implementation depends on the coordinate system and CRS type.
> In particular, getting the two-dimensional (_latitude_, _longitude_) part of
> a three-dimensional {{GeographicCRS}} is a common operation. It would be nice
> if SIS were able to find the instance declared in EPSG database. However
> since it would be a relatively costly operation, this would justify caching
> the result.
> h3. Implementation plan
> We may need to start the work in the coordinate system package:
> * Sub CS of a {{CartesianCS}} can be an other {{CartesianCS}}.
> * Sub CS of a {{SphericalCS}} or a {{CylindricalCS}} can be a {{PolarCS}}.
> In the CRS package, the {{CompoundCRS}}, {{GeographicCRS}} and
> {{EngineeringCRS}} among others would probably have their custom {{subCRS}}
> method implementation. The {{GeographicCRS}} special case handled by
> {{CRS.getHorizontalComponent(…)}} and {{CRS.getVerticalComponent(…)}} would
> need to move in some SIS internal package in order to allow
> {{DefaultGeographicCRS}} to share it. The same warning about ellipsoidal
> height would apply, so the actual method signature may be:
> {code:java}
> public AbstractCRS subCRS(int lower, int upper, boolean
> allowCreateEllipsoidalHeight);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-162) Provide an AbstractCRS.subCRS(int lower, int upper) method
[
https://issues.apache.org/jira/browse/SIS-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-162:
Fix Version/s: (was: 1.0)
1.1
> Provide an AbstractCRS.subCRS(int lower, int upper) method
> --
>
> Key: SIS-162
> URL: https://issues.apache.org/jira/browse/SIS-162
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Referencing
>Reporter: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> We need some way to get the components of a spatio-temporal CRS over a range
> of indices. In Geotk we were used to provide a static {{CRS.getSubCRS(…)}}
> method. For Apache SIS, we should consider a member method in the
> {{AbstractCRS}} class instead. Reasons are:
> * Would allow caching (by generalizing the existing {{derived}} private map).
> * Implementation depends on the coordinate system and CRS type.
> In particular, getting the two-dimensional (_latitude_, _longitude_) part of
> a three-dimensional {{GeographicCRS}} is a common operation. It would be nice
> if SIS were able to find the instance declared in EPSG database. However
> since it would be a relatively costly operation, this would justify caching
> the result.
> h3. Implementation plan
> We may need to start the work in the coordinate system package:
> * Sub CS of a {{CartesianCS}} can be an other {{CartesianCS}}.
> * Sub CS of a {{SphericalCS}} or a {{CylindricalCS}} can be a {{PolarCS}}.
> In the CRS package, the {{CompoundCRS}}, {{GeographicCRS}} and
> {{EngineeringCRS}} among others would probably have their custom {{subCRS}}
> method implementation. The {{GeographicCRS}} special case handled by
> {{CRS.getHorizontalComponent(…)}} and {{CRS.getVerticalComponent(…)}} would
> need to move in some SIS internal package in order to allow
> {{DefaultGeographicCRS}} to share it. The same warning about ellipsoidal
> height would apply, so the actual method signature may be:
> {code:java}
> public AbstractCRS subCRS(int lower, int upper, boolean
> allowCreateEllipsoidalHeight);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SIS-162) Provide an AbstractCRS.subCRS(int lower, int upper) method
[
https://issues.apache.org/jira/browse/SIS-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-162:
Fix Version/s: 1.0
> Provide an AbstractCRS.subCRS(int lower, int upper) method
> --
>
> Key: SIS-162
> URL: https://issues.apache.org/jira/browse/SIS-162
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Referencing
>Reporter: Martin Desruisseaux
> Fix For: 1.0
>
>
> We need some way to get the components of a spatio-temporal CRS over a range
> of indices. In Geotk we were used to provide a static {{CRS.getSubCRS(…)}}
> method. For Apache SIS, we should consider a member method in the
> {{AbstractCRS}} class instead. Reasons are:
> * Would allow caching (by generalizing the existing {{derived}} private map).
> * Implementation depends on the coordinate system and CRS type.
> In particular, getting the two-dimensional (_latitude_, _longitude_) part of
> a three-dimensional {{GeographicCRS}} is a common operation. It would be nice
> if SIS were able to find the instance declared in EPSG database. However
> since it would be a relatively costly operation, this would justify caching
> the result.
> h3. Implementation plan
> We may need to start the work in the coordinate system package:
> * Sub CS of a {{CartesianCS}} can be an other {{CartesianCS}}.
> * Sub CS of a {{SphericalCS}} or a {{CylindricalCS}} can be a {{PolarCS}}.
> In the CRS package, the {{CompoundCRS}}, {{GeographicCRS}} and
> {{EngineeringCRS}} among others would probably have their custom {{subCRS}}
> method implementation. The {{GeographicCRS}} special case handled by
> {{CRS.getHorizontalComponent(…)}} and {{CRS.getVerticalComponent(…)}} would
> need to move in some SIS internal package in order to allow
> {{DefaultGeographicCRS}} to share it. The same warning about ellipsoidal
> height would apply, so the actual method signature may be:
> {code:java}
> public AbstractCRS subCRS(int lower, int upper, boolean
> allowCreateEllipsoidalHeight);
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
