Land Characterization System Software: Implementing Land Cover Ontology

Abstract

Land cover (LC) plays a crucial role in the monitoring and planning of the environment among various domains, such as climate change, the management of natural resources, and sustainable development. However, inconsistent LC legends hamper their usability, particularly as technologies, like remote sensing, rapidly improve data quality and quantity for extracting valuable information. Ontologies play a pivotal role in improving the standardization and harmonization of different LC taxonomies, enabling both a reduction in inconsistencies and a way to harness ever-increasing computing power to help scientists provide faster and better answers. However, using ontologies without suitable tools, especially when expressive power is matched with complexity, can prove a daunting task. This paper introduces the land characterization system (LCHS), an innovative tool built to support the ontology discussed in the ISO 19144-2 standard, known as Land Cover Meta Language (LCML). The LCHS can help streamline and speed up the creation and editing of LC legends using a data-driven design approach.

1. Introduction

Many initiatives have been undertaken to define land cover classification systems that different organizations in different countries can use. At the European level, one of the most used is the Coordination of Information on the Environment (CORINE) land cover (CLC) system [1,2]. It aims to standardize land cover classes in European countries by clustering those in each territory. It establishes three distinct levels of detail, with the coarsest one comprising five classes and the finest refinement consisting of 44 classes. Each class has a three-digit code, a name, and a short definition. A much longer description can be included for correctly interpreting the class. Unfortunately, assessing similarities for comparing legends and classes by employing text definitions, even if supplemented by more extended clarification, is bound to be a source of ambiguity, as reported by J. Feranec et al. [3]. Additionally, it requires a substantial amount of time to compare them.

Given the importance of an efficient assessment of land cover and related changes for the Sustainable Development Goals of the United Nations Agenda 2030 [4,5], among various other uses of land cover information, it becomes paramount to define, promote, and use international standards for providing a reliable basis for the interaction of systems at the local, national, regional, and global levels.

The Food and Agriculture Organization of the United Nations (FAO) is actively providing support to develop solutions to support data interoperability, considering its strategic framework 2022-31 to “support the 2030 agenda through the transformation to more efficient, inclusive, resilient and sustainable, agri-food systems for better production, better nutrition, a better environment, and a better life, leaving no one behind”1. Good practices spread faster and more efficiently only if information flows freely among countries and organizations.

Developed in the early 2000s, the Land Cover Classification System (LCCS) is an example of harmonization and interoperability system [6], designed to be comprehensive, consistent, flexible, and able to describe the complete range of land cover features, among other objectives. The LCCS evolved into the LCCS version 2 based on the experience gained in numerous country mapping activities [7]. In 2003, FAO submitted the LCCS concept to the International Organization for Standardization, and it became the international standard in 2012 as ISO 19144-2 “Geographic information—Classification systems—Part 2: Land Cover Meta Language (LCML)”. As a metalanguage, it does not aim at replacing any classification systems, instead aspiring to provide “a common reference structure for the comparison and integration of data for any generic land cover classification system” [8].

With the advent of the ISO 19144-2 standard (LCML) in 2012 and its revision2 in 2023 [9], the representation of LC classes is possible through UML-like models, basically tree-like structures with connected nodes (mainly corresponding to essential elements and characteristics). The hierarchy of the nodes becomes vital to the definition of the classes. Due to this, a specific editor was needed, and the LCCS3 tool was developed as an application running on the Windows OS [10,11].

Unfortunately, updating LCCS3 was not considered feasible due to a few drawbacks, including: (1) discontinuation of active development since 2015; (2) reliance on some “hard-coded” logic where the editing of every basic element required the development of some ad-hoc user forms for collecting data; (3) limited access to the source code.

The evolving nature of standards, therefore, required an updated software application. Furthermore, many ISO standards are accompanied by a UML as their description language. This provides an opportunity to develop new tools based on UML models. This paper focuses on the analysis, design, and implementation of such a tool.

The tool has been developed to replace LCCS3 and also built around LCML ontology. In doing so, and considering the evolving nature of standards and the new technologies already available, the work described here presents three major advantages: (a) it facilitates maintenance and updates, both as a consequence of source code policy ownership changes and especially its data-driven approach based on the UML model of the standard; (b) it redesigns the user experience and expands the support enabling it to work on tablets too, despite its client/server architecture, as well as in situations where internet connection is unstable, like during field data collection; (c) it integrates with other tools, further enhancing its interoperability.

The work here is structured as follows. First, the methodology for the design of the software is introduced. This was influenced by high-level objectives that were known a priori and through stakeholder consultation.

The results of this process are three-fold: (a) an analysis of functionalities endorsed by users; (b) subsequent design of the software architecture and its implementation; (c) an overview of how the design and implementation contributes to shaping the user experience. Eventually, as user needs change, evolve, or are simply better understood, both the standard and the software will be required to keep pace with the new requirements, and the data-driven design will help in lowering the effort required. A discussion of the novelty of the approach is covered through an example. In particular, a land cover class available in CLC is carefully examined to highlight how to model it using the LCHS. The conclusion presents possible future enhancements.

2. Methodology

The design of the new tool is based on five “pillars”, as shown in Figure 1. One of the primary objectives was to develop a tool more closely aligned with an open-source model. ISO 19144-2 was started in 2012. It was reviewed and confirmed in 2018 without any changes3. However, following increasing sensitivity toward the different needs between land cover and land use aspects, an important update was seen as necessary in the last review process, and a revised ISO 19144-2:2023 is available4. This brought to the fore the necessity of heavily revising the editing tool for LCML classes and legends, that is, LCCS3 software.

Active development of LCCS3 was stopped in 2015. Moreover, the application was initially subcontracted to an external developer, which kept the program as a closed source. This meant that any changes would require to be agreed upon and made with the original authors. In order to initiate a new project, it was, therefore, clear that a different strategy was needed. Therefore, the FAO, in close collaboration with the National Research Council of Italy (CNR), developed the LCHS. LCHS software is open-source.

Moreover, by developing open-source software, the initial author grants the possibility to others to use and modify the software, carrying only limited restrictions in the way the code is used, changed, and distributed. This fosters the cooperation of a much larger audience of skilled developers and experts, potentially enabling the system to evolve in initially unforeseen ways.

For the procedure of renewing the software system that was initially designed for Windows XP, it needed a different design and user interface in a “post-PC” era, in which computing is increasingly performed on tablets and smartphones. Moreover, since the software is intended to replace an existing type, it was possible to gather feedback on the user experience of LCCS3, aiming to preserve the most useful functionalities while, at the same time, attempting to simplify the interface in an effort to enable the application to run on a wider number of device types. Another important point to make is in regard to the nature of standards and their repercussions on designing new software.

An ISO standard, such as LCML, requires the involvement of several experts in a particular field, contributing their wisdom and expertise toward a common goal. The definition of a new standard involves a structured process consisting of several stages spanning a few years. However, the standard is likely to evolve over time, with successive formal revisions. A development goal is, therefore, to design and implement a system that can evolve with the ISO standard itself, possibly with limited effort, or even better, no effort at all. This can be achieved by embracing a data-driven approach. By considering LCML metalanguage, this means that the types of basic elements, properties, and characteristics should be extracted by the LCML specification itself to automatically populate forms and other user interface elements wherever possible.

Furthermore, while the project considered in this work is effectively focused on the development of a graphical editor for land cover classes and legends, the FAO, through its Geospatial Unit at the Land and Water Division, is actively involved in developing related standards, in particular, ISO 19144-3 [12], a metalanguage that allows for describing different land use classifications systems. It builds on the foundation of LCML, complementing it and enabling the descriptions of combined land cover and land use. Given the close proximity of these standards, a future need for integrating these aspects in the most effective way has already been foreseen. This will lead to refining the same software to address multiple scenarios and use cases, although the ISO 19144-3 definition is still in its early stages. Nonetheless, the requirement was considered wherever possible.

Aside from the high-level objectives, it was considered helpful to identify the different potential stakeholders for using the outcomes of the design work, i.e., the software. An overview of the stakeholders that have been considered in the design and development of the LCHS is provided in

Table 1. Stakeholders in the design of the software system.

Stakeholders	Role and Interests
FAO	Funds the development of the new editor. Aims to enhance agri-food systems for better production, nutrition, environmental quality, and quality of life.
Surveyors, GIS, and remote sensing experts	The intended “users” of the editor. They seek efficient and unambiguous representation and interpretation of geographic data.
Researchers	Could be potential users and, eventually, contributors to the project. May utilize and extend the project in novel directions.

.

Land cover and land use are among the fourteen fundamental data theme layers recognized by the United Nations. Developing standards for land cover (and land use) enables a more efficient use of the information available in the different countries and regions. For this, the FAO has developed different software services in support of updated, harmonized, and efficient data. In particular, the FAO developed the Land Cover Legend Registry [13] (LCLR) in 2021. This registry includes a land cover legend at the local, national, regional, and global levels in different file formats (.csv, .lccs, .eapx, and .xsd).

Stakeholders were consulted in the development of the LCHS through surveys, the results of which are highlighted in

Table 2. Survey questions, with an overview of the gathered data.

Section	Gathered Data
#1: Personal data	First and last name; country (place of work); organization; email
#2: Professional background	Years of experience with FAO land cover classification software tools (both specific and open-ended/others); years of experience with land cover mapping tools (both specific and open-ended/others); other image processing/GIS software
#3: IT tools and workflow	Preferred working device/setup for working with land cover, in office and in the field; preferred type of notes gathered while working
#4: IT land cover editors	Usability opinions on different functionalities of LCCS3; additional (open) comments on LCCS3; wish-list of new functionalities to implement; preferences on integration between the new land cover characterization software and external image processing/GIS software (with both specific and open-ended options); preferred export/reporting functionalities; availability for further involvement and type of involvement

.

The survey covered various topics from the software architecture to the distribution model. The survey targeted a diverse group of stakeholders and focused on gathering feedback about LCCS3 software. An overview of the gathered data from the survey questionnaire is available in Table 2.

The survey results highlight the growing importance of web platforms and portable usability, with 72% of respondents desiring a system compatible with both desktop and field use. The participants also expressed interest in geotagged image annotations and better interoperability, with GIS solutions like ArcGIS, QGIS, Google Earth Engine, or SEPAL. Aside from collecting opinions on possible functionalities of the new software, the survey also presented an opportunity to evaluate the features available in LCCS3, in an attempt to preserve the most useful ones and suppress, or enhance, the ones deemed not important. The reported opinions were aligned with a previous analysis but also highlighted the recommendations on advanced features in LCCS3, such as custom characteristic definitions.

While most of the functionalities requested by users were implemented in the initial version of the LCHS, the survey results still offer crucial insights to guide the system’s design and implementation. Beyond that, they proposed a well of opportunities that can be harnessed in the future while improving the software system.

3. Results

The analysis of the design requirements suggested the need for a system that is not only cross-platform but that must also function effectively on tablets. The process centered around developing a web application with the capability to connect to a central server when necessary and possible. Indeed, an initial questionnaire targeting potential users revealed that internet services could be unreliable or intermittent in some cases. Consequently, the system was designed to operate effectively in limited environments, offering reduced functionalities when constraints are present, and providing expanded capabilities when unconstrained, such as the storage of land cover legends and classes on a central server and other advanced functionalities requiring a connection.

To facilitate the presentation of key highlights related to the LCHS, this section is broadly divided into three parts: an overview of the system design and architecture; insights into user experience; and a detailed exploration of available functionalities for further customization.

3.1. Overall Design and Architecture

The system design is based on a client/server solution. The client is conceived as a progressive web application that relies on local storage for most of its operations, reducing the need for frequent data exchange with the server. This ensures that the application can function on the tablet or computer even when offline. However, certain functionalities, such as importing land cover classes from the LCLR, saving and loading legends, and importing classes from other users (with explicit permission), require an internet connection and authentication with the server.

It is essential to note that the LCHS is data-driven, primarily importing entities from a unified modeling language (UML) model specification. This approach streamlines the inclusion of new elements with minimal effort, simplifying future system maintenance. Nevertheless, some exceptions and compromises were necessary in specific situations. Indeed, the system does not directly access the LCML UML model.

This design approach allows for versatility in accommodating different devices and operating conditions while maintaining data integrity and flexibility in the system’s core structure. The LCHS server is based on Python using the Django framework. It handles user registration and authentication, manages land cover legends and classes, and acts as a proxy for interfacing with other platforms, including those developed by the FAO. Data exchange with the client is conducted through a mix of REST and ad-hoc web services. A Postgres-like database with a JSON extension stores the managed data, and the user data requirements include a username, email, and password. An ad-hoc service is in place to act as a proxy for importing land cover legends and classes from the LCLR. This way, the web server acts like a bridge between the LCHS clients and the LCLR system, avoiding cross-origin resource sharing (CORS) issues, which can happen when an LCHS client tries to connect directly to the LCLR system. For the LCHS client, Javascript/Typescript with React 18 is used.

React is a free and open-source front-end Javascript library [12] initially released in 2013 and maintained by Meta (formerly Facebook) and a community of additional developers. This should ensure better chances of continued support due to the combined backing of a large technology/media company and a broader community of individual developers and companies. Data, including the current legend and land cover classes, are stored locally using HTML5 local storage for seamless access. The system employs React Flow [13] for managing directed graphs for graphical representation. The library can be used to display any graph, and therefore, LCML, which is a directed, acyclic graph, can be shown as well. The styles of both nodes (basic elements, element and class characteristics, and other structuring nodes) and links (relationships between them) have been customized. The styles used aim to find a balance between a formal UML-inspired representation and something that a broad audience can easily interpret. This means retaining a UML class appearance with a name and some properties attached to the nodes.

Last but not least, as reported previously, one of the primary objectives was to facilitate the adoption of new revisions to the LCML standard. A UML reference model is part of the standard and the ISO TC/211 processes [14]. Therefore, exploiting this formalization as much as possible was deemed important. A Python script is responsible for extracting the required data from the UML model of LCML, usually designed in Sparx Enterprise Architect. This serves two purposes: it optimizes the data format for a faster client response time and enables data integration from additional sources without modifying the client code or making changes to the UML model standard.

For example, it enables the identification of all the properties of a basic element like LC_Shrub pre-emptively, without navigating at the run-time the inheritance tree established in the UML model, both simplifying and speeding up the client response time. It can also better target the specific software audience. Additionally, documentation of the UML model parts, and even the node and relationship names, can be revised for better readability considering the intended LCHS audience. To perform preprocessing, the UML model is first exported in XML format using XMI1.1 dialect. The script outputs the processed specification in the form of a JSON dictionary, which is later packaged with the LCHS client itself. A schema is shown in Figure 2.

3.2. User Experience

The most conspicuous disparity between LCCS3 and the LCHS is notably evident in the user interface. This redesign was deemed necessary due to the diverse hardware specifications that the system now targets. While LCCS3 was expressly tailored for desktop computers operating on the Windows platform, the LCHS accommodates a considerably wider array of devices. Whereas the presence of a sufficiently sized monitor (e.g., 21 inches) can be assumed for desktop computers, this assumption does not hold true for tablets.

However, the issue extends beyond mere screen space, encompassing challenges associated with the input interface. Whereas desktop computer (or notebook) installations can confidently rely on a mouse or touchpad for the precise selection of interface elements, tablets pose a different challenge. Pointing to objects on a touchscreen with comparable precision is notably more daunting. Notably, this requires a simplified user interface.

LCCS3 comprises seven screen areas, as shown in Figure 3, sometimes with overlapping functionalities and the disadvantage that they are shown in a very tight area, severely limiting the readability and usability. For example, users must zoom in to understand the abiotic element and connected entities, making it cumbersome. The information displayed in the figure remains static and continuously takes up valuable screen space. The “shelf to evaluate the legend classes conformance to LCML rules” displays warning and error messages, which should be shown on demand, especially if there are no issues to report.

Various panels, such as the legend pane, legend graphic overview, and legend element list, show different aspects of the legend and its classes. However, none of them present all the associated information.

User feedback suggested the need for a flexible system that is usable in both office and field settings. As highlighted by the survey results, this requirement is driven by factors like company policies limiting software installation, the benefits of mobile data collection, and the coexistence of PC and post-PC worlds.

To address these needs, an ideal approach is creating a hybrid system that caters to desktop and mobile devices. This impacts UI design, necessitating the utilization of more prominent UI elements for touch-based interactions on post-PC devices while remaining usable on traditional desktops with keyboard and mouse inputs.

The new design is shown in Figure 4. The screen space is divided into fewer sections, and certain sections, such as error messages, are displayed only when requested or needed. This approach ensures adaptability across different devices and offers a more efficient user experience, with contextual functionalities and support.

For example, the LCHS needs to distinguish between registered and logged users and others who prefer to use the software independently without relying on the LCHS server.

The functionalities are shown or hidden, depending on the current context.

Moreover, the ISO 19144-2 standard dictates that a minimal land cover class is composed of a descriptor, a horizontal pattern, a stratum, and a basic element graphically represented with named boxes, called nodes in the system (this is due to the affinity between a land cover class expressed in LCML and a network graph). Constraints exist. For instance, a stratum cannot exist without being linked to a horizontal pattern; a horizontal pattern must be connected to a descriptor.

When a class is incomplete, warnings and messages are shown near the node violating the constraint, most likely a stratum in a newly created class. A circular add icon enables the establishment of a connection between an existing node and a new one, and it is placed on the right side of almost every node in the graph. The user can then customize the LC class by adding additional nodes and declaring the values of specific properties, which further define the class, as shown in Figure 5. This usually starts by adding a defining element to the stratum. Connections have a type, and once the add icon is clicked/tapped, the user first specifies a connection type and then a node type. Users can further customize nodes by adding specific properties, as in Figure 6, meant to describe further, customize, and differentiate among different land cover classes.

Properties can be of various types, including strings and numbers, in both integer and absolute values. Since land cover classes are for describing whole areas, most of these properties are defined in terms of a range of values instead of a single value. Most of the properties are also accompanied by a description showing what the property is about.

3.3. Additional Functionalities and Further Customization

The system uses the browser’s local storage for data persistence so that users can also work offline. There is, however, support for saving locally or remotely on an LCHS server, providing additional functionalities, like the possibility of switching legends, moving the work to other devices, and sharing their legends with other users. Data can be imported from LCCS3 and the FAO Land Cover Legend Registry. There are also export functionalities for external software and the possibility of generating reports at the land cover class or legend levels. Even though the LCHS strives to follow the standard as closely as possible and uses this to its advantage for understanding how building blocks can be linked to each other or what properties can be customized for each one of them, it can be tailor-made in a few ways, in some cases following exactly the standard, while in others, exceptionally, going beyond it in an attempt to better integrate with external tools or to accommodate specific needs. For example, custom and predefined lists are available in some cases, while in others, the standard provides empty lists, encouraging users to customize them. Users can select the enumerated types and use the values, as well as add values through the panel. Some essential elements, like built-up surfaces, provide fields such as the construction material, whose list of predefined values is empty to allow users to provide their code lists. The system can suggest additional options during the editing of properties by adding custom values.

While the list of properties, also called attributes, provided by the LCML standard can be too rigid for a particular use case, the standard (ISO 19144-2) explicitly allows the definition of additional properties for essential elements and class characteristics through a standardization process, which will be covered in the upcoming ISO 19144-4 [15] standard. The definition of new properties, therefore, is a practice that should be considered with extreme care. Currently, the LCHS does not restrict the definition of new properties, additional properties can be only of text type (“CharacterString” in the standard), and additional properties need to be added per node, with no intrinsic support for derived types.

As such, if a user defines an extra property for the generic woody growth form, for example, it is the user’s responsibility to determine the same property for the shrub and tree types as well to ensure consistency, with the system not enforcing it.

Additionally, the ISO 19144-2 standard allows for the definition of custom characteristics that can be associated with the whole class or specific basic elements.

The LCHS enables the definition of custom characteristics. The definitions of custom characteristics in the LCHS is very similar to those in LCCS3, as shown in Figure 7, following the suggestions received in the survey.

The user defines a custom characteristic by providing a short LCML name, a readable name, and a short description. Since the custom characteristic could be relative to a class characteristic or specific basic elements, this information is needed during its setup. It is also necessary to specify if multiple instances of that custom characteristic can be linked to the same parent node.

4. Discussion

While this paper is focused on the design and implementation of land cover characterization system software based on LCML, discussing the merits (and limits) of the LCHS would become futile without considering the broader context of LCML. Although LCML is an ISO standard, it is far from the only standard being used for describing land cover. CORINE Land Cover (CLC), for example, is considered a de facto standard and widely used in Europe. It can be useful to compare how a land cover class can be described in CLC and in LCML and how the LCHS facilitates editing LC classes in LCML. It is important to stress that while CLC is a classification system with a fixed number of classes, LCML is a meta-language meant for interoperability that can be used to describe generic classes, including the ones present in CORINE Land Cover.

The class “olive groves” is one of the 44 thematic classes in CLC describing a parcel of land as being of the olive grove type and is defined by attaching a label with code “2.2.3”, representing “cultivated areas planted with olive trees” (a complete description of the LC class is available in

Table 3. “Olive groves” in CLC (from https://land.copernicus.eu/content/corine-land-cover-nomenclature-guidelines/html/index-clc-223.html, accessed on 12 April 2024).

CORINE Land Cover

CODE: 2.2.3, Cultivated areas planted with olive trees. This class is applicable for: Homogeneous olive groves: plantations of Olea europaea ssp. europaea; Olive groves intermixed with vines or fruit trees, with >50% occupancy of olives; Olive groves intermixed with annual crops, with >50% occupancy of olives; Rainfed as well as permanently irrigated olive groves. This class includes: Olive trees; Vines or fruit plants intermixed with olives; Bare soil or herbaceous vegetation among olive trees; Scattered patches of semi-natural vegetation (greenery); Interspersed annual crops occupying <50%; Irrigation ponds. This class is not applicable for: Non-permanent crop areas shaded by a canopy of olive trees on the same parcel, with non-permanent crops occupying >50% of area (class 241); Parcels of olive trees intermixed in a mosaic with non-permanent crops (arable land), the latter occupying >50% (class 242); Olive trees (Olea europaea ssp. sylvestris) as part of evergreen forest areas (class 311); Wild olive trees (Oleaster spp.) as part of sclerophyllous vegetation areas (class 323); Abandoned olive groves (class 323 or class 322—only in Northern Iberian Peninsula).

). Since CLC was primarily developed for the Pan-European land cover and land use inventory, the class can be used regarding homogeneous olive groves of the “olea europaea” type.

It is noted that in the same area, other vines, fruit trees, or other crops can be present; provided that more than 50% of the area is occupied by olives, we can still consider it an “olive grove”. LCML does not provide a fixed number of classes, nor predefined classes. Instead, it provides building blocks, mostly in the form of physiognomic basic elements, such as “trees”, “shrubs”, and “herbs”, along with other kind of blocks, representing additional information. This way, an unlimited number of classes can be obtained. Additional properties and characteristics per block can also be added as required. Considering the setup, the representation of olive groves in LCML can be directly derived from interpreting the guidelines in Table 3.

Some of the additional (but optional parts), such as irrigation ponds, for the sake of brevity in the LCML description, are not considered in the provided conversion, shown in Figure 8, as recreated in the LCHS by either assembling the graphical blocks individually or by importing classes from the FAO Land Cover Legend Registry (LCLR). Indeed, CLC, along with many other national and regional legends converted and represented in LCML, are available in the LCLR and can be imported into the LCHS.

While the class code “223” is sufficient to identify olive groves in CLC, the representation in LCML is on a completely different level. First, it is a graphical representation and more complex, at least at first glance. This complexity derives from a more detailed formalization of the detailed description with respect to CLC, in particular the “This class is applicable for” and “This class includes” parts.

Although this level of formalization can seem excessive at first, it has several advantages since there is better distinction between land use and land cover. In CLC, if a patch of land of olive groves is abandoned, it must be represented with a different code (323 or 322).

In general, in CLC, there is no clear separation between land cover and land use. In LCML, the patch of land is always represented in the same way and it can be used both for land cover and land use since these data are conveyed in a specific node (“Cultivated and managed vegetation characteristic”). Additional information, like the species name, is formalized as well, and elements can be present or not (optional), such as the shrubs, or even the part of land that should be occupied by the various elements.

Three advantages are realized by this approach: (a) it is a formalization that is machine interpretable; (b) the formalization reduces ambiguity; (c) the same formalization can be performed once and used multiple times, even in different contexts.

CLC uses three-digit strings to represent LC classes, with the first digit corresponding to the more high-level classifications. Using the extended natural language description as the main guide can result in different interpretations, as shown in [3]. LCML, on the other hand, aims to combine more basic elements, which can be more easily recognized and agreed upon. The structure of the LCML classes, akin to a diagram, can be interpreted more easily by a computer program. This structure enables the formalization of a land cover class, eventually augmenting it with land use data, and the reuse of the same specification in many situations. As a consequence, the representation of olive groves in LCML can be used for both land use and land cover.

Land use data are stored in separate “characteristic” nodes and bound at the basic elements level, or even at the class level in the form of class characteristics. In this example, the olive groves are cultivated because the olive trees are specified to be “cultivated and managed vegetation”. The trees themselves are labelled as olive through a different characteristic node, “Floristic Aspects”. They are considered olive groves because they occupy between 50% and 100% of the land. This description states that shrubs can also be present, but optional, and should occupy a smaller area.

It should be noted that CLC has lately been revised and currently features two components, CLC+ Backbone and the related CLC+ Core suite [16]. This has been carried out to offer more flexibility, enabling the creation of “CLC+ instances” customized for specific needs and applications, like land use change, and forestry. The Copernicus community has also felt the need to better separate land cover and land use. CLC+ achieves this by employing concepts introduced in the EAGLE matrix and data model [17]. The former provides a tool and references for decomposing class definitions in land cover, land use attributes, and further characteristics. The latter aims to define conceptual data models via UML charts to separate land cover from land use, as detailed in the INSPIRE directive and related technical guidelines [18], mimicking some choices already made in the ISO 19144-2 standard. When comparing LCML to the EAGLE data matrix, LCML still possesses more expressive power since it can include additional information, like tree cover (a valuable concept for annotating canopy effects and for other uses) or custom data [19].

Handling a rich and detailed representation of land cover can be exploited in other contexts, such as climate mitigation through carbon capture [20]. For instance, trees and plants absorb carbon dioxide and release oxygen, enabling us to better estimate the carbon capture potential of forest areas. Soil can also act as a carbon sink when plants die and decompose. LCML, through its expressive power, can support these vital research fields.

There are, therefore, several reasons for stating that LCML can improve classification accuracy not by employing better classification algorithms but by retaining as much information as possible while defining and storing more complete land cover class descriptions. As highlighted in [21], the objects-based approach employed in LCML is also crucial for creating semiautomatic similarity assessment tools that can be used to facilitate class comparison and change detection, further enhancing interoperability.

5. Conclusions and Future Work

Like with almost any software, there is always room for further improvements, and this should be considered version “1.0”. In this regard, a few of the five high-level objectives used in the design of the software can be used to envision what the future work might look like.

Indeed, one of the leading non-functional requirements was to design and develop the software as open-source, maximizing the chances that the software will be made better, evolve, and be supported in the future. For this reason, the project is hosted on a BitBucket server [22]. Enhancements can essentially happen in two ways: ironing out potential bugs still present, and expanding existing functionalities, perhaps in new directions, with some of them already considered.

LCHS software can be considered a “reboot” of LCCS3 and, as such, and especially considering that land cover legends and classes hosted in the LCLR were created with LCCS3, compatibility with the previous system is going to play an important role, at least in the short to medium period. Although the LCHS is based on a formal specification, since the standard clearly establishes all the building blocks, LCCS3 is not, and hence, its import compatibility can be assessed and enhanced only with time-consuming trial-and-error routines, such as importing LCCS3/LCLR legends and classes, ensuring that the essential elements, properties, and characteristics are imported and appropriately converted, and taking notes of possible issues so that conversion rules can be implemented accordingly.

Further synergies with the LCLR can also be studied. For example, LCHS users can import LCLR legends and classes, but allowing LCHS legends to be included in the LCLR will require the definition of a protocol for approving them and then including them in the LCLR.

There is also room for integrating LCMLUtils, a similarity assessment methodology for comparing legends and classes [23]. The methods and the accompanying system were developed before joining the ISO committee for the under-development updates to 19144-2 and, naturally, before developing the LCHS. Hence, that work used classes imported from LCCS3. Future work could consider updating LCMLUtils so that it is aligned with the latest version of the standard and to better integrate it with the LCHS. The LCHS could then evolve toward being an editor and comparison tool. Last but not least, further integrations with the FAO Hand-in-Hand Geospatial Platform can also be investigated.

The name of the software itself provides further hints for the system’s evolution. Indeed, one of the high-level objectives was to accommodate future expandability to LC/LU needs. Considering that work on the ISO 19144-3 standard is being restarted as a technical specification, with meetings started in early 2023, and that the process needs at least 18 months, it was impossible to advance this requirement further. However, a few speculations can be made. In particular, preliminary documents and proposals that were made available to the ISO 19144-3 committee for restarting the project point out the possibility of developing a model for the land in different ways, like: (1) pure LC land description; (2) LC land description with extra LU attributes; (3) pure LU land description; (4) LU land description with extra LC attributes; (5) functional LULC land description. These options emphasize different kinds of descriptions but allow for nesting different parts as a way to document them better. Understanding which parts act as entry points, just like a “land cover class descriptor” acts as an entry point for land cover, and then understanding the “boundaries” among these various parts will likely be a central activity in expanding the LCHS for better addressing LC/LU needs.

To this end, a new version of the LCHS is being developed. In particular, this version considers the functions and enhancements highlighted here. It addresses the ease of legend generation, interoperability of different classification systems, integration of the Land Cover Registry, and better integration with the similarity assessment methodology presented in [24].