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!

 

  • Peter PARSLOW

    Firstly, gml:boundedBy is quite capable of describing the temporal limits too; GML has a specific specialisation of gml:Envelope to handle this (see 9.4.1, the same clause where boundedBy is described - gml:EnvelopeWithTimePeriod).

    On the main question, I would keep domainExtent, because it is sourced from ISO 19123 (where it is  mandatory). There is no XSD for 19123, so it isn't actually imported, but if INSPIRE removes it, then our spec no longer conforms to ISO 19123. Anything not written specifically for INSPIRE, but 19123 aware, would expect to find a domainExtent.

    I'm not sure that the two specs have to have the same model: OI added footprint for a specific requirement - to indicate the smaller, non rectangular, 'area of interest' outside which lie 'no value' points. Does that occur in EL? Perhaps at the coastline (we made the decision to set all elevations on tidal water at 0, even if that may be not strictly true). By the way, OI describes the use of footprint, and it isn't particularly to do with discontinuous coverages.

  • Jordi ESCRIU

    Dear Peter,

    From your comments I guess you are more happy with OPTION 1?

    I would say that in the case of EL we could also have 'no value' areas near the borders of a rectangular coverage.

    Thank you for spotting that 'domainExtent' is mandatory in ISO 19123, something which I forgot yesterday.

    We could maintain it in the INSPIRE TGs (conceptual specifications), but say that it shall be implemented by means of 'gml:boundedBy' - Does this makes sense?  

    For the others - Please, provide you option on this topic and about the preferred OPTION as well.

    Jordi

  • Jordi ESCRIU

    Dear colleagues,

    I will be proposing OPTION 1 (i.e. with the refinement of the meaning of each property proposed by Julián) as a proposal for chaging the EL & OI TGs in the MIG-T meeting in Rome, to improve the current documents - I have slightly changed the page describing the the proposal:

    https://themes.jrc.ec.europa.eu/pages/view/37857/encoding-of-the-spatial-extent-of-coverages

    However, I will leave this discussion topic opened for further discussion, if needed (e.g. possible ways of implementing the 'domainExtent' property stemming from ISO 19123, need for adding 'footprint' attriubute to EL specifications, etc.).

    Hiope you agree on this approach.

    Jordi

  • Jordi ESCRIU

    I am publishing here an email received from Peter Baumann


    Hi Jordi,

    just wanted to post, but for some reason I cannot, so here by mail:

    First, the domainExtent in ISO 19123 is represented by the domainSet in GML (no idea why it has been renamed) and, hence, GMLCOV/CIS. Also, it has been simplified over 19123 (cardinality 1..*) to have exactly one domainSet. Substantially simpler for implementations. So there is already a place for the domainExtent.

    The boundedBy element indeed is optional. The WCS.SWG at some time in the past strongly recommended it because some domainSet descriptions can become large (ex: point clouds, irregular grids), so this gives a quick overview. Says GML 3.2.1 schema: "The value of the gml:boundedBy property describes an envelope that encloses the entire feature instance, and is primarily useful for supporting rapid searching for features that occur in a particular location."

    However, the boundedBy is not required to be the precise boundary. For example, a raw scene may have the famous 4 black triangles in the corners as the image area is not axis parallel. So it is minimal which still not exactly describing the outline. Not relevant for the discussion on hand, just noting this in passing.

    Time: some folks have mentioned time extents in the thread. Note that a coverage as per OGC has 1 space-time CRS, the time coordinate is contained in the srsName attribute and, hence, present in both boundedBy and domainSet. Actually, it is much simpler than it was conceived earlier. :) See also 19123: "Extents may be specified in space, time or spacetime."

    Hope this contributes,
    Peter

     


     

    What do you think?

    Jordi

  • Clemens PORTELE

    By Clemens PORTELE

    I finally had a look at the thread and would like to add the following comments. 

    On the conceptual level, ISO 19123 specifies two properties:

    • CV_Coverage.domainExtent describes the extent of the domain of the coverage in space, time or space-time
    • CV_Coverage.domainElement describes the domain (an aggregation of objects that may include any combination of GM_Object, TM_GeometricPrimitives, or spatial or temporal objects defined in other standards, such as the CV_GridPoint)

    My understanding always was that domainExtent could be seen as derived information from the domainElement, which is the formal definition of the domain, with the primary purpose of making the domain easier searchable in a more harmonised representation. If that would not be the main purpose, the use of domainExtent would not be clear to me.

    In GML we have mapped this to the following XML property elements of a coverage (see table D.8 in GML 3.2.1):

    • gml:boundedBy implements CV_Coverage.domainExtent
    • gml:domainSet implements CV_Coverage.domainElement

    GMLCOV, and thus the XML schema for coverages in INSPIRE, has "inherited" these properties.

    As it has been pointed out, gml:boundedBy is less expressive than domainExtent when the boundary is not aligned with CRS axes or in the case of non-simple extents, but it (probably) seemed unjustified to not recommend the use of gml:boundedBy and create a new coverage-specific property element. I am saying "probably", because this was discussed more than 10 years ago and I do not remember the discussions in detail.

    In any case, it is quite normal in an implementation to be more restrictive than the abstract specification. For example, gml:Polygon or gml:PolygonPatch cannot represent all instances of GM_Polygon. If the restrictions are a problem for a use case than the community that has the use case has to extend the implementation schema (or develop its own implementation schema).

    In INSPIRE we have created an application schema for coverages (see D2.10.2). Following the rules of ISO 19103, the coverage classes in this application schema are realisations of the CV-types in ISO 19123. These realisations do not contain a property domainExtent. If I remember well, this was for two reasons: first, the information is derived from the domainSet anyhow (so, if anyone needs the information, it is straightforward to derive) and neither GML nor GMLCOV did add requirements related to gml:boundedBy in coverages. I.e., gml:boundedBy may be used in coverages where it is found useful, but there is no requirement. 

    Looking at the OI application schema, I see that two new properties have been added and mapped one-to-one to the GML application schema:

    • OrthoimageCoverage.domainExtent (identical to the definition in ISO 19123)
    • OrthoimageCoverage.footprint (new property that is defined as "refined extent")

    I understand that the idea of footprint is to enable precise spatial (but not temporal) selection, so if there is an identified need for that capability I can see why it has been added. 

    Unless the limitations of gml:boundedBy over domainExtent are essential for the OI data - in particular as there is oi:footprint, too - I am not convinced about the added value of domainExtent.

    For both properties: if the data is published via WCS, how would it be used / useful without a specific extension? Or is it mainly for publication via Atom feeds or similar to simplify processing of downloaded data?

  • Jordi ESCRIU

    Hi All,

    With the nice contributions from Peter (Baumann) and Clemens, now it is more clear to me how we could proceed - Let me summarize the main ideas:

    • It is condirmed that 'gml:boundedBy' implements the 'domainExtent' attribute stemming from ISO 19123 abstract specification in the case of coverages. Therefore, there would be NO NEED to duplicate this information again at implementation level, having an additional 'domainExtent' (as it is currently the case in both TGs, EL and OI ones).
    • 'gml:boundedBy' has certain limitations or it is "less expresive than domainExtent" e.g. when the boundary is not aligned with CRS axes (i.e. existence of the famous 4 black triangles in the corners as the image area, in a raw scene) or in the case of non-simple extents.
    • However, these limitations may not be so important in our case, specially if we do not have any use case that tell us to overcome them.
    • Additionally, in the case of the OI theme we have the attribute 'footprint' which contain essentially the same (spatial) information than 'gml:boundedBy' but more refined - i.e. having the real boundary (GM_MultiSurface) where we have coverage data values and non-simple extents (e.g. discontinuous extents).
    • Finally, implementing 'gml:boundedBy' in GML (although having cardinality 0..1 in the OGC 07-036 GML standard) seems quite important and (even) used. Because it allows and it is useful for  "supporting rapid searching for features that occur in a particular location", and - as pointed by Peter Parslow - it is seen as a GML good practice by the community.
    • As stated by Peters (Parslow), 'gml:boundedBy' also allows making reference to the information about the temporal extent - using the appropriate datatypes.

    Having all these ideas in mind, and changing the more conservative proposal I just draft this morning (without the inputs from Peter and Clemens), I would propose going for the following OPTION (quite similar to the OPTION 2 I already described on 26th October):

    OPTION

    a. Use 'gml:boundedBy' property just for describing the approximate outer bounds of the data set - If  a more refined extent is needed, this may be described under the 'footprint' property.

    b. Use the 'footprint' property (as described in OI TG) for refining somehow the information reported in 'gml:boundedBy' - e.g. to describe a boundary which is not aligned with CRS axes or non-simple and/or discontinuous spatial extents.

    c. TO BE DISCUSSED - Add the 'footprint' property to the EL grid coverage schema in the EL TG. In my view, in EL there is the same need for knowing the refined boundary of the coverage data set than in the case of OI.

    d. Remove the 'domainExtent' attributes from both application schemas, EL & OI coverage schemas - as already pointed by Clemens, in line with the INSPIRE application schema for coverages (D2.10.2).

    e. Add a recommendation in both TGs (EL & OI), saying that "The approximate absolute outer bounds of the data set should be encoded using gml:boundedBy for supporting rapid searching for features that occur in a particular location".

    f. TO BE DISCUSSED - Add a requirement in both TGs (EL & OI), or a constraint on the relevant coverage feature types, stating that at least the 'gml:boundedBy' or the 'footprint' property must be provided when implementing the coverage.

    This way we are not changing the multiplicity of the 'footprint' property (currently 0..1 in TG on OI) while allowing the provision of EITHER the approximate boundary with the 'gml:boundedBy' property, the refined boundary with the 'footprint' property OR both properties at the same time (one approximate, the other one refined). Hence, always an implementation of the property 'domainExtent' from ISO 19123.

    PLEASE - Let me know if you agree on this FINAL OPTION, especially Peter Parslow & Julián, who keep really active on this thread. State mainly your opinion on items c and f (in red above), with the aim to close the final proposal.

    Waiting for your useful and valuable input,

    Jordi

  • Peter PARSLOW

    I'm not sure that Peter & Clemens's inputs, as given above, are entirely helpful, as they appear to contradict each other:

    19123 GML - Peter GML - Clemens
    CV_Coverage.domainExtent [1..*] domainSet [1] boundedBy [0..1]
    CV_Coverage.domainElement   domainSet

    Sorry Peter. Can we clarify this first?

    Then, I think it is only the first of those we're discussing here. So do we believe that a maximum of one domainExtent is sufficient, especially if it is limited to an envelope?

    If not, then (like the authors of the two INSPIRE specs), we need to add an element. I'm not convinced that 'footprint' is a term that 'elevation people' would recognise. Personally, I associate it with buildings, but can see how it fits for imagery. domainExtent seems sensible, if only GML hadn't already made their decision on what should be done with that term.

    Finally, as Clemens says (& inline with the other change we want made): we need to be absolutely clear what applies to multi-part MIME messages returned from WCS, and what applies to "GML + file" delivery, in accordance with the INSPIRE application schemas.

    Sorry to extend the discussion. If we're happy that this is to bring the INSPIRE application schemas in line with the GMLcov/MIME approach, then I can put aside my slight concern on what the attribute should be called, and agree your proposal - including c & f.

    Peter

  • Jordi ESCRIU

    Hi Peter,

    No problem to continue the discussion, since this is the aim of the Cluster. I am just trying to coverge to a solution (if possible this week) to present a solution hopefully in the MIG-T meeting in Rome.

    In the light of Clemens' words:

    My understanding always was that domainExtent could be seen as derived information from the domainElement, which is the formal definition of the domain, with the primary purpose of making the domain easier searchable in a more harmonised representation.

    My understanding is that 'domainExtent' is a simplification of 'domainElement', just made available for supporting more efficient searches without accessing directly to the domain. So - regarding your comparative table - probably Peter Baumann was more generic in his post, while Clemens was more specific in his post.

    But let Peter Baumann and Clemens to clarify this aspect.

    If I correctly understood you - I can see your points about:

    • Cardinality of the property to be implemented - Currently we have 'domainExtent' [0..*] - If we remove it and use 'gml:boundedBy' [0..1], we are more restrictive. The question is - Is this suficient?
    • Is the 'footprint' attribute semantically correct for EL? I agree that we may find a more suitable name for the property, but the underlying principle behind this attribute is applicable to EL coverages.

    I agree with you that we shall be absolutely clear that the final proposal to be presented as a solution shall be consistent and applicable to multi-part MIME messages returned from WCS, i.e. "GML + file" delivery, in accordance with the INSPIRE application schemas.

    Jordi

     

  • Clemens PORTELE

    By Clemens PORTELE

    Peter,

    regarding

    domainExtent seems sensible, if only GML hadn't already made their decision on what should be done with that term

    If you want to use "domainExtent : EX_Extent [1..*]" in the INSPIRE application schema(s) and their GML encoding, I do not see what would be wrong with that.

    GML just says that gml:boundedBy may be used as an implementation of CV_Coverage.domainExtent, but if that implementation is not sufficient for the INSPIRE needs, then this does not block you from defining an additional property with the name domainExtent in the INSPIRE application schemas.

    That said, I do not know the use cases why the added "precision" that comes with domainExtent is important in INSPIRE (domainSet will always be what normatively specifies the domain, not any of the other domain-related properties), but I would like to point out that it seems as if the broader community so far did not see a real need for that - otherwise there would have been change proposals for GML/GMLCOV. Does this really change with INSPIRE?

    That last paragraph should be taken with a grain of salt as my practical experience with coverages is limited. It just reflects the observation that a) domainExtent would not really add any new information over what can be derived from domainSet and b) there does not seem to be a general demand for a more complete implementation of CV_Coverage.domainExtent in the standards.

     

  • Jordi ESCRIU

    Hi Peter,

    Not sure if Clemens resolved the potential contradiction you mentioned, and if I catch correctly your remaining questions / doubts - which I summarize in the following 2 bullets:

    • Cardinality of the property to be implemented - Currently we have 'domainExtent' [0..*] - If we remove it and use 'gml:boundedBy' [0..1], we are more restrictive. The question is - Is this suficient?
    • Is the 'footprint' attribute semantically correct for EL? I agree that we may find a more suitable name for the property, but the underlying principle behind this attribute is applicable to EL coverages.

    Please let me know.

    When I participated as editor of TWG-EL, I proposed to add the attribute 'domainExtent' to the INSPIRE model just because it was mandatory in ISO 19123. At this moment, I was not aware that 'gml:boundedBy' may be used to implement it in GML.

    My guess is that the Editor of TWG-OI followed my path as regards this attribute - To be confirmed by TWG-OI.

    Jordi

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