sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Desruisseaux (JIRA)" <>
Subject [jira] [Updated] (SIS-163) Unsupported WKT 2 features
Date Fri, 24 Apr 2015 21:30:39 GMT


Martin Desruisseaux updated SIS-163:
    Affects Version/s: 0.5

> Unsupported WKT 2 features
> --------------------------
>                 Key: SIS-163
>                 URL:
>             Project: Spatial Information Systems
>          Issue Type: Task
>          Components: Referencing
>    Affects Versions: 0.4, 0.5
>            Reporter: Martin Desruisseaux
>            Priority: Minor
> This page lists the WKT 2 features which are currently not supported in Apache SIS. Support
for those features may be added in future SIS versions if there is a need for them.
> h2. Time extent with named eras.
> | *Currently supported:* | {{TIMEEXTENT\[2013-01-01, 2013-12-31\]}} |
> | *Not yet supported:* | {{TIMEEXTENT\["Jurassic", "Quaternary"\]}} |
> h2. Compound CRS restrictions
> ISO 19162 restricts compound CRS to the following components in that order:
> * A mandatory horizontal CRS (only one of two-dimensional {{GeographicCRS}} or {{ProjectedCRS}}
or {{EngineeringCRS}})
> * Optionally followed by a {{VerticalCRS}} or a {{ParametricCRS}} (but not both).
> * Optionally followed by a {{TemporalCRS}}.
> SIS currently does not enforce those restrictions. In particular:
> * Components may appear in different order.
> * {{VerticalCRS}} + {{TemporalCRS}} (without horizontal component) is accepted.
> * {{GeocentricCRS}} or three-dimensional {{GeographicCRS}} can be combined with {{TemporalCRS}}.
> We should nevertheless perform a check and raise a flag if the CRS does not meet WKT
restrictions, even if we still format it.
> h2. Character encoding restriction
> ISO 19162 requires that we restrict to the following characters in all quoted texts except
in {{REMARKS}} elements:
> {noformat}
> A-Z a-z 0-9 _ [ ] ( ) { } < = > . , : ; + - (space) % & ' " * ^ / \ ? | °
> {noformat}
> They are ASCII codes 32 to 125 inclusive except ! (33), # (35), $ (36), @ (64) and `
(96), plus the addition of ° (176). In particular, the specification recommends:
> * to use (_P_, _L_) as the transliteration of the Greek letters (_phi_, _lambda_) in
axis abbreviations, or alternatively (_B_, _L_) or (_lat_, _long_),
> * to use (_U_) as a replacement for (_theta_) in polar coordinate system,
> * to use (_U_,_V_) as replacements for (_phi_, _theta_) in spherical coordinate system.
> Those restrictions are currently not enforced in SIS.
> h2. Axis name, abbreviation and direction constraints
> ISO 19162 puts many constraints on axis names, abbreviations and directions. Some of
those constraints are inherited from ISO 19111, and some others are specific to ISO 19162.
Apache SIS verifies some of those constraints at {{CoordinateSystem}} construction time, but
not all. Constraints *not* verified by Apache SIS includes:
> * Axis names of geographic CRS shall be ‘_latitude_’, ‘_longitude_’ and (in 3D
case) ‘_ellipsoidal height_’.
> * For other kind of CRS axis names shall be as documented in ISO 19111.
> * Abbreviation of ellipsoidal height shall be _h_.
> * Abbreviations of geocentric CRS axes shall be _X_, _Y_, _Z_.
> * Axis directions are restricted to _north_, _east_ and _up_ for geographic CRS (no _south_,
_west_ or _down_).
> Apache SIS does not verify those constraints at formatting time. We may argue that this
is not formatter job.
> h2. Bearing
> Polar coordinate systems may have a "{{clockwise}}" or "{{counterClockwise}}" axis direction
followed by a {{BEARING\[angle, ANGLEUNIT\[...\]\]}} element. The bearing gives the specified
direction from which the rotation is measured. Those axis directions are not yet supported
in Apache SIS. If we wish to support them in a future version, we could adopt a strategy similar
to the {{DirectionAlongMeridian}} package-private class.
> h2. Explicit {{order}} element in axes
> The optional {{ORDER}} element is omitted at formatting time. This element does not add
any information (it is totally redundant with the {{AXIS}} position), is a distraction for
the human reader, and its support would require new API in the {{Formatter}} class. Until
now we were able to work with tree structures and ordered sequences only. Support of {{ORDER}} element
would force the introduction of the concept of {{List}} (collection with index) or array structures.
We are a little bit reluctant to impose this restriction in the API only for that element.

This message was sent by Atlassian JIRA

View raw message