The following section is a narrative description of the INSPIRE Land Cover Data Model using ordinary language and simple diagrammatic illustrations instead of UML. These illustrations and the accompanying text are informal. The purpose is partly to explain the model, partly to assist readers who find UML diagrams difficult to interpret.

Land cover data provides a description of the surface of the earth by its (bio-) physical characteristics.

In the real world, this surface is populated with physical landscape elements (e.g. buildings, roads, trees, plants, water bodies etc.). Many of these elements are themselves spatial features and represented as such by other INSPIRE themes. The physical characteristics of the landscape elements combine to form the land cover of an area. Land cover is in this sense an abstraction and should be perceived as a surface characteristic rather than a collection of features. Mapping and description of land cover is therefore also different from the mapping of the individual landscape elements.

The conceptual starting point of the INSPIRE land cover data model is the "real world" and its (bio-) physical surface of the earth. The surveying, mapping and monitoring of this surface is organized through land cover survey initiatives. A land cover survey initiative is an activity, usually a long-lasting program, carried out by a mandated organization. Examples of land cover survey initiatives are the CORINE Land Cover program (CLC) implemented by the European Environmental Agency (EEA) and the LUCAS area frame survey implemented by Eurostat. Many Member States and regional authorities also conduct land cover survey initiatives serving national and regional needs for land cover information and land monitoring. The assortment of survey initiatives show that land cover can be described, classified and mapped in many different ways, justified by a multitude of applications and user requirements.

Land cover survey initiatives provide a link between other aspects of the model: The real world, users, documentation and data. The "users" are the institutions, agencies, organizations or people requesting information about the land cover, thereby justifying the effort of carrying out a land cover survey.

By far, the most common mapping strategy employed by land cover mapping initiatives is classification. The earth’s surface is subdivided into a set of land cover units, presumably uniform in terms of land cover, and a land cover class (or several if mosaics are allowed) is assigned to each unit.

An alternative strategy is attribution. The land cover unit is in this case described by various attributes providing relevant information about the land cover situation. Examples are the number of buildings or length of paved roads. Attribution is not often used in combination with classification.

The third strategy is parameterization. This strategy emphasizes one particular aspect of the land cover (e.g. soil sealing or grass coverage), describing this aspect as a parameter. The land cover units for parameterization are usually, but not necessarily, raster cells. The pan-European GMES High Resolution Layers have been created as a result of this strategy.

The current development in land cover mapping and monitoring, at least at the pan-European level, is a movement towards integration of these three strategies. Land cover units created by classification are populated with auxiliary information drawn from secondary data sources, which in turn may be created as a result of the parametric approach. The GMES High Resolution Layers are examples of parametric data sources used to populate (by attribution) the units of the CORINE Land Cover dataset, itself a product of classification.

Documentation is the collection of technical documents that describe the data collection methods, definitions, rules for measurement and classification, and other relevant issues explaining the content of the land cover survey. An example is the technical documentation of CORINE Land Cover. The documentation is usually available as text documents, containing indispensable background information required for proper use of the data.

One particularly important part of the documentation is a code list of the land cover nomenclature. This code list is included in the core model and therefore mandatory in INSPIRE. 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).

The data produced by a land cover survey initiative consists of one or more land cover datasets. A land cover dataset is simply a collection of observation units where the land cover has been observed and measured. These observation units are called land cover units in the data specification.

Conceptually, the geometry of a land cover dataset is a partition (in a mathematical sense) of the earth surface and should therefore be represented as a coverage (ISO 19123). The experience is, however, that the land cover mapping community is unable to handle coverage structures. Simple feature points and polygons together with raster structures are therefore, as a pragmatic alternative, used as the geometrical representation of land cover units in this data specification.

The land cover unit is the "geometry of a land cover observation". When a CORINE Land Cover polygon is classified, it implies that a land cover observation is carried out, and the geometry of this observation is the polygon which the observation is attached to. When the field surveyors determine the land cover at a LUCAS survey point they make an observation, and the geometry of this observation is the point. Land cover units are thus the geometrical building blocks of the land cover data specification.

Polygons are included in the model because many land cover mapping initiatives are using this representation. Most notable is the pan-European CORINE Land Cover program. Points are included in the model because this is an observation method used in statistical surveys of land cover. An example is the LUCAS area frame survey conducted by Eurostat. Finally, the data model includes raster as geometry in order to allow representation of the GMES High Resolution Layers at the pan-European level and land cover data developed from satellite imagery at the national level.

Due to the use of simple feature polygons in the data model, the specification also introduces certain geometrical restrictions: Polygons are not allowed to overlap and gaps must be controlled. Controlled gaps imply that the user must be able to distinguish between areas where information is unavailable (eg due to cloud cover in aerial photographs) and areas not covered by the mapping initiative.

The land cover of a land cover unit is observed on a particular observation date. The observation date is the acquisition date of the aerial photo or satellite image in cases where remote sensing is the observation method. For field surveys, the observation date is the date of the visit in the field. Each land cover unit can be observed several times (e.g. sample points visited every year). This is represented in the core data model by allowing several observed situations to be assigned to each land cover unit. There is no limit to how many temporal situations that can be attached to each land cover unit in order to represent a sequence of changes.

The geometry of a particular land cover dataset is static. It does not change. A change in the geometry, created because a polygon is split or because two polygons are merged, must be represented by a new land cover dataset. Spatial data management, and therefore also the business model for management of changes in data set geometry, is the responsibility of the data owner.

The recommended strategies for representing land cover change are (a) to use a fixed geometry and change only the land cover code from one observation date to another; (b) to delineate land cover change features (which are valid only between two reference dates) ; or (c) to use sample points.

The data model

The core model (see also figure above) proposed for the INSPIRE implementing rules represents a land cover data set consisting of a collection of land cover units. The land cover unit can be a point, a polygon or a raster cell. The land cover data set is also associated with a code list with legal land cover codes and their names (e.g. the CORINE Land Cover code list). A land cover code from the code list is assigned to each land cover unit.

The core model furthermore allows several codes to be assigned to each land cover unit (in order to represent mosaics). It is also, in this case, possible to attach a "Covered percentage" to each code in the mosaic. Finally, the core model allows the observation to be attached to an observation date, and several observation dates to be attached to each land cover unit. The observation date is included because it provides important metadata at the observation level and also because it allows representation of land cover change.

The data specification does not prescribe or recommend any particular land cover nomenclature for use in INSPIRE. There is a multitude of different ways to describe land cover. This is partly due to the wide range of aspects of the environment embraced by land cover, but also due to the many different uses of land cover data. There is only one "real world" but many different descriptions of this world depending on the aims, methodology and terminology of the observer. It is therefore a misguided approach to enforce a single classification system as the common classification system for Europe.

The approach taken by this data specification is instead to allow several different land cover nomenclatures to coexist in the context of INSPIRE. The owners of the various code lists are, however, encouraged to document their code lists by using the upcoming ISO standard 19144-2 Land Cover Meta Language or by using a feature catalogue (ISO 19109 and 19110) and provide access to this documentation through a web link for interoperability.

The extended data model, included in the data specification as an informative annex, provides mechanisms for attribution of the land cover units, parameterization and for use of multiple nomenclatures. Since the core model is a subset of the extended model, data providers implementing the extended model are also implicitly INSPIRE compliant.

A LandCoverNomenclature specifies information provided for correct understanding and interpretation of the classification codes contained in the data set.

nomenclatureCodeList

this attribute references the code list attached to the nomenclature. This code list makes links between codes and values (the code being "112" and the value "discontinuous-urban-fabric" if the nomenclature is CORINE).

responsibleParty

this attribute specifies which party (or organisation) defines and is responsible for the nomenclature. It allows giving contact and/or organisation name.

embeddedDescription

it allows using ISO 19144-2 (LCML metalanguage) to provide a description of the classification system with this common metalanguage. LC_LandCoverClassificationSystem is the root class from ISO 19144-2 to instantiate a definition of a nomenclature with LCML.

externalDescription

this attribute allows to provide a set of URL pointing to the documentation (specification or other document) describing the classification system used and the nomenclature used. These URL can be used to point multiple documents, for example in different languages.

NOTE the grid code is the value used to effectively store classifications in raster formats. Values are consecutive (1, 2, 3), each representing a LC class. For more details, see CORINE Table in Annex E. The following table is an extract with class definitions.

For interoperability purposes, it is recommended to provide documentation about the nomenclature in English. Documentation is useful to the widest community of users if it is written in English.

This is an empty code list allowing each data provider to define its own code list for classifying Land Cover objects (points or surfaces). This is done by putting "any" value for the extensibility tag and leaving the vocabulary tag empty.

This code list defines a mapping between codes and values and allows retrieval of Land Cover classification values through their code. CORINE Land Cover code list is an example for this code list.

For example, the following code list for CORINE LC data set would begin with:

NOTE The complete code list for CORINE 2000 and CORINE 2006 can be found in Annex E.

The LandCoverVector application schema models LC data sets (LandCoverData set in the schema) as collections of LandCoverUnit. A LandCoverUnit has a geometry (restricted to point or surface) and supports the Land Cover information through the attribute landCoverObservation.

NOTE The term "surface" is used instead of "polygon" for conformity with ISO 19107 standard. A GM_Polygon can not exist on its own and shall be part of a GM_Surface. The generic 2D geometry object for 2D is a surface (GM_Surface), according to ISO Standard. Conceptually, the difference is that a surface can be an aggregation of patches.

The attribute geometry of a LandCoverUnit is a GM_Object, which is the ISO 19107 supertype for all geometry objects. It is restricted to GM_Point or GM_Surfaces for LC needs.

Additionally, in this core, only one nomenclature (nomenclatureDocumentation) is allowed for each data set.

name

the name of the data set. This name can be the name of the region, a geographic identifier. There is no constraint about its structure.

inspireId

the inspire identifier. It allows to reference spatial objects (features) if needed and follow their lifecycle.

extent

The extent allows describing the temporal, vertical and geographic extent of the data set.

According [ISO 19115], EX_GeographicExtent can be realized through a bounding polygon, a geographic boundingbox or a geographic description (e.g. name of a region …​).

nomenclatureDocumentation

this attribute allows to provide documentation on the nomenclature used in the data set. Please note that the core model supports only one nomenclature per data set. This nomenclature can be CORINE, another european nomenclature, a national one or any other LC nomenclature. It is modelled with the UML class LandCoverNomenclature described in a following section.

The LandCoverUnit represents a section of space which is classified. It can correspond for example to a CORINE polygon.

Each LandCoverUnit is defined by:

The capacity of a LandCoverUnit to support multiple observations allows changes on the same LandCoverUnit and then to make temporal analysis.

The landCoverObservation is described by the class LandCoverObservation:

The LandCoverObservation class defines following attributes:

The observationDate and the mosaic are voidable; it means that they shall be provided if they exist or are easily computable.

All Land Cover information (class and mosaic) are defined according the nomenclature described and referenced by nomenclatureDocumentation attribute provided at the data set level.

One important aspect on Land Cover information is its changing quality over time. Therefore, it refers to a particular situation. A second aspect specific to Land Cover is that it may have a different appearance within one year subject to seasonal or other variations. This dependence can affect the accurate thematic interpretation and classification of particular classes in a given data set and in consequence, also the detection of real land cover change.

Having in mind the two above-mentioned issues, there are several date types to be considered in describing the landscape from the Land Cover point of view. Some of these date types are important when it comes to the comparison of two or more different situations of land cover. On the basis of diverse available date types, the data user is able to extract and assess land cover change information from imagery or other data sources. The following shows a list of date types along the process of land cover data capture and delivery.

The point of time or short period, when a certain type of land cover occurs in reality, is seen as the event date, e.g. storm damage or clear cut in forest areas, beginning of a construction site, finishing of a construction site, creation of a new coastline by enclosing former salt marshes with a dike. The event date would be the most exact information about the point of time when a certain land cover change appears in reality. The monitoring of land cover aims more at different timelines. Also it is rather unlikely to have such information on the event date available for the majority of land cover objects. The storage of the event date for every single case may appear as not feasible and therefore is considered as not mandatory but voidable.

If nevertheless required, the event date can be modelled as voidable attribute

The observation date is considered as the point of time or situation when the land cover information source, which is used for land cover data capture, is recorded. Usually the observation date is equal to the acquisition date of the aerial or satellite image (remote sensing data) used for mapping a particular spatial unit (polygon). Because many images are used in each survey, the actual date can vary from one polygon to another within the same data set. The acquisition date of the recorded imagery would then be attached to every single spatial unit (point/polygon) e.g. according to the geographic extend of the imagery scenes ("footprints"). The observation date can also be the point of time when the land cover information is captured on the ground by a field surveyor. The land cover object in a particular data set can have different observation dates if several information sources were combined to capture the land cover information (e.g. multi-temporal satellite imagery). The observation date is usually different from the event date. This information is recorded by the observationDate attribute (on classes LandCoverClass, LandCoverMosaic and ParameterType).

A reference year or reference date is a (more or less exact) moment, a period of time or a certain time window when the information in a complete data set is assumed to be valid. The time window for the acquisition of a number of satellite scenes or aerial images within a reference period can range between a few days to several months or even years. For example, CLC2006 has the reference year 2006. However, the satellite imagery collection "IMAGE2006", which was used as the information source, was recorded in the time interval between the years 2005 - 2007. Reference dates come into play, when data sets of greater dimension (regional, country or pan-european level) on land cover shall be compared to derive the land cover changes, which occurred during a certain time interval, e.g. between the two reference years of CLC2006 and CLC2012.

The point of time when a spatial unit is edited in the data set can be modelled as

Point of time, when data set (collection of obtained land cover information) is completed and finished. The release date can be considered as the closure of the last data set editing or revision before making the data available to the customers or to the public through online services such as a web map service (WMS).It can also follow after a publishing date and represent the updating or correction of a data set, which then again is published afterwards.

The Point of time when a data set is made available to the public through a data provider and/or declared as valid and put into force for the first time. After a publishing date several release dates may follow, which can represent an updated version of the beforehand published data set.

The observation date (b) shall be provided at the coverage level (=data set) through external metadata with lineage information (dateTime of the observation/acquisition processStep) or at the feature level (through the dedicated attribute observationDate in class LandCoverObservation.

The edit date (d) shall be provided through the temporal attributes beginLifespanVersion and endLifespanVersion at the data set level (LandCoverData set) and object level (LandCoverUnit).

For temporal reference, the Metadata Inspire Regulation requires to provide at least one of the metadata elements "temporal extent", "date of publication", "date of last revision", "date of creation".

The Land Cover specification recommends to provide the reference date (c) at coverage level (=data set) through the external metadata element Temporal reference / date of creation (see Chapter 8) and the release date (e) at the coverage level (=data set) through the external metadata element Temporal reference / date of publication (see Chapter 8).

The current model embodies coverages, which themselves contain one to many spatial units. Over time these spatial units may change their geometry compared to each other from data set to data set, or they may be fixed and keep their geometric extend (regular grid) and only change their thematic land cover information. To represent land cover changes, there are two ways.

One is analytical: The user makes a differentiating overlay between two coverages of different reference dates, he creates the land cover change himself as a result of this overlay.

Second is historical: For each fixed spatial unit the land cover information is obtained according to one to many observation dates over time and assigned to the spatial unit. LUCAS points or grid cells in general are examples of fixed spatial units where land cover data can be "observed" or "measured" at different points in time on the same spot.

A special case is a data set which contains changing information, e.g. the CORINE Land Cover Change data set 2000 - 2006. It does not have a reference year. It rather can be seen as a coverage with "short time" fixed spatial units and two separate situations (observation dates), one referring to the first and the second to the later observation date, which is represented at the polygon level.

The LandCoverRaster application schema models LC data as rectified grid coverages (in the sense of ISO 19123). This coverage supports the same set of attributes as the LandCoverData set (Land Cover Vector application schema) but has some restrictions compared to the vector model: It does not support all the semantic information provided by the LandCoverInformation:

Only the equivalent of the information classValue found in the Vector representation (i.e. the reference to a code list through the type LandCoverClassValue) is then supported by the raster representation of LC data (see figure above, with "rangeSetIsKindOfLandCoverClassValue" constraint). The rangeSet of the raster allows attaching a single classification code, resulting from a classification process, to each raster cell. These can be Corine codes, IGBP codes or other codes corresponding to a national, institutional or local nomenclature.

These restrictions are linked to the formats used to encode rectified grid coverages (as Geotiff) which only support one value per pixel.

Different types of dates are described in section 5.3.1.6.1 above. The following requirement and recommendation using concepts from section 5.3.1.6.1 applies to the LandCoverRaster model.

NOTE 5.3.1.6 applies to raster as well. The only difference is that observation date is removed from LCUnit, but this is anyways voidable

The observation date (b) shall be provided at the coverage level (=data set) through metadata with lineage information (dateTime of the observation/acquisition processStep).

The edit date (d) shall be provided through the temporal attributes beginLifespanVersion and endLifespanVersion at the data set level (LandCoverData set).

For temporal reference, the Metadata Inspire Regulation requires to provide at least one of the metadata elements "temporal extent", "date of publication", "date of last revision", "date of creation".

The Land Cover specification recommends to provide the reference date (c) at coverage level (=data set) through the external metadata element Temporal reference / date of creation (see Chapter 8) and the release date (e) at the coverage level (=data set) through the external metadata element Temporal reference / date of publication (see Chapter 8).