European Commission logo
INSPIRE Community Forum

Extent for ExistingLandUseDataset

Dear all

Late days a previous commented topic have arose due to the last clarifications from the consultation issues IR-ISDSS process: ‘extent’ attribute on ExistingLandUsedataset and SampledExistingLandUsedataset. I remember comment it during some informal discussions but I checked and there is no a formal comment in the Cluster. It is important to be commented here to reach and homogenous view on the matter.

Now in the Land Use specifications, the ‘extent’ attribute for ExistingLandUsedataset and SampledExistingLandUsedataset in is modelled like a ‘GM_MultiSurface’. This fact implies an obligation to provide the extent like a whole geometry that represents the concrete contour, vertex by vertex, of the dataset.
In practical sense to get this big geometry implies union and dissolve operations over all geometries in the dataset. For example in Spain we had to dissolve more than 2 million of polygons to get this precise geometry with high processing effort. And the resulting vector geometry is not really practical to be managed locally or served by WFS due to its big volume (millions of vertexes). As LU dataset has not obligation to coincide in limits with coastline, frontiers or borderlines; the traditional vector lines to define national or regional extents are not re-usable.

We remain that the objective for an extent attribute is to provide an estimated information about the place covered by the dataset. In case you need an actual or precise description of the data you can always use the layer of elements that compose the dataset (polygons, points, etc.)
To simplify the management of LU extent, we proposed to modify the ‘GM_MultiSurface’ for other simpler type, more practical and homogeneous with others themes. For example the extent for LandCoverDataset is modelled like ‘EX_Extent’ that can represent a bounding box of complete dataset, too much easy to reproduce. EX_Extent is broadly used in metadata parameters and is well known by many users, and additionally an EX_Extent can be used also in detail for that users that want to still maintaining a concrete contour vector delimitation.

At theoretical level does not mean any inconveniences for exiting implementations, but we do not know about practical implications. EX_Extent --> EX_GeographicExtent --> EX_BoundingPolygon (GM_Object, being primitive root for any geometry type, included GM_MultiSurface).

Do you have opinion about it?

Our best regards


  • Lena Hallin-Pihlatie

    By Lena Hallin-Pihlatie

    Dear Julian,

    Thanks for bringing this issue to discussion.

    I skimmed through the INSPIRE data models to compare also with  the solutions of other vector application schemas. In addition to LC and LU I could only find an example in EF (a voidable attribute: boundingBox: GM_Boundary [0..1]). It was not a thorough analysis, but anyway it seems that the solution of LC and LU, having a separate dataset feature type, is rare, so there doesn't seem to be a Best practice example to re-use.

    I share your concern and think it would make sense to make the implementation smoother and the solutions of LU and LC to be more alike.

    1) One way to go forward would be to change the definition of the extent attribute and to rewrite the TG to  allow other ways to provide and create the extent (MultiSurface). If it isn't feasible to create an aggregation, then a bounding box or the approximate outline (country borders as polygons) could be used. I attended one TWG LU meeting in Helsinki in 2011, I think, where I suggested that to the TWG group and I still think this solution would in many cases be more feasible.

    2) If you go for a change in the data model (extent: GM_MultiSurface to extent:EX_Extent), one could add at least a TG recommendation on to use EX_BoudingPolygon (and if not possible then to use EX_GeographicBoundingBox, and not EX_GeographicDescription), or how would you go about? :

    One could also argue that best practice is to provide the BoundedBy information, but that's another discussion :)

    In alternative 2, the already existing implementations (GMLs) would as I see it not be compatible, and therefore if I have to choose I'm in favour of nr 1). Or have I missed something? 

    What does the rest of you think?


  • Julián DELGADO

    By Julián DELGADO

    Dear Lena, thanks for your input

    From my side, the smarter solution could be to modify the data model changing the definition of ‘extent’ attribute to EX_extent, instead GM_MultiSurface. However this change would motivate the generation of a new GML schema and could provoke inconsistences in existing implementations. At theoretically level seems feasible because EX_extent can be understood as complex aggregation of GM_MultiSurface, but in practical level many uncertainties appears.

    A possible solution can be extracted from Lena’s comment. Specifications could be modified textually with recommendation for appropriate use of ‘extent: GM_MultiSurface’ depending on the complexity of the dataset to be published. In case that the dataset allows the union/dissolve operations use the actual contour of the data including all border vertexes. In case that the dataset does not allow union/dissolve operations due to the higher number of vertexes, recommend to use at least and approximate geometry or a bounding box, but encoded like GM_MultiSurface to ensure current GML schemas.

    I do not know much examples of ExistingLandUseDataset implementations excepting ours. In our last modification of the INSPIRE LU WFS, we decided to make public the dataset ‘extent’ by and approximate geometry sufficient to involve inside the complete country. It is not a bounding box, and not correlates exactly vertex-by-vertex with the LU units, but solves the WFS implementation. You can see our geometry for Spain in the following link (save the WFS request as GML file and open with a GIS software)



  • Lena Hallin-Pihlatie

    By Lena Hallin-Pihlatie

    Dear Julian,

    I see what you mean, but that would need an update of all LU schemas, but the raster (gridded) LU schema, increasing the risk for inconsistencies for sure.

    Let's wait for input on this from others until the end of the week and if others agree (don't disagree), then I will at some point investigate what kind of textual amendments this change would need in practice. And lets then see what the representatives of MIG says.

    In the end, the ETS won't be a test testing whether there is a union behind, but making these textual amendments would make the whole thing more clear and feasible.

    Thanks for sharing your example. Working examples are valuable.




  • Lena Hallin-Pihlatie

    By Lena Hallin-Pihlatie

    Dear Julian, all,

    There is a need to find a solution related to the LU extent:GM_MultiSurface in order to be able to close this issue.

    I looked through all the implementations available with a national scope on the INSPIRE Geoportal a few weeks ago. I could find three harmonised examples. A change in data model would have an effect on these three implementations and possible other regional implementations out there, but I assume there aren't many around yet.

    If changing the data model isn't feasable, then there is a need to make a textual amendment to the the Technical Guidelines of Land Use.

    I'll make a proposal of an updated schema and get back to you for comments.


  • Johanna Ott

    Dear Lena,

    Thanks for taking care of the related proposal! Are there already any news on it? We are running into similar issues currently.


    All the best


Land Cover & Use

Land Cover & Use

Join this group to share your knowledge, learn and collaborate in solving issues related to the Land Cover and Land Use themes