INSPIRE Thematic Clusters

CIS 1.1 for Result Encoding

85 Views

O&M ProfileObservation Pressure Depth with ReferencableGridCoverage GML 3.3; pointProperty; valueComponent O&M ProfileObservation Pressure Depth with ReferencableGridCoverage GML 3.3; pointProperty; valueComponent O&M ProfileObservation Pressure Depth with ReferencableGridCoverage GML 3.3; pos; valueComponents/QuantityList

Hiya,

I've been playing with various coverage options over the last months (see the discussion on Observational Coverages as well as the SeaDataCloud Profile Example on our Best Practices Page);

for a while I was quite happy with the potential of the new CIS 1.1 model, but upon further reflection I would appreciate feedback from the wider community on some issues encountered.

Some background: the coverage models to date have been quite specialized (in the IT sense of the word ;) ), every time I tried to apply them I'd come to the conclusion that all possible data permutations are covered except for the one I'm trying to provide. Thus, when I first came across the GeneralGridCoverage in CIS 1.1 (back to soft typing, allowing for whatever domain axes you elect to throw at it), I was thrilled.

Now, taking a closer look, I'm getting worried due to its departure from GML encoding rules; while I'd long been annoyed at the GML 2-Step (relationName/ClassName in the XML; enabled by the GML PropertyTypes), I've started to understand their relevance in the context of Linked Data approaches (there you need something (Class) to relate the relationship to). To my understanding, most SW utilizing GML data depends on this pattern; I know GeoServer App Schema cannot cope without it. As CIS 1.1 no longer includes this, I'm at a bit of a loss...

We can continue with the ReferenceableGridCoverage from http://www.opengis.net/gml/3.3/rgrid (does anyone have an example with a multidimensional domain?), or we could try and get a GML version of CIS 1.1 generated. Other ideas?

Pertaining to the ReferenceableGridCoverage encoding, I've put together a few different versions taking into account the nesting of domain and range values (domain alternately as gml:pos and gml:pointProperty; range as gml:valueComponents/gml:QuantityList and gml:valueComponent/gml:Quantity), does anybody have preferences? Reasons to prefer one version over another?

I'd really like to get this issue clarified so we can provide some guidance in time for 2020 implementation, so any and all feedback is welcome!

:)

Kathi

Environmental Monitoring and Observations Cluster

Environmental Monitoring and Observations Cluster

Environmental Monitoring Facilities, Observations and Measurements