search

ISO-TC211 / ISO19111

Revision of ISO19111 - Spatial referencing by coordinates.
2 stars 0 forks source link

Coverage Referencing Multiplicity #40

Closed marqh closed 6 years ago

marqh commented 6 years ago

following on from #39

I would also like to raise queries regarding the appropriateness of the multiplicity of the association to a CRS within 19123:2007

Regarding Figure 2 - CV_Coverage, I have prepared an abbreviated version of this figure: figure2_abbrv_19123 2007

Is it appropriate for a coverage to have one and only one CoordinateReferenceSystem?

Are there use cases where it is more useful for a Coverage to have multiple coordinateTuples referencing different CRS instances?

The scope of 19111 is being extended to include the parametric extensions (currently 19111-2) and temporal referencing.

It may be more convenient to allow a coverage to define multiple independent CoordinateSet instances, each of which is associated to 1 CRS. I would assume that these CoordinateSets are derived from the information stored in the coverage, this is not repeated information.

This could be modelled as follows (perhaps) remodelled_multple_figure2_abbrv_19123 2007

For example, for a coverage, the horizontal position may be referenced with respect to a widely used CRS, say WGS84. The vertical position may use a parametric CRS and the temporal position may use a count since a specified temporal origin. Each of these would be a different derived CoordinateSet, each referencing a commonly used CRS.

Providing for multiple CRS references could make it easier to reuse published CRSs.

If the multiplicity remains at 1 then bespoke compound CRS instances may be required for many more cases.

desruisseaux commented 6 years ago

I'm not sure to understand... Is the intend to avoid creating CompoundCRS? If so and if each CRS component is kept as a distinct association from CV_Coverage, what would be the CRS of operations like CV_Coverage.find(DirectPosition) or attributes like CV_Grid.groudPoint? We still need to specifies all the dimensions when requesting the coverage for a value, isn't it?

pebau commented 6 years ago

It is not only a question of appropriateness, but very much of usability. CRS composition is a natural process, and it allows to have one single point where the application can find out all relevant CRS information. A very lean and elegant interface between coverage and CRS world. If there is a matching CRS, it can be used (although applications are not forced). If there is none, then it can be composed. All situations in life can be covered easily.

The single CRS, chosen after careful investigation and discussing its use back 2010-2012 has massively simplified CRS handling - actually, several problems some standards have (and WCS had) could be solved, including the issue of axis order. So this established practice (supported by the OGC CRS resolver) is a given in coverage world, it is established (and proven) practice.

marqh commented 6 years ago

thank you for the comments on this topic. As I stated, my intent was to raise queries on this multiplicity. I do not have a strong driver to keep this or change it. Given changes in 19111 the occurrence of compound CRSs may increase.

The comments here are in favour of the multiplicity of 1, as in the current 19123. Unless further comments arise with explicit reasons for wanting multiple CRSs, I have no reason to pursue this further. There does not appear to be an issue to raise with the 19123 editing group here.

I'll close this issue tomorrow unless further comments are raised

thank you mark