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

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!


  • James PASSMORE

    By James PASSMORE

    Thanks, I completely missed that!

  • Jordi ESCRIU

    Peter / James,

    I think that we should be allowing discontinuous extents, just because the INSPIRE models for Elevation and Orthoimagery coverages give the possibility to aggregate single coverages into a bigger / more complex set (concept of coverage aggregation).

    Peter - As a summary:

    1. Do you mean that domainExtent shall be implemented at the end, regardless having implemented gml:boundedBy,  gml:envelope, or gml:envelopeWithTimePeriod ? (because discontinuous spatial domain extents shall be allowed)

    2. Would not be appropriate to add a recommendation in the TG saying something like this - "The absolute outer bounds of the dataset should be also encoded using gml:boundedBy" ?


  • Peter PARSLOW

    1. yes

    2. may be useful

  • Jordi ESCRIU

    I feel the discussion is mature enough.

    Hence, I close it with the following the mentioned conclusions:

    1. domainExtent shall be implemented, regardless having implemented gml:boundedBy,  gml:envelope, or gml:envelopeWithTimePeriod, because discontinuous spatial domain extents shall be allowed.

    2. It would be proposed to MIG-T It the addition of a recommendation in the TG saying that "The absolute outer bounds of the dataset should be also encoded using gml:boundedBy".

    Please, send me a message if you want to re-open the discussion.

  • Jordi ESCRIU

    This topic was proposed and discussed during the Thematic Clusters session at the end of the Workshop on Transformation of Coverage-based Data Themes and WCS, celebrated the last week in Barcelona.

    It was agreed to continue discussing on it taking into account new aspects and inputs - e.g. for example the overlap of spatial component of 'domainExtent' with the 'footprint' attribute defined for the "OrthoimageCoverage" spatial object (Orthoimagery theme), highlighted by our colleague Julián Delgado, from IGN-Spain.

    I hope we are able to arrive to a more wide consensus by 15th October, in time to send the final agreed proposal for discussion in the Kick-off Meeting of MIG-T subgroup MIWP-14 in Rome (30th November-1st December 2015).


  • Julián DELGADO

    By Julián DELGADO

    Many thanks Jordi for opening again the issues,

    At least from my view, we should propose an easy solution for this case. For OI specifications we have 3 suitable elements to provide the extension of an image: gml:boundedBy, oi:domainExtent and oi:footprint. All of them are different, but unfortunately sometimes can have same value and provoke confusions.

    - gml:boundedBy: complete extension of feature members in the GML file

    - oi:domainExtent: extent of a particular orthoimage = GML feature member

    - oi:footprint: accurate limit of the orthoimage

    I would encourage including a clear distinction of them in the OI specifications, it will help in the understanding.

    About previous questions identified by Jordi months ago:

    1. gml:boundedBy & oi:domainExtent should be implemented. Describing clear that sometimes can have similar value (i.e. only one orthoimage in the GML)

    2. gml:boundedBy is a generic attribution, at least from my opinion we should keep it as simple as possible. If we decide complicate it, this complication should be replicated in all INSPIRE teams and complicate too much the work. Otherwise oi:domainExtent needs more clarification in the OI specifications, in fact an user can use the ISO type EX_Extent that allows many values. OI specifications should recommend and give examples when to use a boundingbox extensions, temporal extension, etc. In most of cases for real orthoimages only a boundingbox is sufficient.

    My best regards

  • Jordi ESCRIU

    Dear Julián,

    I am not sure what you are proposing within the 2nd question.

    Could you please explain it again?



  • Jordi ESCRIU

    Dear Colleagues,

    During the Worskshop in Barcelona we agreed to re-open this discussion topic to take also into account the "footprint" (of type GM_Multisurface) attribute.

    About the "footprint" attribute, just to add that:

    a) This attribute is only present in the Orthoimage coverages (OI data specification), but not in Elevation covarages (EL data specification).

    b) It is defined as: "Geographic area enclosing valid data of the orthoimagery coverage" (i.e. it does not include no data values). 

    c) A notes states that it is a refinement of the geographic domain extent ("domainExtent" attribute).

    d) It is a voidable attribute (let's say, somehow optional) and the cardinality is 0..1 - An additional note states that this property is mandatory in case the OI coverage is an aggregation of other OI coverages, or if mosaic elements are provided.

    As agreed in the workshop in Barcelona - my question for Peter Parslow is:

    Why it is so important to provide the "gml:boundedBy" property? - This property is defined at the level of "AbstractFeature" and has a cardinality [0..1] in OGC 07-036 GML.

    My guess is that this property is common to other types of GML features (i.e. not only coverages) and therefore its use is fully standardized in the GI world.

    But, I would like to ask Peter, who proposed this discussion.


  • Peter PARSLOW

    I thought we'd resolved this six months ago. I hadn't considered oi:footprint (we just haven't got to that theme yet!), and have no opinion there.

    Regarding boundedBy: I've always understood populating boundedBy to be GML 'good practice', but I can't find any explicit reference to that. We (OS) worked with OGC on a 'plug fest' last year; there's nothing about the boundedBy in the Engineering Report (OGC document 14-057), but there was a comment against one dataset which had the boundedBy at the wrong end of the file. I got the impression that all participants just assumed it would be there, and some found it useful. There was some discussion about whether it would be better just to have the srsName on the bounding box rather than every feature - only one advocate.

    And all that was about grid data anyway, not coverage data.

    So I can't specifically defend that it's useful, just a 'normal' part of GML.

    ISO 19136 (like OGC 07-036) says '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.' and further on 'The gml:boundedBy property is provided by a data supplier for convenience'.

    Interestingly, Table D.8 says that the boundedBy property is an implementation of ISO 19123 domainExtent attribute. That confuses the situation somewhat!

  • Jordi ESCRIU

    Many thanks Peter for your input.

    You are right, we agreed about this issue and closed it around six months ago, but somehow new inputs arrived in the WS in Barcelona and decided to get back to discussion taking also into account the "footprint" property.

    I am personally convinced that gml:boundedBy is widely used (for supproting rapid searching of features) and that we should preserve it in the GML implementation.

    It is really interesting to see what Table D.8 of OGC 07-036 GML highlights - the 'gml:boundedBy' is intended for implementing the 'domainExtent' attribute defined in ISO 19123 Coverages conceptual specification.

    The only inconvenients we identified for 'gml:boundedBy' in our discussion is that it does not allow the definition of discontinuous spatial extents and that it is only intended for the geographic extent (whereas domainExtent also allows defining the temporal extent).

    Taking into account all this information, I can see 2 different OPTIONS:

    OPTION 1 (the solution we identified and agreed on 20 April 2015, refined by Julián)

    1a. Maintain the possibility to use all these properties at implementation level, i.e. 'domainExtent', 'footprint' (just in OI) and 'gml:boundedBy'. 

    1b. domainExtent shall be implemented, regardless having implemented gml:boundedBy,  gml:envelope, or gml:envelopeWithTimePeriod, because discontinuous spatial domain extents shall be allowed.

    1c. Propose to MIG-T adding a recommendation in the TGs saying that "The absolute outer bounds of the dataset should be also encoded using gml:boundedBy".

    1d. Describe clearly in the TGs the meaning of each property ('doimainExtent', 'footprint' - in OI only, 'gml:boundedBy') and highlighting that sometimes they may have similar value (i.e. only one orthoimage in the GML).

    OPTION 2

    2a. Using 'gml:boundedBy' property just for describing the outer bounds of the data set - If discontinuous spatial extents exist, this could be described under the 'footprint' property.

    2b. To use 'footprint' property (as described in OI TG) for refining somehow the information reported in 'gml:boundedBy' - i.e. in more detail, showing the discontinuous spatial extents if present.

    2c. Consequently, add the 'footprint' property to the EL grid coverage schema in the EL TG.

    2d. Set multiplicity of both 'footprint' attributes to 1 (it is currently 0..1 in OI TG), therefore making it mandatory (as 'domainExtent' now in both TGs, OI and EL).

    2e. Remove the 'domainExtent' attributes from both application schemas, EL & OI coverage schemas.

    What do you think?


This discussion is closed.

This discussion is closed and is not accepting new comments.

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