INSPIRE Thematic Clusters

CIS 1.1 for Result Encoding

153 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

Replies

    • Public

    By Katharina SCHLEIDT

    Hi All,

    Now that I'm a month wiser, and have read a few more standards dox, I now see the error of the GML 3.3 solution. "Use of the instantiable referenceable grid elements of GML 3.3 with ReferenceableGridCoverage violates Requirement 14 of GMLCOV 1.0 and Requirement 24 of the OGC Modular Specification." [1]

    But, there's good news, as this standard is nicely compatible with the GML 3.3 workaround, all I had to do was switch the schema location and namespaces in the examples I provided, now seems good!

    :)

    Kathi

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

    [1]: OGC Coverage Implementation Schema - ReferenceableGridCoverage Extension: http://docs.opengeospatial.org/is/16-083r2/16-083r2.html

    • Public

    By Peter BAUMANN

    Allow me to add a few considerations to this discussion - but first of all, great that we are there now!


    CIS vs GML: It was a recurring topic in discussion about coverages that GML is overly complex, and that this could even hinder CIS/WCS uptake. So we took our "customers" seriously and came up with CIS 1.1, which is more exact than GML 3.2.1 while reducing its complexity substantially. I see this as an asset. And it is a misconception that CIS now "is not GML any longer":

    - relevant parts of GML, where useful, are still there in CIS 1.1.

    - already CIS 1.0 allowed a Metadata record which can be any XML (actually, even any string), definitely no force for GML. CIS 1.1 has just simplified a few more places.

    Hence, the change is not as fundamental as some people might believe.
    my 2 cents,

    Peter

     

    • Public

    By Peter BAUMANN

    next issue: semantic Web readiness.

    Some people believe that the GML pattern is necessary for Linked Open Data. This is not the case, for several reasons - most of all, if you do reasoning you typically use an engine that thinks in RDF, rather than XML - so we talk about a different encoding, which does not need to copy over the mechanical necessities of another "world".

    Notably, CIS 1.1 comes with a fully fledged RDF encoding, and all reasoning is perfectly possible. Also linking together all sorts of data, both locally and distributed across the Internet. If I am missing something concrete, please let me know.

    cheers,

    Peter

     

    • Public

    By Peter BAUMANN

    next: CIS 1.1 and GML and tools.

    While, eg, metadata extraction can well work with standard tools for marshalling into XML and back again I do not think the same holds for an implementation of coverages. XML and pixel world traditionally are quite apart, and implementing coverages with XML will certainly need special coding anyway.

    Further, is it correct that we are talking about a particular tool specifically that is very much tied to this GML pattern? What difficulty specifically are we talking about?

    Hence, currently I am not convinced that there is a real showstopper for CIS 1.1. Definitely, though, CIS 1.1 is LOD ready.

    cheers,

    Peter

     

     

    • Public

    By Peter BAUMANN

    > 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)

    Such artistic modelling IMHO overcomplicates. One of the problems INSPIRE coverages have today that they are so complicated that almost nobody can work with them, at least not easily. My recommendation, from decades of theory, practice, implementation, and use is: KISS - keep it simple and stupid. The coverage model for everyday use should allow an easy handling of standard cases. Advanced stuff could go into extensions, to be used by those who really want it.

    So all stuff like contributing footprints, multiple pixel values, nested domains, etc. - way too complex IMHO.

    my other 2 cents,

    Peter

    • Public

    By Peter BAUMANN

    So, to summarize: simplicity is an asset, and that was one design criterion for CIS 1.1. Further, it support Linked Data (and JSON, BTW). I have heard hearsay that this-or-that should not be possible, but I have not yet seen concrete examples.

    Therefore, let me suggest to define a few use cases and simply work through each one. I will be happy to contribute, and be it just for my built-in curiosity :)

    best,

    Peter

    • Public

    By Peter BAUMANN

    Allow me a PS: We might decide to cooperate among and between OGC & INSPIRE to find coverage solutions - there is a lot of expertise on all sides, so I' love to "stick our pretty little minds" together. Below a fragment of history on ReferenceableGridCoverage if you want to read...

    cheers,

    Peter

    GML history: GML 3.2.1 had only a stub for ReferenceableGridCoverage. 10+ years back Arliss Whiteside had written the missing part, it was adopted, but the GML editors never brought it in.  (GMLCOV/CIS 1.0 just referenced these definitions so as to avoid overlaying definitions.) Eric Hirschorn established the ReferenceableGridCoverage extension to remedy this lack, and so GMLCOV/CIS 1.0 now has RefGridCov indeed.p

    GML 3.3: The GML editors decided to establish GML 3.3 which largely overlaps. Further, this unfortunately effectively prevented normative use of GML 3.3 stuff in GMLCOV/CIS, because it - well - is not referenced normatively due to its late birth. With CIS 1.1 we tried to be as inclusive as possible (and maybe more than that), and GML 3.3 is also included normatively.

     

    • Public

    By Katharina SCHLEIDT

    Hi Peter!

    thanks for bringing your "pretty little mind" to this discussion! ;)

    details later, but one point where I must contradict you across your posts - I fear your pretty little coverages have escaped from their pixilated world, and as here you're posting in the INSPIRE O&M Cluster, I must mention that our Observations have "eaten" your Coverages, misusing the datacube aspects behind them for our purposes and thus requiring the "artistic modelling" I have provided in my real-world examples.

    And yes, cooperation among and between OGC & INSPIRE (and within the various OGC XWGs related to Observations & Coverages; for those without access to the OGC Portal, here a simple overview of the overlaps between Observations & Coverages from the March meeting in Orleans Coverage vs. Observation ) would be most valuable!

    :)

    Kathi

     

    • Public

    By Peter BAUMANN

    Hi Kathi,

    I stand corrected in one point indeed, understood that now: you are using coverages in a way different from what is being discussed in coverage world usually (at least what I perceive, humbly said). Maybe this calls for a f2f meeting in front of a whiteboard - if everybody agrees I'd take an action item to arrange for a harmonization meeting at the Stuttgart OGC meeting Sep 10 - 13, just let me know.

    -Peter

     

    • Public

    By Katharina SCHLEIDT

    OK, but based on the fact that we've broken out of the "pretty little pixel" box and are now trying to provide datacube-like stuff nested within O&M Observations, fear many of your statements above should be rethought! Would you like to do some rephrasing, or should I tear through your text? ;)
    I admit I'm not sure what GML based SW the lack of the object-property-encoding breaks, can only state that provision via GeoServer is not possible, but I will try and follow up on this, i.e. towards Deegree, GDAL and the 52°N SOS. However, one cannot blame SW tailored towards a specific standard for then being dependent on the conventions dictated by that standard.
    I definitely want to chew through this at the OGC Meeting in Stuttgart (had hoped for Fort Collins Funding so that we could already be chewing!). As to the options for getting INSPIRE support, will have to see what's possible. IMHO getting a well-functioning data-cube-like coverage option for INSPIRE would be most relevant, apart from the O&M aspects (that we have preliminarily sorted via CIS 1.0 and the ReferenceableGridCoverage extension) I see this both as a solution for the current statistical dilemma as well as for many of the envisioned "beyond-INSPIRE" aspects, i.e. provision of indicators per administrative unit
    :)
    Kathi