sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Desruisseaux (JIRA)" <>
Subject [jira] [Commented] (SIS-162) Provide an AbstractCRS.subCRS(int lower, int upper) method
Date Tue, 03 Oct 2017 12:30:01 GMT


Martin Desruisseaux commented on SIS-162:

A {{CRS.getComponentAt(CoordinateReferenceSystem crs, int lower, int upper)}} method is available
since SIS 0.5, but it is not as advanced as the one proposed in this issue.

> Provide an AbstractCRS.subCRS(int lower, int upper) method
> ----------------------------------------------------------
>                 Key: SIS-162
>                 URL:
>             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

View raw message