According to Popescu (2012), the Geolocation API “defines a high-level interface to location information associated with the device hosting the implementation, such as latitude and longitude. The API itself is ignorant of the underlying location information sources. Common sources of location information include Global Positioning System (GPS) and location inferred from network signals such as IP address, RFID, WiFi and Bluetooth MAC addresses, and GSM/CDMA cell IDs, as well as user input”.

Geolocation based on GPS signals regularly involves two sources of accuracy error under field conditions: (1) local reflection of GPS signals from large objects like buildings or trees, that can be falsely recorded by the GPS device and (2) error in the signal emerging from variation in solar activity that distort the GPS signals as they pass through the Earth’s ionosphere. In the situation where large objects in the vicinity affect the accuracy of signals, the user can intervene by switching to an aerial photography background map and then directly assessing the accuracy by comparing the physical surroundings to what is shown on the aerial photo around the position indicator. Moreover, in such situations the application can be set to allow the user to manually position the data recording in the map. For the second source of error, correction services delivered by various commercial suppliers improve accuracy down to the decimetre or centimetre or centimeter level. Such correction information was once available only for advanced GPS receivers equipped with an additional radio receiver, as these correction signals were disseminated along FM-radio channel signals. However, in recent years, these correction signals have also started to be disseminated over the mobile telephone network. This new option was considered to be implemented as an additional functionality of Geoport, but would have required programming of an additional software module that is not part of the Geolocation API standard to handle the signal code. To obtain this kind of increased accuracy, users would be required to buy access to such services from national suppliers. Although we considered the availability of GPS correction signals within the mobile network signal to be an interesting new option, we decided not to implement support for it in the current version. For the purpose of recording field data on pests, the position accuracy of 3-4 meters typically obtained when the solar activity is the only source of distortion, was considered sufficiently accurate. The quality of the hardware and the positioning averaging algorithms implemented by the hardware vendor can also affect position accuracy. However, based on our experience with smartphones and tablets from different main producers, all current technologies provide adequate position accuracy. The Geolocation API itself has an optional parameter “enableHighAccuracy” in the set of instructions for position acquisition. This attribute is implemented in the API to provide a hint that the application would like to receive the best possible results. Another intended purpose of this attribute is to allow other applications to inform the Geolocation application that they do not require high accuracy geolocation information, therefore, the implementation can avoid using geolocation components (e.g., GPS) that consume a significant amount of power. For Geoport we chose to activate the “enableHighAccuracy” option by default in order to ensure that the device always provided the most accurate position it is able to deliver, although this results in the slowest response times and largest power consumption. One alternative not yet enabled in the current version of Geoport is to allow the user to switch on and off this “enableHighAccuracy” parameter, which in practice would mean to make more use of the manual placement option based on high quality aerial map background. However, this will break with some of the automatic quality control principles of this data collection principle where time and space attributes of the data recording could be set by the system without the user being able to manipulate them.

Based on our previous experiences with OpenGIS® Web Feature Service Interface Standard (WFS) we chose to design the Geoport web application to allow data recording against any data source supporting Web Feature Service Transaction (WFS-T). There are now several software products, both commercial and open-source based, supporting WFS-transactions (e.g. GeoServer, TinyOWS and ArcGIS Server) with most kinds of geographical data sources like file-based formats (e.g. ESRI Shape files) or database servers with support for geographic data types (e.g. PostgreSQL/PostGIS, Oracle Spatial, ArcSDE). In the following section, we introduce some of the technical principles to facilitate flow of species data records over the Internet, and furthermore, how eventually new data records can be used to trigger events like pest management actions or pest risk assessment re-analysis.

According to the OGC (Vretanos 2005), the OpenGIS® Web Feature Service Interface Standard (WFS) defines: “interfaces for data access and manipulation operations on geographic features using HTTP as the distributed computing platform. Via these interfaces, a web user or service can combine, use and manage geodata -- the feature information behind a map image -- from different sources by invoking the following WFS operations on geographic features and elements:

• Create a new feature instance
• Delete a feature instance
• Update a feature instance
• Lock a feature instance
• Get or query features based on spatial and non-spatial constraints”

A subset of the above described operations of the WFS specification has been named as Web Feature Service Transactions or WFS-T in abbreviated form. The subset of the first four operations listed above constitutes the necessary operations to allow for full editing functionality for geospatial data over the Internet. While the WFS provide the information behind maps, and no map images, the OpenGIS® Web Map Service Interface Standard (WMS) does provide map images that also could be transparent to combine map layers from one or multiple servers (de la Beaujardiere 2006). Also WMS uses the hypertext transfer protocol (HTTP) of the Internet, but here the role of the protocol is just to transfer images over the Internet similar to how photos appearing in a Web-based newspaper, but with the addition that they are accompanied by information on how the images could be arranged in a (geographical) coordinate system to present a geographical map to the reader.

In order to allow different functionality, we decided to implement two modes of operation of Geoport on two different network addresses. One mode allowed the user to control placement of field recordings on the map. In this mode, GPS information is used to centre the map on the device only and the geographical coordinates for data recording are captured where the user taps to insert a new data point. A second mode had no option for user interaction except from placement of the mapping device itself (smartphone or tablet) at the position of the point of interest. In this mode the geographical coordinates for data recording are taken directly from the GPS when a new data point is recorded. The former mode is desirable when positions of interest are difficult to access, e.g. in wetlands (bogs, lakes etc), while the benefit of the latter mode is that data are collected where the device is located.

A mapping session with the Geoport Web application initiates by starting up an Internet browser on the tablet or smartphone and then by entering the Web address. While there is no need for manual installation beforehand like for native applications, successful loading of the application requires network connection. After loading the application the user is asked to allow sharing of the geographical position. This is an integrated part of the W3C-geolocation specification to protect privacy. The user can respond to the request either by sharing the geographical location information once for the actual application session or for future application sessions or to not share the location information (for which the latter option prohibits the application from proceeding into a mapping session). In the mapping session previously registered data is shown by Style Layer Descriptors (SLD) on top of a background map (Fig. 1A) that could be switched between topographic or aerial imagery (orthophoto). The previously collected data shown in the map is coming directly as WFS data from the same data source as the data collection is operating. Background maps are delivered over a WMS service. To record new data, the user taps the “+” button which brings up a user dialog with predefined menu options for “type of registration”, “quantity”, “symptom”, “action taken” and a free text field for comments (Fig. 1B). The date and geographical coordinates are captured automatically from the device. The final action for the user to complete is to press “OK” which fires the WFS transaction. The WFS server then feeds back a message telling the user whether the data was safely secured at the server or not. The application returns to normal mapping mode at the current position.

This Web application, run from a tablet device, offered several advantages for field data collection over handheld GPS-devices or first generation smart mobiles without touch screen. Tablets have much greater battery capacity than mobile phones, and the battery will not run out during the working day. The relatively large screen on a tablet also provided a better overview of data collected and map information. Fine details in the high quality background maps and aerial imagery provided by the Norwegian Mapping Authority become evident on the larger tablet screen. The detailed information on surroundings and the good overview is helpful in the working situation. Use of the touch screen was also more convenient on the tablet compared to the smartphone because the symbols were larger and easier to tap (although this could be adjusted at the expense of visible map information).

Geoport can in principle be used anywhere in the world. It can be configured to use any background map layers as long as they are available over the WMS standard or the other Internet-based map distribution formats supported by the OpenLayers library. It has been tested in various parts of the world when configured to use map layers offered by Google’s Google Maps service. For use in Norway, we chose to use the map services offered by the Land Registry and Cadastre (STATKART) as they offer the highest quality maps and aerial imagery for Norway. Geoport is not publically accessible as it is now distributed as a commercial product from the private company Powel based in Norway. However, the software on which Geoport is based, OpenLayers, is publically accessible as it is published as an “open source” software library at http://openlayers.org.

The greatest use of Geoport so far has been in the on-going nation-wide survey and eradication campaign in Norway against the plant pathogenic bacterium Erwinia amylovora which causes fire blight in pears, apples and some other members of the family Rosaceae (Rafoss et al. 2010). In 2012, a total of 15, 458 host plant locations were inspected and mapped/remapped, distributed in 13 counties and 100 municipalities of Norway (Melbøe et al. 2013). In the survey all host plants were checked for symptoms of fire blight. The disease has not yet spread to the main fruit growing areas of Norway. The action taken depends upon which of the three zone status declared: “eradication zone”; “observation zone” or “protected zone”. An eradication zone is declared anywhere fire blight has been detected and all diseased plants are removed. As a preventive measure the most susceptible host plants are also removed. In the observation zone fire blight has not yet been detected. The observation zone borders the eradication zone, and the surveillance activity is systematic and extensive. In the protected zone, fire blight has not been detected and surveillance in this zone is at random.

The geoport application has also been successfully used at a smaller scale to register vascular invasive plants in Norway and to record data in agricultural fields in India.

In the context of risk assessment and risk management of pests, geospatial information standards that can facilitate development of new knowledge from collected species occurrence data should be of high interest. The various approaches and algorithms developed to project whether species can establish and spread into novel areas based on the species’ current distributions (see Elith and Leathwick 2009; Austin 2007 for a couple of reviews) are increasingly being compared (Elith et al. 2006; Dupin et al. 2011) or used in combination (Smolik et al. 2010). Furthermore, requests for early detection of emerging risks (EFSA 2011) as well as more robust predictions of pest establishment potential for novel areas can be expected. Automatic execution of species distribution models when new data are collected and multi-model operations, respectively, are approaches that could address these two needs. However, there is currently no existing service to tackle these challenges. This is where the OpenGIS® Web Processing Service (WPS) can play a role as a suitable standardization initiative. According to the specification of OpenGIS® Web Processing Service edited by Schut (2007): “WPS defines a standardized interface that facilitates the publishing of geospatial processes, and the discovery of and binding to those processes by clients. “Processes” include any algorithm, calculation or model that operates on spatially referenced data. “Publishing” means making available machine-readable binding information as well as human readable metadata that allows service discovery and use. A WPS can be configured to offer any sort of GIS functionality to clients across a network, including access to pre-programmed calculations and/or computation models that operate on spatially referenced data. A WPS may offer calculations as simple as subtracting one set of spatially referenced numbers from another (e.g., determining the difference in influenza cases between two different seasons), or as complicated as a global climate change model. The data required by the WPS can be delivered across a network, or available at the server. This interface specification provides mechanisms to identify the spatially referenced data required by the calculation, initiate the calculation, and manage the output from the calculation so that the client can access it”. Based on this definition, the WPS standard should have a potential to act as a framework for future standardization of the various modell ing approaches applied to predict the potential for pest establishment and spread. Analysis of geospatial data is commonly associated with some technical burden to handle coordinate systems and projections properly. Further technical complexity is included when the time dimension is added to the analysis of species occurrence data. If standards are used and supported by the tools for analysis and prediction of species distribution, the management and processing of such data could be eased, which will allow the biologist or pest risk analyst to concentrate more on advancing the science and less on overcoming technical barriers.

An earlier Norwegian study on the use of standardized information technology for risk management of pests, demonstrated the potential for chaining of Web-services for automatic warning messaging to be sent to potentially affected farmers and other stakeholders, based on events registered into a Web-client developed for the desktop office computer (Gyland et al. 2007). With the current tool for smartphones and tablet computers, this system is now in principle available for use from the field.

In a risk assessment context, server side routine checks could be set up on the in-coming pest data that could trigger pest risk analysis, or re-analysis, when the new data fulfil certain criteria identifying a potential emerging risk. The new abilities to constantly update field data could generate potential for a new level of immediacy not previously seen in the process of pest risk modelling. In order for this to be a new feature of the pest risk assessment process, risk assessment routines must be dynamically linked to the species presence/absence databases in a way that re-analysis could easily be invoked or even automatically triggered when new data are accumulated. If species distribution models were available as WPS services, we might experience similar effects of lowered effort needs following from of standardization as reported for field data collection in this article and by Rafoss et al. (2010).

Chaining (linking) species distribution models to species distribution databases by standards support may also further facilitate the step from assessment to management. Pest risk management procedures, e.g. emergency warnings and contingency plans, could be held up-to-date from risk assessment model based knowledge on range expansion of pests and associated scientific advice.