European Commission logo
INSPIRE Community Forum

Discussion about amendmends for TG Land Cover and Land Use

Find attached a first proposal for for amendments to the TG for Land Cover and Land Use.

Austrian proposal for amendments to the TG for Land Cover and Land Use.

Following changes are described in detail in  the attached dcument
TG Land Cover
AT001: Change relationship between LandCoverDataset and LandCoverUnit from the specialized association type “aggregation” to a normal association link.
AT002: Add the association role name dataset to the association LandCoverDataset – LandCoverUnit
AT003: Change the multiplicity for association role name dataset from 1 to 1...*

TG Land Use
AT004: Change the multiplicity for association role dataset from 1 to 1……*
AT005: Change the multiplicity for association role name “member” from 0 to 1...*

This document is only a first idea sketch and should serve as a basis for discussion.

With the hope to initiate a fruitful discussion
Best regards.


  • Julián DELGADO

    By Julián DELGADO

    Dear Roland, I revised your proposals

    About AT-001, 002, 003, I agree, these changes would simplified the implementation of WFS and GMLs for Land Cover theme.

    About AT-004. As I understand, the reason to propose the change of multicity from the dataset side, is because a land use polygon can be in more than one dataset because does not change in the time period of the datasets. The idea is good and implementable, but would carries with more implications. At the moment the considerations for (LU or LC) datasets are ‘status layers’ from one particular datetime. Status layers ease the user interpretation, publication by webservices, etc. In summary… allowing (LC or LU) polygons in more than one dataset we would open a discussion about publication of ‘status layers’ dataset or ‘temporal continuos’ dataset in INSPIRE.

    About AT-005, LU data is hard to be implemented in some cases, data can be addressed but not digitalized, or historically described at least only by the dataset and not by the polygons. From my side, I’m ok to accept multiplicity 1..*, if there is a consensous by the INSIRE community.




  • Lena Hallin-Pihlatie

    By Lena Hallin-Pihlatie

    Dear Roland, Julian, all, 

    Many thanks for initiating this discussion.

    Regarding AT-001, 002, 003 I would have agreed with you a few months ago. However, at this point, I'd  actuallyprefer to be even more radical and suggest to drop the whole LandCoverDataset feature type as the same information can be derived from the LandcoverUnits or can be recommended to be put in the metadata. What do you think? Would that be too radical :)?


  • Katharina SCHLEIDT

    By Katharina SCHLEIDT

    Short note from back in the cheap seats - where would you provide the information on nomenclatureDocumentation?

    To my understanding, this is the only relevant bit of information added by the LandCoverDataset. At present, seems the only accepted codelist is Corine; however, if other nomenclatures are used, some information on the nomenclature should be provided somewhere (I'd recommend adding a reference to LandCoverNomenclature from LandCoverObservation, while making LandCoverNomenclature a featureType (otherwise cannot be referenced via OWS))

  • Lena Hallin-Pihlatie

    By Lena Hallin-Pihlatie

    Kathi & all:

    Precisely, the nomenlatureDocumentation information is the most relevant, if not the only relevant. bit of information added by the LandCoverDataset and there is already a reference to the values of the nomenclatureCodelist from the LandCoverObservations in the LandCoverVector model. Assuming that the definitions of the code list values would be better in place that they are at the moment, I suppose this would meet most of the needs or do you disagree?

    You can extend this code list with any values. It's not only aimed for CLC:

    Examples of extensions by EEA and Eurostat can be found for example here if you search for 'land cover' or 'urban atlas':  .It would be great if these could somehow be linked to the INSPIRE Code list register, so that they could be more easily found for reuse.

    I actually had a thorough look at all the existing  LandCoverVector implementations on the INSPRIRE Geoportal and several of them haven't implemented the LandCoverDataset part at all, only the LandCoverUnit part. All of the examples I've looked into the nomenclareDocumentation is just pointing to an URL of a document (all actually not working..), which cannot be resolved by a machine anyway, I suppose. The alternative to provide nomenclatureDocumentation as an 'embeddedDescription' hasn't been used - and this option cannot be used without an update of the ISO LCML standard, which may take years. But also in this case perhaps its enough to have a separate XML with a link from the metadata.

    So in order to make implementation and use easier:

    1) the nomenclatureDocumentaion information could be put in the metadata (suggestion below) for easier implementation and maintenance, or

    2) go for the suggestion by Austria/Roland to "Change relationship between LandCoverDataset and LandCoverUnit from the specialized association type “aggregation” to a normal association link."


    In option 1) one could put a link to the document describing the used nomenclature (PDF or XML) in the metadata for example here:

    /gmd:MD_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:report/gmd:DQ_DomainConsistency/gm d:result/gmd:specification

    What do you think?


  • Johanna Ott

    Hi Lena, all,

    I think dropping the LandCoverDataSet (and for the same reasons the LandUseDataSet) would make sense and safe data providers from issues caused by links to too many members (can cause issues for WFS creation) and by computing the extent (as discussed in this thread).

    Are there any news yet on how these issues will be handled?


    All the best


  • Lena Hallin-Pihlatie

    By Lena Hallin-Pihlatie

    Dear Johanna, all,

    Thanks for your valuable feedback.

    About the handling: There is a list changes which is waiting to be approved by the INSPIRE committee, which contains changes to application schemas etc collected until 2018. Once these changes have been approved, we've been told that a new list of change proposals related to the application schemas, codelists etc will be considered. This list compiled by the Community Forum facilitators already exists, however, it will surely take a while to get it officially approved.

    One way to speed up the process to get approval for dropping the LandCoverDataSet and LandUseDataSet feature types would be to publish a working solution and to describe it in a Good Practise document. The acceptance procedure for the Good Practise document is very smooth: they are first discussed and accepted by the MIG-T group, after which they are approved by the MIG.

    Best regards,


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