Citizen science [1
], community-based monitoring [2
], and volunteered geographic information (VGI) [3
] are all terms for the increasing involvement of citizens (and expert communities) in data collection and other tasks relevant to scientific research. Driven by developments in Web 2.0 and the integration of GPS (Global Positioning Systems) into smartphones, citizens can now act as sensors and generate their own geographic data, becoming ‘producers’ of information as proposed in Reference [4
]. One of the most successful examples that illustrates this new phenomenon is OpenStreetMap (OSM), in which millions of citizens are mapping features and contributing to a free and open map of the world [5
Environmental monitoring is another application in which many citizen platforms have emerged over the last 10 years [6
]. We refer to these platforms as citizen observatories when public bodies act as key stakeholders, which then use the citizen and community-based information for decision-making, and which integrate new technologies and Earth Observation [7
]. The European Commission has recently funded a number of citizen observatory projects including LandSense, which is focused on the monitoring of land use (LU), land cover (LC), and change over time by citizens and other stakeholder groups such as local governments. Using different online and mobile technologies, LandSense is running a number of case studies across Europe and internationally to demonstrate the feasibility of different monitoring approaches to LULC, which are available from the LandSense Engagement Platform (LEP) [8
]. One innovative component of the LEP is the federated authentication system, which allows users to log into any application hosted by the system using a single account; this is intended to simplify access to the diverse set of resources being developed within LandSense. Another component is the development of different services, particularly the change detection and data quality assurance services. The change detection service applies algorithms to satellite imagery in order to automatically detect potential changes in LULC, which can then be verified by citizens. The quality assurance service is tailored towards processing data from citizens and hence uses various techniques for quality checking that can add confidence to the data collected.
As mentioned above, one of the key stakeholders in the LandSense citizen observatory is local government. With the adoption of open data policies, local governments have proposed different initiatives to share data and engage in a dialogue with citizens [9
], collect data for urban planning [10
], or even define new regulations, e.g., in advertisements [11
]. Recent research has also shown that national mapping agencies (NMAs) are starting to engage with citizens and communities by proposing their own platforms to obtain feedback on existing data or to collect new data [12
]. For example, the National Land Survey of Finland has explored the possibility of improving the quality of their authoritative topographic database by proposing a collective map layer for citizen contributions, as outlined in Laakso et al. [13
]. By engaging with schools, Bol et al. [14
] showed how the data collection process can be included in the primary school curriculum, as demonstrated in an innovation pilot proposed by Kadaster, the Dutch NMA. The French NMA, which is also a partner in the LandSense project, has proposed a community- and citizen-based tool for collecting feedback from citizens and public bodies such as firemen and local municipalities in order to reduce the time needed between two releases of the data [15
]. However, platforms proposed by NMAs to date have mainly been used for collecting data, with no examples of collaborative mapping. Moreover, they are mainly targeted at public partners, with very few oriented towards citizens, and none of them, to the best of our knowledge, have involved different types of communities. This paper is an attempt to propose a system that will fill this gap.
In this paper we focus on the mapping of LULC data and the monitoring of change, both of which are crucial for decision-making. However, LULC data are complex, especially for non-experts. First, there is confusion between land cover and land use [16
]. Secondly, there are different nomenclatures for LULC proposed at the country and European levels, e.g., Corine Land Cover (CLC) [17
], the Urban Atlas [18
], INSPIRE (Infrastructure for Spatial Information in the European Community) [19
], and CNIG (National Concil of Geographic Information) [20
]. Although some recent research has focused on establishing links between different nomenclatures [5
], choosing the most appropriate LU or LC class is still a complex and often subjective task, which also depends on the level of detail needed by the users of the LULC data.
The majority of citizen science platforms that deal with LULC data are focused on validation tasks or the collection of training data for producing LULC maps (e.g., LACO-Wiki [23
], Geo-Wiki [24
]), with the exception of OSM. Indeed, for Europe, CLC data have been imported into OSM and then updated and improved over time by volunteers, although sometimes there is a mixture between LU and LC. Although it is possible to use OSM to study past land changes [25
], it is difficult to distinguish changes due to the correction of errors in the data from real changes that have happened on the ground. To indicate this distinction, the OSM data model could be extended with a new tag or relation. However, this solution would require good practice from the volunteers, i.e., to always fill in this value and make this distinction. Another issue is a problem related specifically to LULC data, which is generally digitized as polygons that cover several features so they may overlap with other features or there may be gaps in the polygons. These types of errors could be fixed by volunteers if an LULC protocol was established in OSM or if an automated correction process could be implemented to solve some of these issues. However, there are still potential problems in the quality of the final LULC map derived from OSM and the inability to detect real change.
The aim of this paper is to propose new concepts that facilitate the collaborative mapping of LULC and to show how these concepts can be implemented in a collaborative platform to engage both citizens and other types of communities, including local government partners. Through this platform, our goal is to study the feasibility of citizen and community science improving authoritative LULC data while simultaneously helping LULC end users to create map products that better fit their needs.
2. French National Needs for Mapping LULC Data
Reducing the increase in soil sealing, i.e., impervious surfaces due to urbanization, is an essential measure for protecting ecosystems, maintaining biodiversity, and mitigating climate change [26
]. France has ambitious climate targets and these cannot be achieved without better management of the country’s soils, particularly those found on agricultural lands. To respond to these targets, local authorities and decision-makers need up-to-date and accurate LULC data.
The French NMA has recently started to produce a new LULC database at the regional scale. The nomenclature of LU and LC classes is INSPIRE-compliant and the specifications of the production were defined to take into account the needs of the end user, as expressed by different stakeholders in a consultation process. An interesting aspect of the LULC product is that it is ‘on-demand’. The LULC database relies on a skeleton layer, which has been defined by the main road and rail networks in order to provide the basic structure of the landscape and to ensure the stability of the data. The LULC data are stored in a vector polygon database, where each polygon is classified with both an LU and LC class. The LULC data are produced by using different French NMA products (e.g., topographic layers, the address layer, the forest layer, etc.) and by photo-interpretation. The LULC data are updated on a three-year cycle, which corresponds to the production cycle of orthophotos. LULC data were first produced for the Midi-Pyrénées, a sub-area of the Occitanie region in France. For this region, a nomenclature was developed containing 17 LU classes and 14 LC classes. However, not every combination of LU and LC classes, i.e., 17 × 14, is possible. The current version was released in 2016 and represents the LULC in 2013. A cyclical update to the LULC database is one of the most important requirements of the end users as this allows for snapshots in time to be specified, which is necessary for defining annual indicators.
A number of different issues can be highlighted regarding the LULC nomenclature and the production process. First, as a result of being produced mainly by photo-interpretation, some LU classes are lacking in information. For example, the LU classes Secondary Production (LU2), Tertiary Production (LU3), and Residential (LU5) are grouped into one LU class (LU235) due to the lack of information concerning the main function of the buildings, e.g., is a building used for agricultural purposes or as a residential dwelling? The LU class associated with quarries is difficult to assess without information about the current state of the quarry, i.e., is it active, closed, or abandoned? The lack of this type of information makes the classes Forestry (US1.2), Abandoned Areas (US6.2), and Areas without Use (US6.3) less meaningful. It is also difficult to distinguish between different types of LU (e.g., residential, agricultural, touristic, etc.) in a large farming area using only photo-interpretation since this depends on information concerning the functionality of the buildings. Finally, identifying and monitoring change in order to produce a new snapshot in time is a very time-consuming and expensive task. Hence, improving the production process is a necessity for both IGN and the end users of the LULC data, and two main needs have been identified: (i) to improve the current LULC data, in order to (ii) produce a new snapshot in time.
In this context and based on the LEP, our goal is to propose a framework where participants can make contributions in order to improve and update the LULC database. To achieve this goal, this research aims to adapt and implement the data collection protocol proposed by Mooney et al. [27
] by following the guidelines addressed in Olteanu-Raimond et al. [28
LULC data are a difficult theme to map because of the complex and detailed nomenclature used to describe LULC. Thus, one of the key questions we asked was: how can this task be made easier for contributors? We came up with a series of ideas for implementation as follows:
Involve different communities and define different roles. It is essential to engage with these different communities and identify their needs and motivations as they may differ between communities. For example, a citizen may be more willing to provide local information based on their own knowledge while local authorities may differ in their interests, e.g., one might be concerned with agricultural areas while another may be more interested in monitoring the urban infrastructure.
Define distinct types of contributions so that contributors can choose between them as a function of their needs and motivations.
Define precise and clear tasks for contributors.
Develop tools tailored to validation and mapping tasks.
Run different campaigns over time and develop tools for managing the campaign (e.g., give feedback to contributors, help contributors to understand the LULC nomenclature) in order to sustain motivation over the long term.
Make use of services developed in the LandSense project to obtain in situ feedback from contributors, particularly the change detection and quality assurance services.
To demonstrate and validate the concepts outlined here, two campaigns were planned in the Midi-Pyrénées, a sub-area of the Occitanie Region in the south of France. These campaigns are part of seven pilots (or case studies) planned in the LandSense project, which are spread across three themes (urban landscape dynamics, agricultural land use, and forest and habitat monitoring).
3. Strategy and Underlying Concepts of the Campaigns
The goal of this section is to present the strategy for the campaigns and the concepts proposed to in order to achieve these goals.
3.1. Scheduling of the Pilot Campaigns
Two main campaigns have been planned: the first campaign will run in 2018 followed by a second campaign in 2019. As mentioned earlier, the LULC database is a dated product released for a specific year. The production of the LULC product is subject to two main requirements. First, there must be temporal consistency between the ground truth and the year of production, i.e., these must be in the same year. Secondly, if a feature is modified in the dataset, it is essential to know whether the modification is due to a change in the real world or whether it is an error in the database that has been corrected. In order to fulfill these requirements, the strategy for the campaign is illustrated in Figure 1
LULC 2013 represents the first version of the product. During the first campaign, two new products will be produced: a revised LULC 2013, where the errors are corrected, and a new LULC dataset dated 2016, where changes in the real world are captured. For temporal consistency, an orthophoto from 2013 is used for LULC 2013 whereas for LULC 2016, the orthophoto is from 2016. Between the two campaigns, a fusion process will take place in which a data quality assessment will be made, resulting in a new product referred to as LULC 2016 Fusion. This dataset will be used as the starting dataset for the second campaign. The process will be the same as that used for the first campaign: the two products obtained will be LULC 2016 revised and LULC 2019. Overall, the workflow shown in Figure 1
will result in three products by 2019: LULC 2013 revised, LULC 2016 revised, and LULC 2019.
The exception to this process described above is for information on buildings. Since this information is continuously updated, there is no need to produce a building product for a specific year as with the LULC products. Hence, the workflow for updating building information is continuous over time.
3.2. Definition of the Concepts and the Types of Contributions
To achieve the goal of improving LULC and building information, four main concepts are proposed: (i) the location to visit; (ii) feedback from the contributor; (iii) reporting on the current state of the LULC map; and (iv) feature mapping or modification. The location to visit is a point with a pre-determined location, which is based on similar ideas found in FotoQuest [29
], a mobile application that encourages citizens to collect LULC data at specific locations including LUCAS (Land Use Cover Area frame Sample) points [30
]. Here the locations to visit involve tasks such as adding new thematic information (e.g., the building function and the number of floors), validating new thematic information (e.g., changes detected by satellite processing), and improving LULC classification for classes where in situ information is needed (e.g., areas under construction, abandoned or inactive quarries, etc.). Each location to visit is characterized by a coordinate and the type of task to be achieved.
The second concept is feedback, which represents the data collected by the contributors when they visit a location, while the third involves contributors reporting on the current state of the LULC map compared with the real world (e.g., a building does not exist anymore, a new construction, etc.). To facilitate this process, a taxonomy of reports (i.e., delete a feature, add a feature, modify the geometry of the feature, etc.) has been defined. Finally, mapping or modifying features consists of adding new features to the database or modifying existing features, which can be both the attributes and/or the geometry. To do this, supplementary information can be used such as the local knowledge of the contributor, reports made by other contributors indicating areas of change, or errors in the database, aerial photographs, etc.
Contributions from the collaborative process aim to improve and update the existing LULC database. There are four types of contributions that correspond to the tasks that contributors can make:
Edit a feature: This deals with changing one aspect of an existing feature. Modifications can be made to the geometry (e.g., mapping a new feature or splitting an existing one, deleting a feature by dropping it or by fusion with another feature) or changes to the attribute values that are already present in the initial database.
Add new information about the feature: Here the focus is on attribute information. This task consists of adding one or several attribute values that have not been filled in yet in the initial database.
Make a report: This refers to adding markers on the map that highlight a change or an error and choosing an element of the taxonomy that describes the report. This report is linked to a feature.
Take pictures: A contributor on the field can take a picture of the features depicted on the map.
All types of contribution/task require the addition or modification of attribute information from a list of eligible values. This prevents errors when entering values and limits the list of potential values. Still, the contributions will be checked by experts.
3.3. Types of Campaign
Contributions can be made in two different types of campaign: opportunistic and guided. The reason for having two campaign types is to cover different contributor motivations and address how the contributions will be made, i.e., in situ or online. Contributors must have access to mobile devices to make in situ contributions or a computer to make contributions from their workplace, as the online system is mostly targeted at local government partners. Opportunistic campaigns can run at any time and can be placed in the chosen test area, covering all features in the dataset. Hence, there is no guidance towards specific features as all types of task are available to the contributors. Contributors map and validate features in the defined test areas where differences or errors exist between the real world and the database. For example, a feature can be an LULC polygon corresponding to a combination of an LU value and an LC value in the nomenclature provided or a building polygon in the production database.
In contrast, a guided campaign consists of specific tasks chosen by the campaign organizer. In this case, contributors are encouraged to visit locations that correspond to a particular aspect of the landscape. Guided campaigns also run for restricted periods of time and focus on five different types of task, which correspond to specific features that are selected as locations to visit:
The addition of new building information: Primary use, secondary use, number of floors. Note that primary and secondary uses are drawn from the same list of values.
LULC validation or quality validation: This task is linked to the change detection and quality assurance services provided by the LandSense project. LULC polygons are detected as having changed in the previous year and this change has to be validated as a change (and hence values must be changed in the database) or determined as having not changed (and hence no changes are made to the initial database).
Status of quarries: This task focuses on the quarry LU polygons that are in the initial database, where contributors are asked to indicate the status of the quarry as active, closed, or abandoned.
Updating construction LU classes: This is a transitory class. If the construction is completed, the LU and LC will need to be updated relative to the initial dataset, in which case contributors are asked to update both the LU and LC classes.
Improvement of information on LU in agricultural classes: This task deals with points located in agricultural land use polygons, where the goal is to determine if the point belongs to an agriculture land use type (e.g., area under cultivation) or not (e.g., residential area).
Reports of any type of change can be made in either the opportunistic or guided campaigns as this reporting option exists in both the mobile and online applications. Finally, we can also run what we refer to as ‘flash’ campaigns, which are campaigns limited in space and time in order to gather information quickly over a short period of time. These campaigns can focus on a specific theme (i.e., be guided) or not (i.e., be run as an opportunistic flash campaign).
3.4. User Profiles and Their Roles
There are different user profiles within the collaborative process. Profiles are defined for different purposes, e.g., the administration of the process, launching guided campaigns, and for managing contributions. Three user profiles are defined: Administrator, Expert, and Contributor. Each profile has specific roles in the collaborative process. The Administrator has the role to define, launch, and close opportunistic campaigns by managing data on the platform (see Figure 2
An Expert (see Figure 3
) defines and launches a guided campaign by identifying an area, the locations to visit, or by running the change detection service or the quality assurance service. The expert profile is validated by an administrator and is generally restricted to staff from IGN and local authorities.
Most profiles will correspond to Contributors. Their role is to contribute to the campaign by using the proposed tools and accomplishing the tasks described in Section 3.2
. The roles of the Contributor are outlined in Figure 4
4. PAYSAGES Platform
This section describes the implementation of the concepts defined in Section 3
as a collaborative platform named PAYSAGES (which means Landscapes in English).
The architecture of the PAYSAGES platform is based on a federated authentication as proposed by the LandSense project [8
], and contains three tools and three services as depicted in Figure 5
A user account is required to access the platform and make contributions, as suggested by Olteanu-Raimond et al. [28
]. Users are asked for two types of information to create an account: mandatory (i.e., user ID, password, and e-mail) and optional (i.e., profession, age, gender, institution). The goal of collecting the optional information is to gain insights into who the contributors are; this will allow us to adapt the tools in a way that is tailored to the different profiles of the contributors. Note that the collection of this personal information is compliant with the new European General Data Protection Regulation (GDPR) that came into force at the end of May 2018. At this stage, the link between the federated authentication system and the PAYSAGES platform is still under development, so the first campaign will run using the PAYSAGES authentication system.
Three tools are available in PAYSAGES that allow contributors to monitor LULC and contribute building data. The first tool is the PAYSAGES website (see https://paysages.ign.fr/
). It is an online system and provides a user-friendly interface for editing, visualizing, and downloading LULC and building features. This tool is used during opportunistic campaigns, which can run at any time and in any place located in the study area, as outlined previously (Section 3.3
). This system is based on the mon-guichet©
) tool and was built using three web services hosted on the IGN France server:
The French Geoportal flow and its Application Programming Interface (API) (the French National Geoportal produced by IGN France), which allows for the visualization of some data produced by IGN through a Web Map Service (WMS) such as orthophotos (for 2013 and 2016 in the PAYSAGES context). The orthophotos are displayed to help in mapping features. For more information, readers can access the following link: https://www.geoportail.gouv.fr/
The database, which refers to the initial database that is modified during the campaign by the contributors. The data available for the French pilot are vector objects with respect to the test area. Two types of data are available: buildings and LULC. The API allows for accessibility to and modification of the data by using the Web Feature Service Transactional (WFS-T) protocol, and the API can be reached by other Geographic Information Systems (GIS) clients.
The third server manages the contributions from the users as well as the photographs taken by contributors in the field. This is described in more detail in Section 4.2
The second tool developed is the PAYSAGES mobile application. This tool is used during guided campaigns in order to collect in situ information about specific features. The third component, the PAYSAGES wiki, is the social aspect associated with these campaigns and is based on a semantic wiki tool. The goal is to provide information about the campaign, to help contributors in mapping LULC and building data with respect to the nomenclature provided, to allow users to engage with the campaign, to report any difficulties encountered in the mapping, and finally, to visualize in situ photographs taken by the mobile app. These three tools are described in more detail in the following sub-sections.
4.2. PAYSAGES Web Application
The web application is an adaptation of the espace-collaboratif©
) system proposed by IGN to engage with different local governments for data production.
illustrates the functionalities of the PAYSAGES web application.
In espace-collaboratif, a contributor can only edit some attributes in the database (i.e., not the geometry directly) and create new reports (i.e., photographs, documents, or schema may be attached). The contributions are managed by the data administrator, which is a staff member from IGN. The procedure to check the integration is launched before data publishing.
In contrast, in the new PAYSAGES web application (see a screenshot in Figure 7
), contributors can directly modify the data (i.e., both the attributes and the geometry), and the updated data are directly available on the web through a Web Feature Service (WFS). To guide users in making difficult or controversial decisions, the administrator creates a series of points to visit. For example, in situ contributions are sent from the mobile application by users taking part in the campaign and sometimes these contributions can be in conflict. In this situation, the contributor to the online application must decide and resolve the conflict by inserting the correct attributes associated with a given feature.
Three main categories of functionality are available in the PAYSAGES website:
Edit feature geometry: This category contains tools for adding a new feature, deleting an existing feature, modifying the limits of the feature, and shifting the feature.
Edit thematic information: This category has tools for modifying attribute values. The modification of attributes is either an open field or users can select an attribute value from a pre-selected list. For LULC data, the attributes are LC and LU classes based on the nomenclature proposed by IGN, whereas for buildings, the attributes are the number of floors and the primary and secondary uses of the building.
Manage the history of data and edits that are conflicting.
The API REST (Representational state transfer) manages the contributions from the mobile and web applications. The main API requests allow user contributions (feedback), reports, and photographs to be read, to create new feedback, to add a new report for feedback with one to four photographs, and to obtain follow-up indicators. A functionality implemented in the mon-guichet tool provides a template system to exchange the data. The same functionality is developed for the report. The data sent are automatically checked against a predefined list of values and whether these are mandatory, such as a new LU or LC type.
illustrates the interaction between the mobile application and the API for a specific task which, in the example provided, is change detection validation. The mobile app is described in the next section.
4.3. PAYSAGES Mobile Application
The design of the PAYSAGES mobile application was originally based on FotoQuest [29
], which is an app for in situ data collection that consists of a simple map interface showing users the location of all available ‘quests’. Quests consist of pre-determined locations that users must navigate to, and once the point is reached, the user must take five photographs, one of the point location and four in the four cardinal directions away from the point. The user must then choose the LC and LU from a drop-down list, which corresponds to the LUCAS LULC nomenclature [31
]. FotoQuest was modified to become PAYSAGES so that instead of ‘quests’, users complete a series of different tasks as outlined in Section 3.3
shows some screenshots from the tutorial when the app starts. Figure 9
a shows the starting screen of the app, while Figure 9
b,c illustrate the map interface that shows the locations of the tasks, in this case tasks related to collecting information on buildings. Red markers show points that have not yet been visited, blue markers show points visited by others, and green markers are points that the user has already visited. The user then selects a location to visit, which turns yellow as shown in Figure 9
c. The user is then told to move as close to the point as possible, as shown in the tutorial (Figure 9
c) and in the actual app (Figure 10
Once the point has been reached, the user indicates that they are at the point by pressing the button (Figure 10
a) and the ‘Add building information’ screen will appear (Figure 10
b). The user selects the principal and secondary uses of the building, selects the number of floors, and optionally takes a picture of the building. This information is then saved to the phone and uploaded later when they have a wifi or data connection. Figure 10
c shows the screen associated with a different task. The user has chosen a location where change may have occurred and is asked to verify if the LU is ‘Agriculture’. If not, they are asked to choose the new LU followed by the new LC and to take up to four photographs (the latter two parts of the task are not shown in the figure).
The app runs on both Android and iOS operating systems and is available for download from the Google PlayStore and the Apple AppStore, respectively. The app is available in both French and English; the language that appears is based on the phone settings, although translations were done manually to ensure the correct meanings of the terms used, particularly those related to LULC, which are often poorly translated when using automatic translation facilities. Although the app can work anywhere, the tasks shown on the phone are part of guided campaigns that are related to the area of interest. Therefore, tasks will only be shown if a user is in the city of Toulouse or the surrounding rural areas of the Midi-Pyrénées region.
4.4. PAYSAGES Wiki
The wiki (https://paysages.ign.fr/fr.wiki
) (implemented using the Mediawiki software, Version 1.30.0, https://www.mediawiki.org
) is the social component of the PAYSAGES platform. Most people are familiar with Wikipedia; an advantage of this tool is that it provides a way for everyone to collaborate easily by writing unstructured information. To initiate the PAYSAGES wiki site, a presentation about the project, user guides, an Frequently Asked Questions FAQ, and important dates for the campaigns have already been published.
One of the major challenges with LULC information is to understand the metadata. To this end, the wiki represents a good way to help contributors in understanding this information. First, as a result of infobox
, important information about a particular LU or LC type is directly accessible from the wiki (Figure 11
a). Anyone can add an image or advice, or initiate a discussion in a specific metadata page. Almost all elements of a metadata page are saved as semantic properties. Then, via the Semantic Mediawiki extension, the metadata page can be exported or published, allowing other systems, such as the mobile application, to access these pages. This last functionality is still under development.
With Semantic Mediawiki, other extensions can be used to query external data, make searching and navigation easy, or display the results in tables or graphics. For example, a graphic could be published that summarizes the progress of visits or shows the points to visit on an interactive map, or the top 10 contributors could be displayed in a table (Figure 11
As part of the PAYSAGES architecture, a database with field photographs and metadata will be created; however, this is still under development. The wiki will be able to use this information and display it by querying and filtering with semantic metadata.
5. Pilot Demonstration
5.1. Study Site and Schedule
The campaign is divided into two parts to take place over two years, where the deployment corresponds to the strategy and workflow outlined in Figure 1
. The dates of the campaign were fixed to coincide with a period of the year in which citizens and local government employees are more likely to contribute over a sufficient length of time in order to collect a sizable number of contributions. The first part of the campaign is taking place from June to October 2018, while the second part will occur during the spring/summer of 2019.
The site for the campaign is located in the current Occitanie region in the old part of the Midi-Pyrénées, where the LULC 2013 product was completed. The site covers urban and peri-urban areas, including the city of Toulouse, which is actively expanding, as well as the surrounding rural areas. Various landscapes show different degrees of urbanization and contain features that correspond to the different tasks outlined in Section 3.3
. The extent of the area is approximately 10,000 km² (Figure 12
The in situ locations to visit with the mobile application are distributed across the site. The coordinates of these locations correspond to the center of the targeted features for which contributions are requested (e.g., the center of a building). The spatial distribution of the points is constrained by the location of the targeted features and the desire to spread the points across the entire site equally. As a result, there are 8191 points divided into the five tasks for the guided part of the campaign, while the opportunistic campaign covers the whole area of interest.
5.2. Launching the Campaigns
The first campaigns running in 2018 have several parts, which we refer to here as ‘thematic’ campaigns. There are three opportunistic campaigns and five guided ones. The thematic campaigns were launched and communicated to potential contributors through different social media channels and face-to-face meetings with different stakeholders. The opportunistic campaigns are focused on the 2013 and 2016 LULC data as well as the ongoing update to the building database. The goals of these campaigns are:
To update the building data;
To update the LULC data (LULC 2016) and correct any errors in the LULC data for 2013; and
To distinguish between residential, industrial, and service uses, which are three LU classes that are currently merged into a single class due to lack of information.
The guided campaigns are focused on the 2016 LULC data and are divided into:
Collecting new information on some pre-selected buildings;
Identifying the current state of quarries;
Distinguishing between residential, touristic, and agricultural LU;
Updating the LU and LC classes at locations that are ‘under construction’ in the initial database;
Validating points automatically detected by the change detection service; and
Making reports at any location concerning building and LULC data collected in the field.
This paper has outlined a strategy and workflow for updating and correcting LULC information on a three-year cycle and building data on a continuous update cycle for the national mapping agency, IGN France. The technology, which was developed as part of the LandSense project, is comprised of web, mobile, and wiki applications, targeted at different types of users to be employed in different types of campaigns. The web application will mostly be used by experts who work for IGN or local government partners who are also users of the data. The mobile application is intended to reach a wider audience including citizens and students, so the tasks are well-defined and the locations of where information is needed are pre-determined. Finally, the wiki application is intended for use by both citizens and experts. A series of opportunistic and guided campaigns are planned for the summers of 2018 and 2019 that will reach out to all types of users in the pilot area of the Midi-Pyrénées.
The success of the campaigns depends on how the contributors are recruited and engaged. One of the most challenging tasks is to build and maintain a community around a collaborative initiative. We plan to integrate different contributors into the different campaigns since they have varying knowledge about geographical information and mapping. A communication campaign through well-known channels (e.g., Facebook, LinkedIn, Twitter, etc.) to involve citizens during the guided campaigns began at the end of June. Some mapping parties involving staff, citizens, and students are scheduled for September and October 2018.
As this stage of the campaign, 50 contributors have registered and almost 200 contributions have been made. As general feedback received to date, the contributors have noted that the application is user-friendly and very easy to use.
From a technical perspective, for the second campaign that will take place in 2019, we intend to implement the link between the PAYSAGES system and the LandSense platform, as well as to develop the functionality that allows the mobile application to access metadata from the wiki application and to take into account user feedback.
From a data quality perspective, the collected data will be analyzed in order to assess their qualities such as positional accuracy, thematic accuracy, topological consistency, etc., which will eventually use the LandSense quality assurance service when it becomes available.
Moreover, both the Sentinel-based change detection service and collaborative mapping can generate errors. These errors can accumulate from the initial data collection and propagate to the final product. Thus, it is essential to identify these errors, to model them and their propagation, and to quantify them. The errors can be positional as well as thematic (e.g., misclassification of LULC classes). Different strategies can be applied. On the one hand, quality indicators such as topological and thematic consistency computed on the same dataset (before and after changes) can be used to highlight positional and thematic errors. For example, overlapping between polygons, sliver polygons, or polygons with holes can be detected. Thematic inconsistency between LULC classes (e.g., a feature having the land cover class shrubs, and the land use class equal to residential) can be detected. On the other hand, different snapshots of LULC data (e.g., before and after changes) can be compared in order to compute both positional and thematic differences between the two snapshots. These differences can be then quantified through different indicators.
To manage the quality of the data, the errors can be classified into different patterns and then modeled in order to analyze the error propagation and the impact they would have on the final product by applying a sensitivity analysis. Finally, from a collaborative point of view, a semi-automatic tool can be developed in order to display and help users (i.e., experts) to fix such errors.
Finally, as depicted in Figure 1
, the final product is a fusion of initial data and data coming from different campaigns. One important task in the fusion process is to distinguish between valuable and meaningful changes. Indeed, some changes are valuable at the features scale but they are not meaningful from an LULC class point of view. For example, a contribution reporting two new buildings in an urban area is valuable, but it is not meaningful for LULC because the new features do not change the class in the LULC dataset. Thus, our goal is to develop new methods to determine if the change is meaningful for the authoritative databases under consideration (e.g., the change has already been inserted in the database, the change does not concern features in the authoritative data due to the data specifications, etc.). These types of situations will be identified and allow us to make decisions regarding whether an update needs to be done in the authoritative database.