European Commission logo
INSPIRE Community Forum

domainExtent vs gml:boundedBy (EL & OI coverages encoding)

Peter Parslow opened the following discussion topic in the Elevation subgroup, making a new proposal to encode the domain extent of (ISO 19123) INSPIRE coverages using gml:boundedBy

https://themes.jrc.ec.europa.eu/discussion/view/12877/domainextent-vs-gmlboundedby

Original description from Peter:
Given that the purpose (within the INSPIRE specification) of the ISO 19123 domainExtent attribute is to describe the spatial extent of the domain, why not implement it with gml:boundedBy? As it stands, the feature should have both a gml:boundedBy (from GML good practice) and an inspire/ISO domainExtent, containing the same geometry encoded in a different way.

Since the proposal is not only valid for Elevation coverages, but also for Orthoimagery ones (and any other INSPIRE coverages in general), please use this new discussion topic in the parent Cluster group for further discussion.

Feel free to participate!

 

  • Julián DELGADO

    By Julián DELGADO

    Dear all,

    After a couple of vacation’s days I feel completed flooded with new inputs, and I don’t know exactly what it is the last proposal. After read all I can answer about some new ideas presented.

    - About the possibility to delete or reduce importance of domainExtent, ok from my side. BoundedBy can offers a simple location of the dataset and the footprint the accurate coverages geometries.
    - Possibility to add a ‘footprint’ attribute to EL data, ok from my side. Currently there is no special obligation in EL to provide the accurate limit of each DEM.

    Form the user-side (I feel more user than developer of coverage data) the use of boundedBy, footprint, coverage domainSet and possible domainExtent must to be clearly described in the new specification text, if not, misunderstandings will always happen.
    I remember that maybe these ideas of gml:boundedBy, domainExtent implementation, can be exportable to other INSPIRE themes, so, be aware on it when they will be presented.

    My best regards
    Julián

  • Jordi ESCRIU

    Dear Julián,

    Thank you for your quick up-to-date on the thread!

    Just for clarification - The final solution or OPTION we are discussing and trying to close now is the one I presented in my post on 28th October (yesterday), just after the first post of Clemens Portele.

    Any ideas on a more suitable name for the 'footprint' property proposed as an addition to the ElevationGridCoverage?

    Let me know if you agree on this proposal - From your words, I think so.

    Jordi

  • Emmanuel DEVYS

    By Emmanuel DEVYS

    Sorry folks to introduce myself in this thread lately, but as having a strong interest in orthoimagery and elevation coverage data (and models) and in INSPIRE OI and EL, I dare do so.

    I must confess I am somehow puzzled by the meanders of this thread, though it seems to progress slowly.

    In spite of Peter Baumann and Clemens contributions, there is some remaining fuzzy or obscure the domainExtent and domainSet and I am not sure when Peter Baumann says that "domainExtent in ISO 19123 is represented by the domainSet in GML" which, as Peter Parslow mentioned, seems to contradict what Clemens said.

    It seems to me that the key issue of INSPIRE Coverage-based specifications is that is based on 19123 abstract model (UML) and implemented on basis of GMLCOV, also bringing INSPIRE designed elements in the model. As the mapping between 19123, GMLCOV and INSPIRE specific classes is not perfectly clear (at least to me), this is uneasy, and requires clarification. Some ambiguities along this thread suggest that it is not that easy... and I must confess that after having gone through the thread, it is not crystal clear to me.

    I would just like to start from 19123 CV_coverage : it has the following elements:

    +domainExtent [1..*] : EX_Extent (contain the extent of the domain of the coverage. Extents may be specified in space, time or space-time)
    +rangeType : RecordType (describes the range of the coverage)
    +commonPointRule : CommonPointRule

    and also the following CV_coverage Association (as per class diagram) elements:
    +domainElement (CV_DomainObject) : 1..*
    +rangeElement (CV_AttributeValues) : 0..*

    According to Clemens,

    • gml:domainSet implements CV_Coverage.domainElement (CV_domainObject)
    • gml:boundedBy implements CV_Coverage.domainExtent

    However the issue is that the gml:boundedBy element (optional ) cardinality is one only, so this GML limitations may be impacting complex domainExtent descriptions as specified by INSPIRE coverage-based specification.

    I let Peter Baumann clarify his contribution on domainExtent vs domainSet, but I am confident that there should be a consensus on this.

    The mapping of domainExtent with boundedBy (or gml:Envelope) is not made clear (in my humble opinion) by GMLCOV (09-146r2). Note 1 to its Table 2 provides an explanation, but no requirements, as Peter Baumann explains in his contribution.

    I am not involved enough in INSPIRE OI or EL specifications to be in a position to provide any recommendation on whether the domainExtent which has been re-introduced in Orthoimage(resp. Elevation)Coverage needs to be maintained or not, and I am confident INSPIRE experts will converge to an appropriate solution (whether to keep it in addition to the boundedBy or not).

    I must confess that I am more in favor of this standardized element than in the INSPIRE specific oi:footprint (which is for sure an answer of some duly assessed requirement and use case).

    However whatever the final proposal is, I would strongly recommend it to be duly documented, with a mapping to 19123 AND to GMLCOV, and the additional constraint (if any) of the INSPIRE model / schema. (lack of clear mapping is the source of ambiguity in these specifications that rely on both 19123 and GMLCOV).

    Also, it should be noticed that WCS2.0 technology does not take account of INSPIRE model extensions, and the result of a getCoverage should loose these extensions in an INSPIRE download service, unless specific WCS extensions are being developed.

    My 2 cents, hoping this contributes to the emergence of a clear solution

    Emmanuel

     

  • Julián DELGADO

    By Julián DELGADO

    Dear Jordi, yes, i'm agree with your option proposed 2 days ago.

    About last Emmanuel commnent, sorry but I have no sufficient background to provide ideas. But i agree that the use of domainSet (among other elements coming from GMLCOV) should be also clarified, in practical sense, in the especification's revision.

    My best regards

  • Jordi ESCRIU

    Dear All,

    I feel there is NO consensus at the moment on any of the proposals that had emerged till now, and the discussion shall continue - probably with support from appropriate experts in the developement of the mentioned OGC standards.

    Therefore, I have removed the page documenting the proposed changed to the TGs.

    As Emmanuel pointed, it is not clear enough how the ISO 19123 abstract specification maps to the corresponding implementation standards (GML+GMLCOV). At the same time, a new standard for coverages is emerging (CIS v1.1) which hopefully may bring light into this issue.

    In my view, the proposal for MIG-T would be to further explore how coverages should be encoded in an harmonized way, analysing carefully the mapping between ISO 19123 and GML+GMLCOV - especially focused on the properties discussed in this thread (domainExtent, gml:boundedBy, footprint...) but also on other aspects that are not clear (e.g. spotted in the thread - https://themes.jrc.ec.europa.eu/discussion/view/42326/need-more-guidance-for-elevation-encoding-and-correct-example-for-elevationgridcoverage-on-the-basis-of-gmlcov-schema).

    Maybe this work could form part of MIWP-7b WCS - Task 2: New Technical Guidelines for providing conformant INSPIRE coverage data by using WCS - Something to be checked.

    Hope you agree on this approach.

    Jordi

  • Clemens PORTELE

    By Clemens PORTELE

    Jordi,

    no disagreement from me, but I would like to clarify two points:

    it is not clear enough how the ISO 19123 abstract specification maps to the corresponding implementation standards (GML+GMLCOV)

    With respect to GML, the mapping is defined in section D.2.11 "ISO 19123 Coverages" and in particular "Table D.8 — Description of the implementation of ISO 19123", which specifies that mapping of domainExtent and domainElement that I have described earlier.

    The other point is in INSPIRE there is an intermediate step between the level of the abstract schemas (ISO 19123) and the implementation schemas (GML and GMLCOV), i.e. the INSPIRE application schema for coverages. In this we had intentionally left domainExtent out of the INSPIRE coverage classes as we had reduced the schema to what is mandatory in the implementations (again, GML and GMLCOV). I guess, it would have been better to discuss that explicitly in the document. Once there is consensus about how to update the INSPIRE application schemas for coverages and their documentation, I would suggest to update in that document/schema all aspects that are not specific to a single theme.

  • Jordi ESCRIU

    Dear Clemens,

    Thanks for highlighting the second point - I will take it into account.

    Regarding the first point, I can see that the mapping between ISO 19123 and GML is clearly defined in the annex you mentioned. But when adding GMLCOV, it becomes more complicated.

    The fact that GML and GMLCOV (which is in fact a subsequent complement to / amendment of GML) are defined in different documents makes it difficult to interpret the overall standard and there is room for some inconsistencies (e.g. see the issue about rangeParameters / fileReference identified here).

    Therefore there is a need to avoid that readers make their own interpretations. So the guidelines for providing INSPIRE conformant coverage data would be really helpful.

    Tomorrow I will draft a proposal in line with my previous post.

    Hope ALL agree on this.

    Jordi

  • Jordi ESCRIU

    I copy here an email received from Peter Baumann yesterday (he is experiencing loggin issues).


    From: Peter Baumann [mailto:p.baumann@jacobs-university.de]
    Sent: diumenge, 1 / novembre / 2015 14:27
    To: Escriu Paradell, Jordi; Clemens Portele
    Subject: Re: FW: Your input needed in discussion: gml:boundedBy vs. domainExtent

    Jordi-

    Clemens is right about domainSet vs domainExtent. I am not sufficiently familiar with what INSPIRE had established earlier, in particular those items diverting from the OGC coverage model - I was guessing, which is not good here.

    Therefore, others who are more fluent on INSPIRE's coverage model should do an INSPIRE-based assessment.

    Some comments on what I find on the discussion page:
    - "mapping to 19123 AND to GMLCOV" sounds a bit scary, like yet another individual solution.
    - "WCS2.0 technology does not take account of INSPIRE model extensions": yes. INSPIRE has chosen its own way earlier (despite my manifold attempts to point out the dangers), and we are facing the resulting issues now. Actually, even services crafted specifically for INSPIRE have issues in keeping all data items, as has been pointed out at the WCS kickoff workshop in Frascati based on an interoperability test conducted (by Ilkka?).

    Talking about CIS 1.1 could be the unique opportunity of getting INSPIRE back in sync with OGC and ISO (which is in the process of adopting CIS 1.1, in parallel to OGC), and before operational coverage services get deployed.

    my 2 cents,
    Peter


     

  • Jordi ESCRIU

    Dear All,

    I think this solves the contradiction which Peter Parslow spotted regarding the first posts of Peter Baumann & Clemens Portele.

    Do you think that we could propose a solution different to the mapping analisys?

    Jordi

  • Jordi ESCRIU

    Answer from Peter Baumann yesterday.


    Hi Jordi,

    On 2015-11-01 23:53, Escriu Paradell, Jordi wrote:

    Hi Peter, Clemens,

    If I am not misunderstanding your email, the contradiction which Peter Parslow spotted regarding your posts (Peter & Clemens) would then be solved, wouldn't be?

    from my perspective, yes.

    If so, there is still room for arriving to a solution different to thge mapping analisys.

    What I can gladly offer is a telecon for explaining concepts and design rationales of the 1.0 vs 1.1 coverage model, if that is deemed useful.

    Cheers,
    Peter


     

Elevation, Ortho & Grids

Elevation, Ortho & Grids

INSPIRE Thematic Cluster Elevation, Orthoimagery, Reference systems, Geographical grids - Join this group to share your knowkledge, learn and collaborate in solving issues related to the Elevation, Orthoimagery, Reference systems and Geographical grids themes