1 Introduction

The rise and success of different volunteered geographic information (VGI) activities (Goodchild 2007), together with increasing technological advances, have prompted national mapping agencies (NMAs) to consider the possibilities of using crowdsourced geographic information in topographic data collection. The power of citizens is at its best when it comes to topographic data features that are difficult to map with remote sensing techniques (such as forest paths hidden by trees) or that require local knowledge (such as place names or any other features of interest to people). In some cases, the use of VGI is the best option for mapping temporal changes. However, NMAs have been reluctant to get involved with VGI due to numerous challenges such as data quality, contributor motivation and legal issues (Olteanu-Raimond et al. 2017a). Also more inconspicuous challenges like participation inequality (Haklay 2016) (where most of the contributions are done by a small group of volunteers) and semantic challenges (Ballatore 2016) (such as simple definition conflicts) can have far-reaching consequences. Most likely because of these and many more issues, there have only been a few examples of long-term VGI initiatives. In Europe, many NMAs have some kind of feedback system to collect hints on map updates from citizens. For example, Swisstopo in Switzerland (Federal Office of Topography swisstopo 2018) and Kadaster in the Netherlands (Verbeter de kaart 2018) have active citizen feedback services. In those services, citizen contributions and their status in the update process are visible to all users. The US Geological Survey (USGS) has a long tradition of crowdsourcing its data collection. It has created a dedicated engagement programme to promote and sustain the mapping community called the National Map Corps (McCartney et al. 2015). The collected VGI helps the USGS update its structure points in support of the national map and US topographical maps. However, the features that the USGS collects are limited to a few predefined point-type data features, such as schools (Jackson et al. 2013), hospitals and other public buildings. In all of these existing crowdsourcing services, the collected data are mostly point-type hints about map errors, and they do not seek to offer full map editing tools for complete feature contributions.

The most well-known VGI realisation is probably OpenStreetMap (OSM—Arsanjani et al. 2015). In many areas, the OSM data coverage for certain data classes even exceeds the one provided by the authoritative topographic database (Haklay 2010). Even though OSM data are open and free to use, licensing conflicts prevent merging OSM data with authoritative NMA data. OSM data are licensed under the Open Database License ‘ODbL’ 1.0. All data merged with OSM data are to be distributed using the same ODbL licence and therefore requires the attribution of OSM contributors. An NMA could, for example, offer its topographic data as open data under the CCBY licenses, and if so, then they could not be merged with data under the ODbL licence. For map users, the licensing does not usually present a problem as long as the data are open, but for an NMA, it is important to preserve the copyright of the data. Regarding the completeness of the data, NMAs collect data according to certain quality principles throughout the country, whereas OSM data are often less complete or even missing in certain areas, because of the geographical distribution of contributors and because they fall into different contributor types (Steinmann et al. 2013), who generate data of varying quality.

In light of the recent developments in the use of VGI by NMAs, the National Land Survey of Finland (NLS) has been developing a concept for the use of VGI in the data acquired for the national topographic database (NTDB). The aim of the work is to study whether it is possible to raise the quality (i.e. the completeness: missing features, and the accuracy: feature location errors) of the NTDB via crowdsourced information. By offering more advanced map editing tools such as importing GPX tracks and by adding social features such as citizens being able to comment on each others contributions, we wanted to have more complete, accessible and useful data. We also incentivized citizens to create new map features that are currently not in the feature catalogue to reveal the novel data needs of citizens. With this new concept, NLS seeks more refined ways of employing VGI to achieve better-quality map data with fewer resources while developing the relationship between the NMA and citizens.

In this paper, we first explain the main principles behind the social map service that we developed in Sect. 2. Then we present the high-level technical and social features of the map service. Outcomes from the pilot, including results from questionnaires and user feedback are presented in Sect. 3. In Sect. 4, we discuss the future implications of VGI in NMA procedures and draw some conclusions.

2 Map Gretel—a social map service

Currently, through the existing simple form-based feedback system, the NLS receives approximately five hundred reports annually from private citizens about errors and changes in map data. A report consists of a point on a map, a description and an email address. These reports are processed by NLS employees who are public officers (referred to hereafter as ‘operators’). Operators evaluate the reports, and when needed, there is a dialogue between the concerned citizen and an operator via email. Operators update the NTDB based on the processed reports and eventual dialogue with citizens.

As the basis for conducting this study, we developed a social map service called ‘Karttakerttu’, which can be freely translated into English as ‘Map Gretel’. Map Gretel is a web browser-based social map service for citizens that enables data import and data edits. Map Gretel uses the topographic map of Finland created from the NTDB, and it serves as the reference map for users. NTDB is a vector data set depicting the terrain of all of Finland at the scale of 1:10,000 and is updated continuously. The topographic map created on the basis of the NTDB uses a pixel size of 1 m at a scale of 1:10,000 and has nine scale levels. This background map represents the latest visualisation of NTDB data, which is updated weekly into Map Gretel. The registered users of Map Gretel (referred to as ‘mappers’) have access to a layer where they can add and edit features. This layer is referred to as the ‘citizen layer’ in this study and holds all the contributed features. According to the Map Gretel terms of service, to which all mappers have agreed to when registering, all rights of contributed features are given to the NLS.

2.1 The operational workflow of Map Gretel

The operational workflow of Map Gretel consists of two phases: contributing and processing. There are two types of actors in Map Gretel: a mapper and an operator. A mapper contributes by either creating or editing features and the operator processes the features (Fig. 1). The feature contributed by a mapper can be edited by other mappers. Content generated by the mappers is stored to the citizen layer and is processed by operators. If accepted by the operator, the feature is transferred to the NTDB, thereby completing one cycle of the mapping process. A mapper may, for example, add a point marker to the citizen layer showing an error on the map, create a new walking path that does not exist on the map or further edit another mapper’s contributed feature by refining it. After a mapper has contributed a new feature to the citizen layer, the feature is automatically tagged as ‘unprocessed’ by the system and made visible and editable to other mappers and processable by the operators. The creator can both edit and delete the feature while other mappers can just edit the feature. The operators, who are assigned to work on a specific part of the country, start evaluating the contributed features by tagging the feature ‘being processed’. While the feature is ‘being processed’, it cannot be edited by mappers. If the feature is rejected by the operator after it has been processed by the operator, the feature stays on the citizen layer. If the feature is suitable, it is tagged ‘transferred’ when the operator transfers it to the NTDB. Once the feature is processed, it can again be edited by mappers. In principle, a suitable feature is removed from the citizen layer only if it does not offer any additional information to that already found in the NTDB. One example of such a situation is a feature representing an error on the map. In many cases, the features hold additional information, such as informative descriptions, and therefore they are not removed from the citizen layer, even though they have been transferred to the NTDB. This means that ‘unprocessed’ features and ‘processed’ features are both present in the citizen layer.

Fig. 1
figure 1

Functionality available to creators, editors and operators of a feature in Map Gretel

Full size image

2.2 Map Gretel social map service pilot

The pilot for the social map service was developed based on a number of key ideas: accessibility, freedom, quality and relationships. The key ideas are aimed at creating a service where users would find the system easy to use, where users are not restricted by the system to contribute data, and where users can create relationships with both other users and the NMA operators.

We wanted to keep the barrier to entry to the service low by allowing anyone to view the data, similarly to the citizen layers of NMAs in Switzerland (Federal Office of Topography swisstopo 2018) and the Netherlands (Verbeter de kaart 2018). Neither of these systems have registration and users are completely free to add features to the citizen layer. As user freedom in some ways stands in contradiction to data quality (Mooney and Minghini 2017), we decided to restrict feature contributing to registered users. Registration does have many benefits as it is needed to enable the social features such as having identifiable feature comments. The registration requires only an email address, which is used to confirm the creation of the user account. One other example of restrictions we chose to impose is the way in which the type of feature being contributed is selected. We provided a list of thirty or more feature types from which mappers could select. The list guides the mappers to contribute the kind of data in which the NMA is interested.

The user interface was simplified as much as possible to allow users who are not familiar with mapping tools to easily contribute. An anonymous feedback channel was also added to make it as inviting as possible to hear from the users. We wanted to give mappers the freedom to contribute instead of restricting them. We could have restricted contributions by means of predefined menus and other tools or given mappers editing privileges only to features that they themselves had created. Instead, we thought that in order to reach users who might have insights into what is really going on in the environment, it was reasonable to keep the system open. We therefore chose to allow mappers to edit all the features, even those that the mappers did not create themselves.

The implications of including aspects familiar from social media services in a VGI map service will, in the long run, develop relationships between the mappers and between mappers and operators. These relationships should help produce better-quality features since feedback and training have been shown to retain interest and increase quality in other VGI and citizen science-based projects (Minghini et al. 2017). Such relationships would also be useful if, for example, there would be some specific need from the NMA side to map a certain place with the help of mappers. Mappers with good reputations as reflected in their profiles could be asked to do certain assignments for the NMA, with the NMA being relatively confident that it would then receive high quality data. Mapper reputation could be based, for example, on the quality and quantity of their contributions.

2.3 Technical aspects of Map Gretel

The technical aspects of the social map service were driven by two criteria: functionality and ease of implementation. These criteria led us to choose the open-source project called uMap (uMap 2017) as the main development platform to use, which makes use of OSM. We have made significant modifications to the source code of uMap both on the client side and the server side, which proved necessary in order for the functionality to work as intended. We had to use technical solutions that did not favour performance and high-level scalability, and we also had to limit the designed functionality. The Map Gretel pilot has the following high level of functionality: a map browser, a citizen layer and a feature editor. Key functionalities are presented in Table 1 with a rationale for each one. The map browser displays the background topographic map, which users then use to explore the current situation on the map. On low-zoom levels, a heatmap is displayed to show where there is user-generated content. Operators see a heatmap of features that have not yet been evaluated. The citizen layer, which lies on top of the background map, displays the content that mappers have created. Due to technical limitations of the pilot, the functionality to display features on the map is limited to 20. Thus, the UI has a button to display features; this button is always visible. By clicking the button, 20 of the nearest features relative to the centre point of the map screen are displayed. The features are displayed as points or lines. The focus of the pilot was on point and line features; thus polygon creation was disabled. The features presented on the map are also listed in a side panel to show some of their attributes. By pressing on either the feature symbol on the map or an item on the list, more information on the feature will be displayed. There is also a place name search and a measuring tool in the UI. With the feature editor (Fig. 2), mappers can add features to the citizen layer as points or line strings by digitizing on the map or by importing data from a file, e.g. a GPX file. The feature editor allows any mapper to not only edit the title, description and type of any feature but also to adjust the geometry of any feature in the citizen layer. Operators can tag features as ‘transferred’ (feature has been added to the NTDB) or ‘rejected’ (feature remains on the citizen layer). For example, a walking path made by one mapper can have its geometry adjusted and description expanded by another mapper and finally have the path transferred by an operator.

Table 1 Key functionalities of Map Gretel and the rationale behind them
Full size table
Fig. 2
figure 2

Feature editor of Map Gretel displaying a footpath added by a user

Full size image

2.4 Proposed social and gamification aspects of Map Gretel

The social and gamification aspects of the service, which are based on a number of social media services, were not implemented in the pilot (Fig. 1). This functionality is the basis for the mapper-to-mapper and mapper-to-operator interaction. The key aspects are mapper profiles, mapper rankings, feature rating, feature commenting and feature confirming. When implemented, mappers will have nicknames that are to be displayed in both the features and the comment section, but the nickname can be hidden from the feature if the mapper chooses to do so in order to better protect their privacy. Feature creator and editor nicknames can be presented in the feature with a timestamp. From the profile, a mapper can monitor their mapping progression. The functionalities of the social and gamification aspects are presented in Table 2 with a description of each one.

Table 2 Key functionalities of Map Gretel that were not implemented in the pilot but which describe the proposed social and gamification aspects of the tool
Full size table

Commenting on a feature is a way of showing interest. Features that have been considered interesting or important by mappers aid the operator in making decisions about which features to focus on. Mappers also receive positive feedback when their contribution is commented on by other mappers and operators. Other mappers may have valuable information to add to the feature that is useful to both other mappers and operators. Operators can also improve their relationship with mappers in the comment section, while operator comments guide mappers to contribute better features. When an operator rejects a feature, the operator is asked to give a reason for rejection. The reason for rejection is displayed as a comment in the feature. Similar to commenting, rating both features and feature comments allows mappers to emphasize important contributions to the operators and other mappers. Each mapper can cast one vote for each feature and comment. This one vote rule will keep the voting democratic for the ranking system. The upvotes and downvotes are anonymous due to mapper privacy. Operator upvotes are visible since they guide mappers towards better contributions. Regarding confirmation, photos of the feature help operators in processing the feature. Keeping them visible only to operators avoids many privacy issues. The ranking system is based on the ratings and introduces a gamification aspect to the mapping, allowing users to know how much and how well they are performing compared to others; thus, visible ranks are needed. Visible ranks also inform the operator of the mapper experience. One example of the ranking system in Map Gretel is to count the number of upvotes a mapper has received regarding the features they have contributed. This particular rank would emphasise a mapper’s success in creating content thought to be interesting by the community. Another example is to rank the number of features that have been successfully transferred by the operator. This rank would emphasise a mapper’s success in creating content thought to be valuable by the operator. The extent to which a mapper scores well on both rankings could also be used as a rank. Operators also have gamification aspects included in their process of transferring features to the NTDB. Their rank is based on how well the operator detects the needs of the mappers and how actively the operator participates in the discussion. This can motivate operators to get in touch with users and ask for more details more often. The ranking is intended to help operators follow their own progress and is thus visible only to themselves.

3 Results from the Map Gretel pilot

The pilot for the social map service was launched on 23 March 2017 for the whole of Finland. During the launch the pilot was promoted by NLS on their website and on their Twitter and Facebook accounts. The pilot was also covered in a few newspapers at the time. In the first 6 months of operation, the pilot has expanded to include more than 363 registered users, who have contributed over 950 features to the citizen layer. A total of 146 users have created one or more features meaning that roughly 40% of users have made a contribution. Thirty-four users have made more than five contributions, and 16 users have made 10 or more contributions. A total of 3326 actions have been made by the users, which includes newly registered users (363), new features added (950) and features edited (2086). A representation of all the accumulated data is presented as a heatmap in the service (see Fig. 3). Of the features, 687 (73%) have currently been processed and 330 of them (48% of the processed contributions) have been transferred to the NTDB by the 15 NMA operators who participated in the pilot. The operator’s performance at processing features was not measured and thus cannot be compared to the previous email-based system. The operators were processing Map Gretel contributions on top of their regular work, and we did not want to make them feel pressured but rather have the operators play with Map Gretel. However, most of the operators did not find the work required laborious. The most common reason for not transferring a feature is that it does not belong in the current feature catalogue of the NTDB (slipways for boats, for example), and thus cannot be transferred. Only around 10% of all the features had either insufficient data or could not be validated by the operators, for example, from an aerial image, and were rejected for lack of quality. We encouraged mappers to contribute features that were not included in the NTDB feature catalogue knowing that we could not transfer them. The aim was to find out what new features users would add to the citizen layer. Features that are not part of the NTDB catalogue will remain in the citizen layer. Figure 4 presents one example of data contributed by a mapper and processed by the operators, where buildings that no longer exist were marked as errors on the map and a new building was drawn by the mapper. After the data were processed by the operator, old buildings were removed and a new building was added to the NTDB.

Fig. 3
figure 3

Accumulated data from users is presented as a heatmap in the social map service

Full size image
Fig. 4
figure 4

User contributions (on the left) for buildings that no longer exist and drawing of a new building, which the operator then processed and transferred to the national topographic database (NTDB) (on the right)

Full size image

3.1 User feedback

Users provided 31 messages via the feedback page of the map service. The feedback varied from bug reports to suggestions for new functionality, but users also provided detailed descriptions of features that they were unable to add to the system. Some users reported that they were unable to remove some of the contributions they had made by mistake. Much of the feedback had to do with the pilot nature of the map service, meaning that it addressed bugs and incomplete features. Some feedback was clearly from experts in the field, who were kind enough and interested enough to detail multiple issues, while also praising the service. As the feedback was very constructive, we responded to all feedback that gave an email address. Here is one example of expert feedback (translated from Finnish): ‘For some reason, nobody before has developed this sharing of geographic data from the users’ perspective (having a low barrier to entry)’, meaning that there is not currently a service that makes it very easy for citizens to contribute data to an NMA.

3.2 User survey

We conducted a web-based, 5-to-10-min survey with 10 questions and received 78 responses from users. We sent the survey to all registered users via email and also provided a link to the survey on the Welcome view and on the navigation bar of the map service. The aim of the survey was to obtain an overall idea of what the average user is like and gain an understanding of how they would like to see the service developed further. We asked how often the user had visited Map Gretel. 54 of the 78 respondents answered ‘a few times’, and 12 answered ‘often’ or just ‘once’. (See Fig. 5.) Regarding the ‘often’ answers, it is important to note that the service has been up and running for only 6 months, but this pattern does follow what is often found with other citizen-based projects, i.e. a small number actually make the most contributions (Fritz et al. 2017). We asked whether the user had added features and roughly 70% (54) of the respondents answered ‘yes’. We asked the respondents if the features that other users had contributed had been useful, and 25% of them answered in the affirmative. This rather high percentage was somewhat unexpected, since the 950 features contributed were spread around the country and not restricted to one particular area of familiarity (see Fig. 3). Given the number of features and the extent of the area in which they are situated, a single feature has a low likelihood of being both near and useful to other users. We also asked what new functionality users would like to see included, and 67.6% of them chose a mobile mapping application. This is unsurprising as many citizen science projects now use mobile apps for participation (Seibert et al. 2017). 54.4% also wanted to receive notifications of when their contribution had been processed by the NMA operator, which makes sense since citizens want recognition that their contributions are being used (Fritz et al. 2017). The open feedback from the survey was much like the feedback given through the service. Many of the comments had to do with the user–operator relationship. Below is some translated feedback.

  • ‘It’s great that an active mapper can add something that is not visible on the map’.

  • ‘I would like to know about the processing time. My contributions have still not been processed’.

  • ‘There’s no mobile application’.

  • ‘There are issues with the user interface’. The respondent then listed multiple relevant issues, such as the lack of transparent layers.

Fig. 5
figure 5

78 respondents answered the user survey on how often they have visited the service

Full size image

3.3 NMA operator survey

Eight of the 15 NMA operators answered a survey directed at them. The operators estimated that approximately 10% of the contributions were of low quality (mostly tests done by users). When asked what portion of the data has been useful or usable, the operators answered ‘more than 60%’. As to whether the processing of features has been laborious, three out of eight operators answered yes. The operators thought that the geometric quality of the data was mixed, as was to be expected when some users imported GPX tracks and others drew their tracks on the map freehand. One operator noted that a large proportion of the features are paths that actually exist in the real world, but that are not in the NTDB. This confirms that Map Gretel also yields other types of data than just point data, unlike the existing report system used by NLS, which cannot handle line strings. We estimate that approximately 50% of the features contributed by the users to Map Gretel are some type of path and therefore are a new type of data received from citizens. There has been both excitement and a lack of enthusiasm among the operators regarding the whole idea of VGI. The reason for the lack of enthusiasm of some of the operators may be the result of operators having to process Map Gretel data on top of their normal work. The data quality may also have had an effect on the operators’ enthusiasm. Overall, however, the response has been positive, and operators are clearly interested in the idea of including VGI in their processes. As one operator put it: ‘A great service for both citizens and us operators. Thank you for the entire development team!’ The operators emphasised the importance of being able to get in touch with users as a way to obtain more valuable information.

3.4 Overall results

Overall the social map service has been accepted very well by its users and operators alike. We were pleased with the number of people who registered for the service and with the number of features contributed over the relatively short time span of the service. The quality of the contributions was also at a high level. The users were generally in favour of a mobile application as an easier way to collect data. The desire for a mobile application was also expressed by some of the operators when we discussed the future of the service with them. The user–operator relationship, which unfortunately did not realise its full potential in this pilot project, was considered important by both the users and the operators. From the user side, there is a clear need to be recognised and to receive acknowledgement that their contribution has been received and deemed of value. From the operator side, the ability to directly communicate with users was seen as a way to gather even more valuable information. The operators know the right questions to ask in a given situation, and therefore any means of supporting user–operator communication is a way to improve data quality and also facilitate user retention. Due to the lack of methods to communicate with users (e.g. the possibility to comment on a particular feature), operators figured out a way to reach users by editing the descriptions of the features as a way of explaining the decisions they made when, for example, choosing not to transfer the feature to the NTDB. This speaks to both the need for better user-operator communication and also the enthusiasm of operators in facilitating such dialogue. More generally, both the users and operators need better tools for engaging in VGI work.

4 Future implications of VGI in NMA procedures

Currently, the use of VGI in many NMAs is low; but as this study has shown, it is not overly difficult to launch successful initiatives that aim to incorporate VGI in NMA procedures. Our pilot service had a fair number of users, and users uploaded a considerable number of features in a relatively short period of time, which indicates that there are citizens interested in VGI, even though the service did not include the planned incentives such as gamification (Olteanu-Raimond et al. 2017b) and social aspects. Compared to the traditional way of gathering information from citizens, which yields approximately 500 feedback reports a year, Map Gretel has already gathered over 900 features in half a year, many of which are types of data, like paths in a forest, that the existing feedback system cannot provide. Our service was considered to have a rather low barrier to entry: it only required the users to register with an email to make contributions and edits. Had we released a mobile application, which is what the majority of the users wanted, the resulting data would most likely have been even better, both in quantity and quality. A mobile platform for Map Gretel is the logical next step. As for other future work, we found that citizens and NMA employees alike are interested in VGI and that there are many ways to support both parties. Citizens need confirmation and acknowledgement of their work; the emphasis on the user–operator relationship already partially meets that need. Applying methods used in social network services such as voting and commenting are simple but effective ways of promoting dialogue between not only the users themselves but also between users and operators. These methods require further study in a VGI context. Based on our results, the operators are keen to ask users more questions, while users are usually interested in hearing that their contributions have been useful. Therefore, integrating this functionality into Map Gretel and other similar projects would be beneficial.

When citizens are brought into the realm of data production, protecting their privacy is a considerable research challenge (Mooney et al. 2016). Currently there are initiatives to protect the privacy of citizens and give them more control over their data (Guinness et al. 2015), but there are still many open questions and often clear principles and rules are still lacking. Issues regarding privacy in VGI are further emphasised in the newly implemented EU General Data Protection Regulation (GDPR), which is ‘designed to harmonize data privacy laws across Europe, to protect and empower all EU citizens’ data privacy and to reshape the way organisations across the region approach data privacy’ (Regulation (EU) 2016). VGI initiatives should take into consideration the new laws, as the collected data can contain ‘personal data’, for example, location data that can be linked to a person (Regulation (EU) 2016).

Previous studies have suggested that VGI has great potential, but also many challenges to overcome. VGI could potentially complement and even rival traditional mapping sources in terms of both data quality and richness (See et al. 2017), but workflow developments and protocols for data collection processes have to be developed in order to overcome the challenges pertaining to VGI data quality (Minghini et al. 2017). There are also issues with the metadata of VGI, as it is patchy and extremely heterogeneous (Bastin et al. 2017). Citizens need to be supported when contributing VGI, while also having their privacy protected. Recruitment, motivation and retention need to be addressed in the future (Fritz et al. 2017). One way is through the use of gamification, as it shows promise as a method for increasing motivation among citizens (Olteanu-Raimond et al. 2017a). Gamification is a new area of expertise that NMAs can familiarise themselves with in order to better reach and retain their users.

What kind of future implications does Map Gretel have with respect to the procedures used in NLS for updating maps? At the very least, it has been recognised that interacting with citizens, an important aspect of a successful VGI platform (Olteanu-Raimond et al. 2017b), can create positive publicity and aid in collecting data that would otherwise be left unmapped. NMAs are seen as trustworthy and reliable, and this could be leveraged when engaging citizens. One way to capitalise on this trust is to introduce the topic of VGI in elementary schools. This would enlarge the spatial coverage of VGI throughout the country. Embedding the topic of VGI into the school curriculum would add continuity to the process and ease communication with citizens, as already tested by the NMA Kadaster Netherlands (Bol et al. 2016). Citizens will likely be more willing to share their data with an NMA rather than with other entities, especially if they have had positive interactions with an NMA through school cooperation. To have these positive interactions, NMA operators need tools that will help them do their job better. Our study revealed that operators are interested in working with citizens but they need more advanced tools that allow for dialogue with the citizens making the contributions.

A more fundamental change regarding the advancement of automation in the future can make certain elements of VGI redundant (de Oliveira et al. 2014), and it might focus VGI into areas of data collection that automation cannot reach. VGI can also only necessarily comprise a small part of the NMA’s whole data collection process, and its role in the process might shift more to data validation rather than data collection in the future. Citizens will more likely avoid repetitive tasks, especially if they can be done by automation, and favour tasks that require more intelligence, such as validating a data set that was produced via automation. The Missing Maps project (Albuquerque et al. 2016), for example, avoided repetitive tasks by having experienced users validate each other’s contributions. Therefore, we foresee that in the short run, NMAs will venture further in the direction of games and gamification that are integrated with the processes of data collection. But in the longer run, NMAs might be more interested in the analysis that citizens can perform. As an example, a data set that has been produced via an automation process can be analysed by a citizen in a game-like environment and the analysed result can then be processed by an NMA operator to validate it, which will both help save resources and give the user more incentive to continue making contributions.

For the near future of VGI as a whole, our study has led us to envision a VGI service influenced by social media services such as Facebook (social networking tools), WhatsApp (privacy-respecting messaging) and Instagram (visual information tools), and also by games such as Pokemon Go (incentives for outdoor activities). The common theme across these different services is the very low barrier to entry, simplicity, user interactions and perhaps most importantly—fun. A simple voting or commenting functionality can be seen as a gamification element when citizens compete to become the most respected player in the VGI platform. At this point, VGI is not only about the data collected by the user, but also a way for users to enjoy their time and gain respect among their peers. Users will likely expect something more than just the good feeling of helping out in the future when they participate in VGI initiatives. They already value their time and will more likely spend it on something that is considered an experience. We predict that whoever can develop a service that makes the role of a ‘citizen as a sensor’ fun will raise the data collection process to the next level both in terms of quantity and quality.