A Platform for Location Based App Development for Citizen Science and Community Mapping

Abstract

Community Mapping and Citizen Science involve members of the public in projects to address real-world problems such as noise pollution, air pollution or large-scale development in their neighbourhood. Many of these are inherently location-based and maps provide a powerful tool for engagement. Most importantly, they can be tailor-made to display information required by the drivers of these projects—different groups of people with different interests. Previous Community Mapping and Citizen Science projects allowed the public to capture data for use on such maps via web based systems. However, mobile devices offer additional means of data capture and their in-built sensing devices (microphone, accelerometer, GPS) allow participants to work with additional types of information not available on web-based systems. Although many such Applications (Apps) exist, our experience with community groups shows that flexibility is key—the groups themselves must be able to decide what information they are interested in. While it is possible to meet this need by developing a bespoke App for each group, many of the group members involved in such projects are not programmers and do not have funding for bespoke development. This paper describes the development of a location based services App platform for Community Mapping and Citizen Science. The platform allows an unlimited number of bespoke Apps to be created by a non-technical administrator, without the need for programming skills.

1 Introduction

Citizen Science is a form of research collaboration involving members of the public in scientific research projects to address real-world problems (Wiggins and Crowston 2011), and has also been defined as the scientific activities in which non-professional scientists volunteer to participate in data collection, analysis and dissemination of a scientific project (Cohn 2008; Silvertown 2009). Such projects form an open collaboration where the goals of the scientific endeavour are often set by the communities who will benefit from the results obtained and from the additional understanding that is derived through involvement in the project. A similar approach is taken in Community Mapping activities, although here the reach of projects is broadened out beyond the traditionally ‘scientific’ measurement towards issues relating to perception mapping (where users describe how they feel about their environment, what they like and dislike, what changes they would like to see) as well as identifying sites for potential development and recording local history (Ellul et al. 2009b, 2011). In both cases, the ability to include a location component to data capture forms a fundamental component of any project—for example, noise and air quality measurements are spatial in nature, an individual’s perception of their neighbourhood may relate to specific instances of graffiti or fly tipping. The importance of such activities when considering environmental issues and sustainability should not be underestimated—indeed, a Principle 10 of the 1992 Rio Declaration states that (United Nations 1992):

Environmental issues are best handled with the participation of all concerned citizens. At the national level each individual shall have appropriate access to information concerning the environment [..] and the opportunity to participate in the decision making process.

Until recently, data capture for both of these project types was often undertaken by users sitting at their personal computers and digitising data of interest. Whilst this has worked very well to date (Ellul et al. 2011), the emergence of Smart Phones with in-built location sensors (via the mobile network or Global Positioning System, GPS) can greatly facilitate data capture when compared to the web-based approach.

Previous projects (Ellul et al. 2011) and our experience with community groups shows that flexibility is key to engaging people in both Citizen Science and Community Mapping projects—participants themselves must be able to decide what information they are interested in. This in turn highlights the importance of bespoke tools for each project, and in each case the required Smart Phone Application (App) must be developed and tested, requiring programming expertise. Therefore, for such projects to take advantage of location-based tools and services (and the resulting improvement in data capture methods), some level of technical skill is necessary to develop the required bespoke Apps. While such expertise (or funding to develop the Apps) may be available in some teams, this is often not the case. To maximise the reach of Smart Phone based Citizen Science and Community Mapping activities, a non-programmatic approach to bespoke web and mobile tool development is required.

We have previously reported (Ellul et al. 2009a, b, 2012) on the development of a web-based platform for Community Mapping and Citizen Science. In this paper, we report on the development of a mobile location based platform to meet the same needs—i.e. to allow non-programmers to deploy Apps configured for the requirements of a specific scientific or community activity.

The remainder of this paper is structured as follows—following a brief overview of Citizen Science and Community Mapping, we review a number of relevant location-based Apps, along with existing platforms to allow non-technical users to develop and deploy such Apps. Limitations of these approaches are discussed in the light of three specific projects in which we are currently involved. Our platform for location-based App development is then presented, and the paper concludes with considerations as to its potential, along with an outline of further work required before the platform can be deployed to a wider audience.

2 Background

2.1 Citizen Science

Although only having received attention recently, Citizen Science in fact pre-dates modern science. As Silvertown (2009) notes, until the late 19th century, science was mainly developed by people who were otherwise employed, using their free time for data collection and analysis. Even with the rise of the professional scientist, the role of volunteers has not disappeared, especially in areas such as archaeology, where it is common for enthusiasts to join excavations, or in natural science and ecology, where they collect and send samples and observations to central repositories. Activities include the Christmas Bird Watch that has been active since 1900 and the British Trust for Ornithology Survey, which was established in 1932 and has collected over 31 million records (Silvertown 2009). Astronomy is another area where volunteers have been on par with professionals—for example where the identification of galaxies, comets and asteroids are considered (BBC 2006). Meteorological observations have also relied on volunteers since the early start of systematic measurements of temperature, precipitation or extreme weather events (World Meteorological Organisation 2001). A list of additional citizen science activities can be found in Haklay (2012) and also in Scientific American (2012).

Of particular relevance to location based services is participatory sensing, where the capabilities of mobile phones are used to sense the environment (Haklay 2012). Some mobile phones have up to nine sensors integrated into them, including different transceivers (mobile network, WiFi, Bluetooth), FM and GPS receivers, camera, accelerometer, digital compass and microphone. In addition, they can link to external sensors.

2.2 Community Mapping

A United Kingdom (UK) Government White Paper entitled “Communities in Control—Real people, real power” (Communities in Control 2008) published in July 2008, and the more recent Big Society initiatives by the United Kingdom Government (BBC 2011) both reflect ongoing efforts by central and local government to increase community participation and generate a more vibrant local democracy. Access to information forms an important part of this process (and indeed forms the first element on the latter of citizen participation proposed by Arnstein 1969). Internet-based Geographical Information Systems (Web GIS) have long been seen as part of this information dissemination process, as well as being a tool to encourage participation in local decision making. They have importance both in the top–down ‘information’ dissemination processes and the bottom–up ‘participation’ processes forming part of local planning activities (Talen 2000). In particular, community-sourced mapping is of importance—information regarded as relevant by community groups is not necessarily identical to that provided by local government (perhaps due to issues of scale, currency or trust). Government-issued information also tends to ignore local knowledge (Elwood 2007). Community Mapping projects such as those described in Ellul et al. (2011) thus have particular relevance as they allow each group to identify their own interests, define what they would like to appear on their map and take ownership of the data capture, moderation and maintenance processes.

2.3 Bespoke Location-Based Apps for Citizen Science and Community Mapping

A number of Apps are available that, although not customisable to the requirements of individual community groups do offer a useful insight into how Location-Based Apps can be used in the context of Citizen Science and Community Mapping. An in-depth description is given here of one noise monitoring App, as this illustrates how sensors built into the mobile device can be used to replace more expensive tools (sound meters), widening the potential participant group for noise-related Citizen Science activities. This is followed by a very short overview of a number of other bespoke applications that primarily relate to data capture. We do not aim to provide a comprehensive list, in particular as Apps are emerging daily, but rather to illustrate what can be achieved in terms of developing bespoke location-based Apps for Citizen Scientists and Community Mappers.

EveryAware WideNoise (EveryAware 2012, Fig. 1) has been developed as part of the EU FP7 funded EveryAware¹ research project and permits a user to monitor the noise levels around them, making use of the in-built microphone on a Smart Phone.

Fig. 1

EveryAware WideNoise start screen, decibel prediction screen and qualitative rating of the noise

When the EveryAware WideNoise application is first opened, a start screen allows the user to start taking noise samples (of 30 s duration). During recording, a graphical representation shows the change in sound volume (in decibels). The user is also able to extend the audio recording from the default length. At the same time, is also possible for the user to attempt a guess at the maximum decibel level the audio recording may reach. Once the user has finished recording their noise sample, a noise context rating is shown allowing comparisons e.g. a sleeping cat, rock concert area. The user is then able to restart the audio recording or carry on to qualify the noise—do they love or hate the sound, is the sound calming or hectic. The user can then send the report to EveryAware for further analysis—the recordings are also made public on the WideNoise website. The user is then able to share noise values via Facebook and Twitter to raise awareness amongst friends.

Similar noise-focussed Apps exist and can also be downloaded free of charge. NoiseTube (Maisonneuve et al. 2010), was created in 2008 at the Sony Computer Science Lab in Paris and is currently hosted by the BrusSense Team at the Vrije Universiteit Brussel. NoiseWatch, from Eye On Earth (2012) set up by the European Environment Agency to monitor air quality, noise and water quality) allows the user to take noise samples for 10 s apiece.

Looking beyond noise, Apps such as those developed by Project Noah (2012) allow people to document nature with their mobile phones and assist scientists with ongoing research. Research scientists can also use the platform to define “missions” where specific animals and wildlife are searched for in particular areas of the globe. LeafWatch (2012) is a UK-based App which allows users to identify and photograph leaves, and also to give a rating to their condition, enabling the collected data to be used to monitor tree and plant health². In the context of Community Mapping, perhaps one of the best known (in the UK) Apps is Mappiness (MacKerron 2011). This App prompts users, at random intervals during the day to rate their level of happiness, and collects this information along with who the user is with, where they are and what they are doing.

2.4 Location-Based App Development Platforms for Non-Technical Users

A number of existing platforms to enable non-technical users to undertake App development can be identified. For example, for the Android platform, the Massachusetts Institute of Technology offer the App Inventor tool (App Inventor 2012), Fig. 2. App Inventor uses visual design so the designer can preview the final results.

Fig. 2

App Inventor dashboard

A second alternative is offered by EpiCollect (Aanensen et al. 2009, Fig. 3) which provides a web application for the generation of forms and freely hosted project websites (using Google's AppEngine). EpiCollect allows a user to create a mobile data collection project and specify what kinds of data they’d like to collect such as text, textboxes, radio buttons and check boxes. The application can then be accessed on a compatible mobile phone by downloading the EpiCollect App and loading the project. After data has been collected, the project creator can logon to their account on the EpiCollect website and see all the collected data included text and pictures in database format.

Fig. 3

The EpiCollect interface

A third App development platform is offered by the Open Data Kit (ODK, Hartung et al. 2010) project, which allows organisations to develop field-based data collection toolkits. Functionality provided includes the ability to ask users to capture text, numbers, dates, location, media and bar codes and to select a single or multiple options from a list. An interactive form designer is used to create an XML version of the required form, which is then deployed to a pre-configured server. The ODK App on the device can then be configured to connect to the server, allowing users to enter data into the form and save it to your server.

Additional fee-based App development tools also available—for example doForms³ allows capture of date, text, single and multiple choice, lookup tables, GPS coordinates, sketch drawings, photos, video and audio clips and also includes “skip” logic, which allows the system to respond dynamically to users’ selections. A similar platform is available from MobiForms,⁴ which also offers integration with databases such as Oracle and MySQL and also offers GPS integration.

3 Requirements for Location-Based Citizen Science and Community Mapping Apps

As can be seen from the range of platforms described above, a requirement for flexible, bespoke, App development by non-technical users is not unique to our research team. However, our review of existing approaches highlights three main issues—firstly, some platforms require you to upload data to a central server hosted by the platform providers. This could cause issues with regard to data confidentiality, particularly where sensitive data is concerned (see the Monitoring of Illegal Logging case study below). Given our existing web-based platform, we additionally require that data is integrated directly with our servers to make it immediately available to our research teams. Secondly, many of the platforms do not offer full connectivity with all the sensors available to citizen scientists on a mobile device—for example, the accelerometer or microphone. Even where sensors such as GPS can be used, this is often restricted to one ‘reading’ per App, which is not appropriate to many location-based Apps requiring continuous positioning traces. Thirdly, the platforms do not offer the range of functionality required to support activities where users may not have the literacy or numeracy skills required to work with standard text-based forms.

Looking specifically at the three platforms described above, while App Inventor makes very good use of all the sensors and devices on board the Smart Phone, it requires the App designer to design state machine diagrams and link them to various variables/methods and to also be able integrate with web services. Additionally, Apps cannot as yet be uploaded to the Android Market⁵ and multi-screen Apps are not available.⁶ For EpiCollect the data can be exported to CSV or Excel format, but there are limitations in terms of the types of data that can be collected—namely text and pictures. It is also not possible to associate multiple GPS readings (e.g. a GPS trace) with the data and all data must be uploaded to the EpiCollect server (although as the project is open source this could be altered). A similar restriction on the GPS trace option exists for the ODK platform and although this tool does allow you to save the data directly to your own server, it does not integrate well with the on-phone devices—indeed, camera (photo or video) options are not provided, and no options are included to integrate with the on-board microphone or accelerometer.

Specific requirements for two Location-Based Apps Noise Measurement and Monitoring Illegal Logging and Poaching, and one Community Mapping App Perception Mapping are described here to illustrate the importance of these issues:

3.1 Noise Measurement

As can be seen from the list of bespoke location-based noise Apps described above, noise forms a key area of interest to Citizen Scientists, and capturing noise readings using appropriately calibrated equipment can be used to empower citizens to remove a noise nuisance in their neighbourhood (Haklay et al. 2008). Mobile phones, with their in-built microphones, provide an appropriate tool for this type of activity. However, work previously carried out by our team highlights the fact that in the case of community-led citizen science, a generic Noise App does not meet requirements. Two issues arise: depending on the source of the noise nuisance, different protocols may be required for measurement. In some cases (e.g. flight noise), taking three 1 min samples at random times during the day may be appropriate. In other cases, a longer measurement time may be required (e.g. 5 min sampling time). Fixed length noise measurement (e.g. 10 s from NoiseWatch) does not offer this flexibility. Secondly, as shown above, Noise Apps include both quantitative data capture [the dB(A) measurement] and qualitative information. The latter will vary depending on the requirements of the individual community and the “standard” values such as love/hate, calm/hectic, alone/social, natural/man-made offered by EveryAware WideNoise do not match those required by groups monitoring flight noise, where tags requested by the group included enjoyable, annoying, threatening, high-pitched, shrill and many others, along with a requirement to select multiple options rather than the pairs suggested by EveryAware (Fig. 1). Indeed, it is important for each community to be able to define its own qualitative text and word groupings.

3.2 Monitoring of Illegal Logging and Poaching by Non-Literate Users

Dr Jerome Lewis is an anthropologist working with UCL’s Extreme Citizen Science (ExCiteS) group. He has established a long-term working relationship with a group of pygmy hunter gatherers in the Congo basin, investigating (amongst other things) discrimination, economic and legal marginalization. As part of this effort, he has developed a series of tools to support data gathering of conservation-related information such as resource damage in logging, illegal logging, poaching. These custom-built tools, developed in conjunction with Helveta, have been designed specifically for use by non-literate groups (Lewis 2007). A second phase of the research is designed to further empower the hunter gatherers by allowing them to visualize patterns of illegal activity across space and time. As part of this, there is a requirement to move from the custom Helveta platform for data capture to a more mainstream platform such as Android. The current tools use icons to allow data logging by non-literate hunter gatherers, and it is expected that the new tools will make use of the same image picker approach. A series of appropriate icons to cover poaching, illegal logging and other activities have thus been developed in conjunction with the tribes people themselves. Image picker functionality is required as follows (Fig. 4):

Fig. 4

Sample draft icons for the illegal logging and poaching app (courtesy of Dr Jerome Lewis)

• The application should start with a screen showing six icons.

• Clicking one of these icons takes the user to a second level page of icons relating to that specific topic.

• Clicking a level 2 icon takes the user to a level 3 icon, which the user can then click on to capture the data point in question.

• As part of the level 3 click, the GPS reading of the device should also be saved.

As many of the poaching sites are some days’ walk into the forest, any tools developed cannot assume that a mobile phone network will always be available. Data must be saved to the local device. The nature of the data captured is also very sensitive.

3.3 Perception Mapping

Perception mapping is an important component of Community Mapping, and allows users to comment on the positive and negative aspects of their local environment, often providing a mechanism to identify issues of concern to each community group. Such information could then be used by, for example, Local Authorities who could prioritise areas for improvement. Previous work with community groups has highlighted that the information of interest to one group may not be identical to another. One neighbourhood may have a problem with graffiti, while another has a problem with illegal rubbish disposal. Although perception mapping can be done as a paper-based exercise (giving people post-it notes to place on a map) or on a web based Community Map, Smart Phones offer a much more interactive, real-time option to collect such data. The App should allow the user to walk around their neighbourhood, and take a video (with voice recording of their commentary) as they walk, tracking their location as they move using GPS in order to be able to tag elements of the video to specific locations. Having a voice-based commentary overcomes issues that many users have with typing large quantities of data using the small touch-based keyboards on a Smart Phone, and the video allows them to focus on specific areas related to their voice-over commentary.

4 The Resulting Platform

A key decision to be made at the outset of the project was between an HTML5 web application and native App programming. HTML5 Apps are written with web standards, primarily HTML, CSS, and JavaScript, and can be deployed on all mobile platforms. This makes them cheaper to produce and easier to deploy to wider audiences. However, currently issues can be identified with integration with a number of sensors (e.g. GPS, accelerometer, camera) on mobile devices, and the wide range of browsers on the devices means that not all HTML5 functionality is available on all platforms as yet (although the standard is continually evolving). An always-on connection may also be assumed.

It was therefore decided to initially develop the App using Java and XML for the Android platform. This decision was driven in part by the lower cost of Android Smart Phones compared to the main rival Apple (at the time of writing, a Samsung Galaxy Europa Black phone with Android can be bought as a pay-as-you-go phone for £49.99,⁷ versus an Apple iPhone 3GS for £299.99⁸), and their greater level of uptake (Android powered 59 % of all mobile devices shipped in the fourth quarter of 2011, versus 23.8 % from Apple⁹) meaning that Apps could be deployed to a greater number of users. Android/Java development also permits direct access to the required sensors. Crucially, working with the native development environment means that the App does not assume an ‘always on’ data connection.

Figure 5 shows a Use-Case diagram for the developed platform. As can be seen, two groups of functionality have been identified—web-based administrator functionality which allows non-specialist coordinators of Citizen Science and Community Mapping activities to generate Apps and deploy them to the general public, and the Mobile Application itself, which combines the requested functionality in the order required.

Fig. 5

Use case diagram for the platform

Figure 6 gives more detail about the functions available to each Smart Phone App. Currently this includes login functionality, the ability to capture text and dates, single drop-downs and multiple selections, photographs, audio recording, video recording, capturing a single GPS reading, capturing a GPS trail, record accelerometer readings, picking an image from a set of images (which can in turn link to further sets of images), saving the captured data, and uploading the data to the server.

Fig. 6

Functions available for each Smart Phone App

Each bespoke App developed using the platform makes use of two components. Firstly, a series of XML documents are generated, detailing the layout of each page in the App and the order in which the pages are linked. The required XML documents are generated by the web-based administration application, and then embedded into the.apk file, which is the zip file that makes up a deployable Android application. Secondly, a set of Java classes have been written to process the XML and launch appropriate functionality and activities depending on the required content. When the App is run, the Java code parses the XML files to generate the appropriate forms, and generic code handles data capture on the forms, depending on the type of data (photo, GPS point, GPS trace and so forth).

A worked example is given here to illustrate the end to end process for one form. The following XML (Fig. 7) is used to generate the form shown in Fig. 8a. The ID values of the of the elements, which are used to determine the type of data being captured and the element TAGS are used to provide the field names into which the resulting data is to be inserted once submitted into the database.

Fig. 7

XML form creation

Fig. 8

a The Resulting Form and b the captured data

The resulting form appears as shown in Fig. 8a. Once the user has finished capturing data, data is stored on the devices’ SD card for upload to the server once a Wi-Fi connection becomes available. Once the user finalizes data entry, the Java code parses the elements on the form, and generates a name/value pair text file which is stored on the SD card on the device for upload at an appropriate time (e.g. when Wi-Fi is available). The data file from the form is shown in Fig. 8b.

A similar approach is taken for other types of data capture. Fig. 9 shows the layout settings required for the Accelerometer and the GPS trail data capture types.

Fig. 9

a XML layout for accelerometer and b XML layout for GPS trail

In each case, clicking on the respective button calls a method which starts an activity of the required type. For the accelerometer, it is changes in orientation of the device that are recorded—i.e. a listener is set up which records any changes in the X, Y and Z orientation values. For the GPS Trail, a location is requested and recorded every second, through a location listener. The GPS Trail functionality can be run in stand-alone mode, but can also be combined with other data capture types such as audio or video recording.

For all data capture, when a suitable network connection is enabled (either 3G or Wi-Fi, depending on the user’s preferences), the data is posted to the server as a series of name value pairs. Although XML could be considered a more appropriate, generic format for data submission, the pairs allow existing code (for data submission on the Community Mapping web application, see Ellul et al. 2009a) to be used to update the platform database, using the standard storage formats defined for previous projects. This means that uploaded data will be immediately available to the web-based platform (subject to privacy issues where data will not be published).

5 Discussion

Although still a prototype, the development of a very flexible generic platform for App creation for a location-based data capture for Citizen Science and Community Mapping has proved feasible in the chosen environment (Android). Importantly, the platform is configurable via XML files, which in turn can be generated by a web-based administration tool, and can make use of all the inbuilt sensing devices on the Smart Phone. XML configuration negates the need for Citizen Scientists and Community Mappers to employ programmers and developers for each new project, and opens up data capture to a much wider user base. Given that initiators of, and participants in such activities often do so in their own time rather than via funded research projects, minimising development and deployment costs using this generic platform is appropriate.

The platform has been developed to be as flexible as possible in terms of the types of data that can be captured as in Community Mapping and Citizen Science activities the context, driven by the end users, is as valuable as the measurements that are collected by the community. The data types that can be collected currently include numbers, text, video, photography, pull-down lists, multiple selection lists, GPS readings, GPS traces, accelerometer readings and image pickers, providing great flexibility as to the range of information that can be gathered. The single generic “platform” code base will also be easier to maintain in future than different bespoke Apps developed for different activities.

A number of key functions differentiate our approach from those available to date. Firstly, the ability to work offline is fundamental to working in situations where a network is not available—both in the Congo Basin but also in some cases in the United Kingdom such as on the London Underground. Secondly, the image picker functionality, where clicking on an icon brings up a second and a third tier of options, is very useful when working with non-literate users, who can also actively participate in the icon design. Again, such functionality could also be useful when working with groups in the UK having low levels of literacy—or example new immigrants. Thirdly, the ability to record both individual GPS readings (associated with a photograph, for example) and GPS trails opens up the potential for continual measurements—for example, an App could be developed which measures noise exposure during a person’s commute to work, tracking the points on their route where recommendations are exceeded.

All map-based data is captured and held in native spatial data format inside the database. This opens up the data to be shared across researchers in the group, who can then take advantage of visualisation and analysis functionality built into Geographical Information Systems to examine and interrogate the data. The central data repository also permits questions relating to the quality of user-generated location-based Citizen Science and Community Mapping data to be examined.

An additional advantage of the database-based approach is the integration with a very well established Community Mapping and Citizen Science platform (Ellul et al. 2011). While many citizen science tools are available, they are not integrated into an online Community Mapping framework that allows rich data collection and post-collection annotation in bottom-up activities. Our framework provides the opportunity for further annotation of data, beyond that possibly by touch typing into a small Smart Phone or recoding a commentary as the user walks. Indeed, two avenues of data capture are automatically provided—an App based approach and a web-based approach, increasing the reach of any project to those who don’t own a Smart Phone.

Although designed for Citizen Science and Community Mapping activities, the platform provides enough flexibility for use with other data collection tasks. As projects evolve and new requirements emerge, these can be added to the existing platform—the platform can also be easily extended to handle other types of data, such as that from external sensors coupled to the Smart Phone.

One issue common to many Location-Based Services also impacts the Apps developed using this platform—the accuracy of positioning technology, and in particular its limitations in an indoor setting. Network based positioning (using the mobile phone signal) can overcome these issues in some cases. Additionally, the coupling with the editable online Community Maps allows users to validate that their data was indeed recorded correctly, and make corrections if necessary.

A second issue that may arise is the size of the App itself—with traditional bespoke applications, only the code required by the App is included in the package. In our case, however, the generic code to handle all potential data sources and capture must be included, as the App does not know what data types it will be working with until it reads the XML configuration file when it is loaded.

However, perhaps the most important issue to be addressed within the project is the selection of Android as a development environment. While this does ensure the maximum reach for a single environment, the number of users of other devices (Apple, Research in Motion) cannot be ignored, and if required further versions of the above platform may be developed to address this issue.

In addition to multi-environment development, a number of important steps remain to be carried out before the platform can be deployed. Key amongst these is the skinning and design of the interfaces presented to users. Our platform currently generates prototype Apps using basic Android interface widgets (buttons, text boxes), which although usable are not very attractive. These need redesigning, perhaps to include the option of App or Community Group-specific ‘branding’ options that are currently available for the web based version of this platform.¹⁰ Further integration is also required with the Community Maps themselves—moving from a basic manual integration to automatic data upload with the possibility for users to choose whether to share their data with the world or to submit data to the project without sharing. As part of this, the current administration tools require expansion to fully automate the generation of the XML configuration files used to generate each App by the platform. Testing of the resulting Apps is also required—particularly in situations where battery life, lack of GPS or network signal is an issue.

Haklay (2012) notes the importance of knowing the accuracy of the instrumentation (in particular in the case of LBS-based Apps, the GPS receiver) in order to be clear about the quality of information that is being captured. For example, calibration (as described for NoiseTube, Maisonneuve et al. 2010, and EveryAware WideNoise, EveryAware 2012) of microphones for noise measurement is important—such microphones are optimised to the frequencies used in normal speech, filtering ambient sound, and in addition may vary from device to device.

6 Conclusion

The range existing of Apps (both bespoke and generic) listed above highlights the importance of Location Based Services for Citizen Science and Community Mapping, and facilitating the use of such Apps can help policy makers as well as citizens, due to the resulting combination of residents’ local knowledge and first-hand experience with recommendations from professional scientists (Coburn 2005). Both areas of research and engagement are focussed on the needs and requirements of the general public rather than of specific research groups within an academic environment. They are thus well placed to take advantage of the overall growth in uptake of Smart Phones, and to make use of the wide range of existing functionality these phones offer over standard mobile devices. Having a flexible App created specifically for a single project allows these end users to set the scientific agenda rather than (as is done with Project Noah, EveryAware WideNoise, NoiseTube) than just to participate more passively as data collectors. Giving the Citizen Scientists and Community Mappers the flexibility to define the specifications of the tools they will use will also help to move research towards the top of the Citizen Science ladder of participation proposed by Haklay (2012—where the lowest level limits the participants to one way data collection via sensors, higher levels increase their involvement in the project by increasingly participating in problem definition and at the highest level–collaborative science—they are involved in collective problem definition, data collection and analysis as full partners with the ‘scientists’.

We conclude, however, with a note of caution—making use of the location-based technology described in this paper does indeed help to progress the work of Citizen Scientists and Community Mappers. However, in the United Kingdom, only a third of adults use Smart Phones (of any brand).¹¹ This means that fully two thirds of the population are excluded from using location-based technology on such devices. This is even more the case in locations such as the Congo basin. The second-level digital divide (Hargittai 2002 ) should also be considered—people may have access to the required devices, but may not have the skills to interact with the Apps. When designing any Citizen Science or Community Mapping project, it is important, therefore, to use a range of tools and activities, from highly technical location based services to very low technology such as diffusion tubes or wipes for pollution measurement or post-it notes on paper maps for perception mapping. This, at least in part, will help to ensure that such projects reach a maximum number of participants with all levels of skill and interest.