European Commission logo
INSPIRE Community Forum

Is the Land Cover Class code list to be used or not?

Hi,

I find that there is a need to sort out whether to use any classification or the Land Cover Class code list when implementing Inspire in the Land Cover theme. My interpretation is that the Land Cover Class code list should be used, but I would be interested in the opinion of others.

To give you a bit of background information:

The IRs defines the Land Cover Class (LandCoverClassValue) as a "code list or classification" and says that "the allowed values for this code list comprise any values defined by data providers."

The Inspire code list registry follows the same definition:

"This empty Land Cover code list should act as a container for Corine, other European, national or local code list for LC nomenclature"

http://inspire.ec.europa.eu/codelist/LandCoverClassValue/

However, in the IRs it is also said that

"Data providers may use the values and the integer codes (to be used to represent specific land cover classes in the range of the LandCoverGridCoverage objects) specified for the Pure Land Cover Component (PureLandCoverComponentValue) code list in the INSPIRE Technical Guidance document on Land Cover." This piece of text is referring to Annex H of the data specification. But according to me the values of the PLCC should also be part of the Land Cover Class code list, since you cannot use PureLandCoverComponentValues, but only LandCoverClassValues.

There's a similar case the Land Cover data specification on page 32, where two code lists are mentioned: LandCoverClassValue and CorineValue, but regarding CorineValue its been clarified that it represents Corine nomenclature as an example of the LandCoverClassValue code list.

To make it a bit more confusing it says on page 19 of the Land Cover data specification that “The code list can have any format found appropriate by the data provider. The primary use of a code list is to check that a code found in a land cover data set is valid, and to use the code list as a lookup table to find the textual legend associated with a code. Multi-lingual code lists are recommended in order to support the reuse of data across Europe. Introducing portrayal rules (eg RGB codes) in the code list will promote visual harmonization. Documentation interpretable by computers, allowing applications to convert data between different classification systems automatically help to improve interoperability. This level of harmonization is outside the scope of INSPIRE. Consequently, the data specification does not require machine-readable code lists. It is still recommended to establish machine-readable documentation. It is also recommended to include portrayal rules and a formal definition of the codes. The formal description can either be done by using the Land Cover Meta Language (LCML) defined by ISO standard (ISO 19144-2) or by using a Feature Catalogue as described in ISO 19109 and 19110 (Geographic information - Rules for application schema & Methodology for feature cataloguing).

Overall I find the message is contradictory. Either we use only the Land Cover Class code list and values within that or then we allow “code lists” with different kind of names that are not true code lists in a technical sense.

How do you see it? Do you come to the same conclusion as me that the Land Cover Class code list should be used or not?

  • Dolors BARROT

    Hi,

    I was really surprised reading the guideline because in theory, Land cover information has to be homogenous and comparable between different locations in Europe, based on the infrastructures for Land Cover information created by the Member States (if existing), and made available and maintained at the most appropriate level, but in fact, any classification can be used. There is not a common classification list, nor conditions to describe the code list used in a dataset.

    In the LU theme for instance, two code lists can be used: the HILUCS classification which is mandatory and another code list agreed at national or local level, included in the national codeList register.

    If only one LandCoverNomenclature per dataset can be used to classify the land cover, how it's possible to have homogenous and comparable information in Europe?

     

     

     

     

     

     

     

  • Michael LUTZ

    I'll leave it to the members of the TWG LC to explain why there is no commonly agreed code list to be used for LC data (as there is with HILUCS for LU).

    In my view, the PureLandCoverComponentValue code list mentioned in the IR and included in Annex H of the TG is to be considered as an extension of the empty LandCoverClassValue code list. It is not (yet) included in the INSPIRE registry because it is not formally represented as a code list in the TG (and the UML model).

    If this group agrees it is useful to have this code list formally represented, I will ask the JRC registry team to add it.

    I would suggest to use the code as the id, the "component name" as the label and the description as the definition fields (unless someone can propose a split between a definition and a description for all classes).

    For example:

    • id: http://inspire.ec.europa.eu/codelist/PureLandCoverComponentValue/001
    • label: Artificial constructions
    • Definition: All types of artificial man-made constructions with a sealed surface. It includes
      - roof covered buildings (residential, commercial, industrial, transportation (train stations and airport terminals) etc.)
      - other artificial constructions (e.g. dams, water sewage plants, power plants, dump sites)
      - linear constructions (e.g. railway network, road networks).
      It would exclude surfaces formed by bare surfaces (rock, sand, soil) under anthropogenous influence (e.g. quarries) or other man-made artificial vegetation covers (parks/gardens).
  • Lena Hallin-Pihlatie

    By Lena Hallin-Pihlatie

    Thank you both for your contribution to the discussion.

    Dollors. I hope that a former TWG LC member would be willing to explain why there is no common classification. I would however like to draw your attention to the following requirements and options that the IRs and the Technical Guidelines (LC DS) already outline:

    There are theme-specific requirements in the IRs on how to describe the land cover classification used: "If an onlineDescription attribute is provided for a LandCoverNomenclature data type, the referenced online description shall define, for each class, at least a code, a name, a definition and a RGB value to be used for portrayal. If the online description describes the nomenclature for a LandCoverGridCoverage object, an integer grid code shall also be provided for each class. This code shall be used in the range of the LandCoverGridCoverage to represent the corresponding class." 

    You are also encouraged by the LC DS to describe the classification used by an embedded encoding according to ISO 19144-2 Land Cover Meta Language (LCML) with the embeddedDescription attribute and the use of the LCML provides a way to be able to compare classifications.

    Please also note that the LandCoverExtension application schema supports the use of several nomenclatures simultaneously.

    Michael. Ok, let's see what the opinion and feedback of this group is regarding the PureLandCoverComponentValue code list. 

    I see now that the LandCoverClassValue code list can be extended and populated in several ways, for example by adding an externally maintained vocabulary (case: Corine), by making an extension (possible case:PureLandCoverComponent) and probably also by populating the LandCoverClassValue code list itself. Correct me if I'm wrong.

    To sum up so far, any LC nomenclature/classification can be used, the classification has to be documented according to the IRs (and the LC DS) and the value, label and definition related to a particular land cover class has to be part of the LandCoverClassValue code list, in one way or another.

     

  • Julián DELGADO

    By Julián DELGADO

    Dear Lena, Michael, Dolors

    I participated in the TWG-LU, and we were connected with TWG-LC, even more afterwards in the EAGLE group. Anyway, I encourage to TWG-LC experts contribute in the discussion.

    DS LC could not fix a classes' nomenclature to use as mandatory requirement, because this fact would complicate excessively the national datasets transformation, and in some cases would be impossible. In LC classes matching between different nomenclatures, the conceptual sense behind classes’ definition must be same. If not, the matching is not reached. Example: how to compare 'forest of 30% TCD (tree canopy density)' with 'forest of 10% TCD'? it is impossible to do it.

    The correct way to compare LC nomenclatures is analyzing with LC descriptor elements (example: presence of trees, buildings, water, etc.). This is de focus proposed by EAGLE group and ISO 19144-2.

    Anyway, an homogeneous vision of LC data across Europe is always provided by CORINE Land Cover project. This is other reason why TWG-LC didn't define a nomenclature. In TWG-LU, we didn't find a similar European project and defined the HILCUS nomenclature (mainly built from LUCAS, NACE standard, and UN-SEEA) in order to homogenize a bit the so heterogeneous arena of LU dataset in every country.

    About the idea to publish the PureLandCoverClassValue under LC class value, I'd clearly say no, because they are different concepts. You would provoke a misunderstanding of DS LC. PureLandCoverClassValue are those LC descriptor elements used to form LC class values. In other words, first are the content and seconds, the container. In UML terms, there would be a relationship of composition between them.

    After checking in a practical way the DS LC and XSDs, I reached a conclusion that the best way (and maybe the unique) to ensure DS LC is that, each data provider have to publish on-line a registry with their respective LC classes. Days ago EEA published the registry for CORINE Land Cover.

    https://themes.jrc.ec.europa.eu/discussion/view/27211/codelist-for-corine-land-cover-clc-published 

    Although TWG-LC doesn't exist actually now, the EAGLE group maintain actively the community of LC/LU experts in Europe, so I propose contact with it in case of more DS LC doubts. (Lena and me are involved in the group, we can transmit possible questions).

    https://themes.jrc.ec.europa.eu/discussion/view/3954/the-eagle-concept

  • Michael LUTZ

    Dear Julian,

    sorry to disagree here. If you read Annex H of the LC data specification, the possible usages of the PLCC code list are:

    a) It can be used simply as a kind of nomenclature, and the LC data is entered into the model by application of the code list like a categorization and attaching only one single code from the code list to a certain land cover unit.
    b) The code list can be used in a descriptive way, which gives room for attaching more than one land cover component from the code list to a single land cover unit, expressing that on a particular spot in landscape there exists more than one land cover component. This application of the code list would go in-line with the idea of the descriptive approach of the ISO standard 19144-2 (LCML).
    c) Use the code list like mentioned in b), in a more elaborated way by not only mentioning more than one land cover component to be attached to a certain land cover unit, but also to enter a percentage value and structure description (like in LCML horizontal pattern/vertical stratum), which indicates the relative fraction and spatial composition of the considered land cover component inside the area extent of a definite land cover unit.

    And when looking at the classes, there are clearly land cover classes (e.g. Broadleaved forest trees or Artificial constructions).

    So I fully support Lena's summary.

    On a related note, in the MIWP-6 sub-group on registers and registries, we are currently setting up a testbed for an INSPIRE register federation that will investigate how to best model and work with national and thematic extensions of central INSPIRE code list (empty or not). The LandCoverClassValue and its extensions (e.g. the recently published Corine land cover classification) will probably be one example we will look at.

  • Julián DELGADO

    By Julián DELGADO

    Dear Michael,

    Concepts of LC classes and LC descriptors go further than DS LC can express. Knowledge of it has evolved and matured in last years after DS LC, and go back to proposed PLCC can arise confusions. The PLCC where thought has atomic LC descriptors of the surface, but if you analyze each of them it is possible to identify some LC classes on it. So, the use of this list like LC class values, is not sufficient clear.

    PLCC really atomic LC descriptors: artificial constructions, consolidate bare surface, unconsolidated base surface, coniferous forest tress, broadleaved forest trees, shrubs, herbaceous plants, lichens/mosses, salt/brackish water, permanent snow/ice

    PLCC that represent a complex combination of atomic LC descriptors (real LC classes): arable land, permanent woody/shrubs crops, wetland/marshes, organic/chemical deposits, intertidal flats, water courses/bodies

    But even more important is that LC DS don't motivate to use an unique nomenclature of classes, answered in the annex H question 5. 

    Best

  • Pavel MILENOV

    Dear All,

     

    Although, I was not directly involved in the TWG on LC as a member, I will try to provide some further comments about the scope, nature and applicability of the pure PLCCs. These comments are based on my personal experience and understanding of the subject.

     

    To my knowledge the reason to propose such PLCC within INSPIRE was partly initiated by EUROSTAT in response to similar activities conducted by United Nation Statistical Division. SEEA has proposed a list of “aggregated structures” based on LCCS to be used to produce harmonized land cover statistics at global scale. They were meant to describe the land purely based on its bio-physical nature (land cover). During the global consultation of the land cover classification, EUROSTAT argued that apart of the FAO Land Cover Classification System (LCCS), Eurostat's work on LUCAS and the work carried out in the LC and LU working groups of INSPIRE should be taken into account. Thus, one of the aims of the Pure Land Cover Components (PLCCs) was to provide the concept and method to describe the European land purely based on land cover characteristics for the purpose of the EU statistics, taking into account not only the LCCS, but the European experience from LUCAS and INSPIRE development. Moreover, PLCCS have to act also as a sort of generalized nomenclature - similar to the SEEA one - which can be used as a generic INSPIRE LC codelist (or even enumeration) to which national LC nomenclatures and products will be mapped in order to derive harmonized statistics on land cover at European scale.  

     

    I was indirectly involved in the discussion about Annex G together with Wim Devos from JRC, who was member of the INSPIRE TWG on LC. We tried to design a stratification of the land, based on generic land cover “primitives”. The list of LC types was meant to be:  scale-independent; flat (all LC types are on the same level of detail); exhaustive and unambiguous (LC types are mutually exclusive). We used the UML model of the LCML, combined with the dichotomous approach of the LCCS, by starting this list from the most generic (upper) level of the model with only two main land cover types (biotic/abiotic) and further sub-dividing them by adding land cover classifiers (elements) while going step-wise at lower (more detailed) hierarchical level of the LMCL model. The process was not always straightforward as LCML concept is different than the one applied in the LCCS. I believe part of all this work was used for the design of the PLCCs currently present in Annex G; although the resulted list in the INSPIRE DS is quite different than what we have proposed.

     

    In this respect, I can agree with Michael, that the current PLCC list looks both:

    1. as fixed nomenclature to be applied a one single code for every land cover unit, and
    2. as a set of LC “primitives” used to describe the different land cover components inside the land cover unit, in similar way as SIOSE.

     

    However, I agree also with Julian, that adopting the PLCC as official INSPIRE codelist is not advisable, as knowledge on land cover semantics already evolved and matured, and there are new developments in this respect (EAGLE project, TEGON model) that needs to be considered before such decision is taken.

     

    best regards,

    Pavel

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