EnviroInfo 2012: EnviroInfo Dessau 2012, Part 1: Core Application Areas Copyright 2012 Shaker Verlag Aachen, ISBN: 978-3-8440-1248-4
Geospatial Service Interfaces and Encodings for Mobile Applications Denis Havlik, Peter Kutschera, Clemens Geyer, Maria Egly 1
Abstract Sensor Web Enablement suite (OGC SWE) offers a set of standardized service interfaces and data models which can be used for encapsulation of arbitrary observation-generating processes. In the past, AIT has used the OGC SWE for wrapping of hardware sensors, sensor data stores, cadastres and various sensor-like models behind OGC Sensor Observation Service (for data access) and Sensor Planning Service (for process control) interfaces. This approach was successfully applied in different projects (SANY, SUDPLAN), and resulted in development of the SOS and SPS service interfaces for the set of open source tools for time-series handling (ts-toolbox.ait.ac.at) developed by AIT. We have also discovered several issues and limitations of the OGC SWE services: (1) encoding of observations in SensorML/SWE Common is not always straightforward; (2) XML encoding/decoding can become extremely inefficient for large data sets; and (3) the complexity of the OGC XML schemas (O&M, SWE common, GML) further slows down the SWE-based solutions. However, these issues appeared of secondary importance compared to benefits of interoperability for classic environmental applications where both server and the client had plenty of memory and CPU power, the observations and processes creating them are well-defined and do not often change, and the interoperability across different organizations is a must. Recently, our focus moved towards Volunteered Geographic Information, and the rules of the game changed, with (potential) numbers and profiles of users and “sensors” drastically rising, and smartphones replacing the classical PCs as key client platform. This resulted in development of a Mobile Data Acquisition Framework (MDAF) which will be described in this paper.
1.
Introduction
Information and Communication Technology (ICT) for environment is widely recognised as one of the key enablers for sustainable development and improved quality of life (ICSU 2011, Hřebíček 2011). ENVIROFI research project, which started in April 2011 as one of the eight Usage Area (UA) projects within the “Future Internet Public Private Partnership” (FI-PPP) FP7 programme aims to assure the environmental data and services are easily accessible and usable through ENVIROFI Specific Enablers (SE) in the future internet applications (Havlik 2011, Havlik2011b). In this context, special attention is given to the “technology triangle” with observations from sensors, humans and models (Figure 1). Our previous experiences with the Sensor Web Enablement (Usländer 2009) clearly showed that the observations from classical in-situ and remote sensors, as well as those from models can be adequately handled by services and data encodings of the Open Geospatial Consortium’s “Sensor Web enablement” (OGC SWE) suite of standards. However, the OGC SWE has so far not been widely accepted for mobile applications and citizens’ observatories and our own analysis confirmed the doubts that the SWE standard currently does not fulfil some of the basic requirements imposed by technology and organisational constrains of the citizen’s observatories. Following section analyses some of the reasons for this failure.
1
AIT Austrian Institute of Technology GmbH, email
[email protected]
Figure 1 Technology triangle: observations from sensors, humans and models (from Havlik 2011).
2.
Requirements on the “citizens SWE”
The OGC SWE (Bröring 2011) is conceived as a very generic solution for all types of observations, mainly targeting the interoperability between data centres. In our experience, the OGC SWE proved the most valuable if: (1) the interoperability is important enough to warrant the somewhat complex process of observation and process modelling; (2) the observation methodology is well-defined and the observation model does not change very often; (3) the results must be re-usable and comparable across administrative and domain borders – for years and years to come; and (4) the SWE services are mainly used in the data centre, where sufficient computational power and network connections can always be assured. Quite often none of this is true for the citizen’s observations where budget and time constraints play a much bigger role, data models evolve over time and the application “owners” aren’t bond by legal requirements for sharing the results in an interoperable form. As a consequence, the cloud centric platforms such as Cosm (https://cosm.com/) or Cumulocity (http://www.cumulocity.com/) have experienced explosive growth, with OGC SWE playing only a marginal role in this market segment. These platforms typically provide only a small subset of the SWE functionality, but the functionality they do provide is exposed using very simple APIs and in some ways more robust than in the SWE. For instance, Cosm automatically limits the amount of data returned by the system while OGC Sensor Observation Service (SOS) does not foresee a standard mechanism for this purpose. In addition, these platforms automatically provide some simple visualization methods. As a result, even the most inexperienced developers can quickly develop applications and visualize the observations in tables, line graphs or on a map. Main issues: • The APIs, data model and naming conventions vary from provider to provider. Consequently, the applications cannot be easily ported from one platform to another. • The resulting data often lack most of the meta-information foreseen by the SWE standard such as process description, quality or uncertainty.
Copyright 2012 Shaker Verlag Aachen, ISBN: 978-3-8440-1248-4
In addition, the informal technology tests we performed in late 2011 have confirmed that the smartphone applications need to be optimized for robust and efficient network use, in order to cope with slow, expensive (e.g. roaming) and even completely ruptured (white spots, network overload) connections as well as for processing, memory, and especially power consumption, as these are all in short supply. In addition, the user interface design has to be adapted to mobile devices with small multi-touch screens and a multitude of sensors (camera, acceleration, NFC). Finally, we also noticed that XML parsing and validation of complex XML schemas used by OGC SWE can slow down mobile apps to a crawl, while simple RESTful service interfaces and JSON encoding assure much better user’s experience. These findings have led to development of the Mobile Data Acquisition Framework (MDAF) prototype which will be introduced in the next section.
3.
Overview of the MDAF Architecture and Underlying Technologies
Mobile Data Acquisition Framework (MDAF) is the mobile observation gathering, processing, storage and presentation platform developed by AIT within the scope of ENVIROFI and FI-PPP programme. The ultimate goal of the MDAF development is to simplify conduction of arbitrary “experiments” involving: (1) gathering of observations from (mobile) sensors and from humans; (2) quality assurance and processing of these observations; (3) visualization of the results; (4) discussion and collective decision making. At the current development stage, we focus on humans using small mobile devices (e.g. smartphones) for observation gathering. These observations can be either objective, as in “here and now I see a forest fire”, or subjective, as in “this street is too noisy” and can be accompanied with measurements made through built-in and external sensors (photographs, sound recordings, temperature, pressure, etc.). In order to meet the first two targets, we opted for a 3 tier application design illustrated in Figure 2 below:
Figure 2 MDAF Architecture
Copyright 2012 Shaker Verlag Aachen, ISBN: 978-3-8440-1248-4
The tier 2 service (MDAF Server) has a role of coordinator linking the users and their mobile devices with the tier 3 mobile applications (MDAF App). MDAF server component also provides application-specific views to observations, as well as interfaces for configuration and use of the data processing functionality of the tier 3 services which are presented as grey boxes on the right-hand side of Figure 2. Based on our previous experiences with OGC services and existing support for Sensor Observation Service (SOS) and Sensor Planning Service (SPS) in TS-Toolbox, our initial intention was to rely on SOS and SPS for all data (observation) access as well as for the process triggering and configuration respectively. Alternative views to data could then be provided using the OGC WCS and/or WFS interfaces, and the issues with inefficient data encoding/decoding could be solved through provision of binary data using e.g. WebDAV and NetCDF. While these considerations still hold, implementation of these interfaces has been postponed in order to satisfy the following specific requirements of the tier 1 (mobile, smartphone) application: • Asynchronous uploads: as a consequence of the network related issues mentioned in the previous section, transferring new observations from user’s mobile device to a tier 2 server may not be always desirable or even possible. MDAF tier 2 service must therefore accept both synchronous and asynchronous uploads as well as to allow partial uploads of the observations (e.g. uploading of the photos could be only allowed over WLAN connection). • Pre-fetching and synchronization: in order to allow offline usage, or at least to assure the adequate user experience in spite of the slow or unreliable network connections, MDAF must provide a lightweight observation access service with prefetching/synchronization of the data between the mobile device and the tier 2 service. • Proxy for tier 3 services: in order to lower the processing needs and complexity of the smartphone application, the tier 1 application should not directly connect to tier 3 services. Task of interfacing to external observations sources, interpreting, mashing and presenting them in appropriate way is thus delegated to tier 2 services. • Notifications/Alerts: since humans aren’t good at performing repetitive tasks, the MDAF system must provide a mechanism for soliciting the users input. This mechanism must be designed in a way which will minimize the number of requests presented to users and work even in the case the MDAF client application hasn’t been activated. MDAF server component must also generate the events of interest to the tier 3 services, but actual processing and dispatching of events to users and services may be outsourced to dedicated event and notification tier 3 service(s). • Collaborative offline mode: ideally, the users should be able to exchange observations over local network without relying on the availability of the central tier 2 service. This could be implemented either in full peer to peer fashion, or with help of a local instance of the MDAF server. This is particularly interesting for crisis management and other applications which require real time exchange of information among the field workers. In order to meet these requirements, we developed a lightweight and cellular-phone friendly “MDAF Server” observation service and a corresponding mobile application.
3.1
MDAF Server Design
MDAF Server component is the central component of the MDAF application. It provides a data storage facility for the user-contributed observations, as well as the pre-fetching and caching facility for the observations from tier three services and assures the observations required by the user are synchronised to its device as needed. In addition, the MDAF server component also implements most of the application logic through provision of the application-specific views to observations, generation of application-specific events and tier tree service execution. The synchronization of observations, as well as the rights management is simplified by three-level database design illustrated in Figure 3 below.
Copyright 2012 Shaker Verlag Aachen, ISBN: 978-3-8440-1248-4
Figure 3 MDAF Data storage and replication The central database (DB) instance contains all observations relevant to MDAF users. Some of these are generated by MDAF users or by application-specific tier three services, while others may be only prefetched from external sources and temporarily cached by MDAF to improve the user’s experience. Application-specific server-side synchronization process assures that observations relevant for a particular user are available in the user-specific server-side database and a much simpler replication process assures the same data is synchronized to a DB instance residing on the user’s mobile device. New observations are always synchronized in a controlled manner to the global observation store and to the observation stores of all users who are interested in these observations and allowed to use them. This happens without delay if the user is online, or asynchronous at a later time in case the network connection is slow, broken or simply too expensive. This design has been chosen for several reasons: • First, the DB instance on the mobile device minimizes the network traffic and assures the mobile application can work in offline mode. • Second, the user-specific databases on the server side simplify client design and prevent mischievous users from overriding the database right management mechanisms. • In addition, the server-side synchronization between users DBs and the central database provides a convenient way for triggering events and starting external processes required by application logic. • Finally, this design simplifies scaling to a large number of users, as user-specific database instances can be easily distributed to separate (virtual) machines. Obviously, the usability of the MDAF system will heavily depend on the reliability and flexibility of the database synchronization. Fortunately, we were able to delegate this issue to third party developers through use of the CouchDB as storage engine. This noSQL database can be used on Linux, Windows, Android and IoS operating systems and features a very powerful synchronization mechanism assuring the “eventual consistency” of the data (Anderson, 2010). Compared to SQL databases, the CouchDB provided several additional advantages for the MDAF development: integrated web server, RESTful interface, op-
Copyright 2012 Shaker Verlag Aachen, ISBN: 978-3-8440-1248-4
timized for working with JSON and GeoJSON, highly scalable, database schema easily modified at run time. The data model used in MDAF server is based on the abstract observation model of the OGC O&M 2.0 (Cox, 2010), and takes into account following technical limitations: 1. CouchDB is optimized for storing of the related data in a single “document”. 2. MDAF heavily relies on external processes reporting additional observations on the previously reported ones. For instance, a leaf recognition service is expected to provide a list of probable species in ENVIROFI “biodiversity” pilot (Schleidt 2012). 3. The position of an observed object is usually reported as part of the observation, and therefore we decided to model it as observed property. As a consequence, we decided to store all observations collected simultaneously as one CouchDB document containing “related observations” and to interpret the OGC concept of the “feature of interest” (FoI) in a way which allows us to use any existing CouchDB document as FoI for the new observations. Practical implications of these decisions can be best understood on example of the ENVIROFI “tree” application. This application, allows the users to report their observations on various trees and view the already reported information: • All observations on a specific tree provided by a single observer on a single field trip (“sighting”) are stored as one CouchDB document. However, the sighting made by a different observer, as well as the follow-up sightings by the same observer on a different day would be stored in different documents. • All of these observations should point to a single document serving as a neutral “Feature of Interest” (FoI). It can be discussed if this document is really needed and whether it should contain any information except for the unique ID. In particular, it seems logical to assign a geo-location of a tree to FoI and even to use the location as the unique ID. Unfortunately, in most cases the location is just one of the reported observations and varies from sighting to sighting due to measurement uncertainty. • Each of these documents can in turn serve as the FoI for an observation stating that the leaf photo could belong to species X or that the reported specie indeed occurs in the region (habitat). This concept of “observation on observations” is somewhat unusual but appears to be allowed by O&M abstract specifications. • Finally, a special view to this forest of related observations can be generated for specific applications. In our “tree info” application, various probabilities provided by users and tier 3 services could for instance be merged in “most probable identification”, enhanced with “best of” user contributed photos and comments, and the result shown to the users.
3.2
MDAF Mobile Application(s)
MDAF server has been specifically designed to improve the usability of the smartphones for mobile observation acquisition. For now, the client-side development concentrates on the specific needs of the ENVIROFI “biodiversity” (Schleidt 2012) and “personal environmental information system” (PEIS) pilots (Kobernus 2012b), but our long term goal is to simplify the client development to the point where users can either generate the required mobile observation applications on the fly, or simply configure a generic MDAF App for their needs using a dedicated MDAF portal. With this in mind, the prototype mobile application(s) developed within ENVIROFI build on PhoneGap distribution of the OS-independent Apache Cordova framework (Leroux 2012), share much of the code and feature following pilot-independent capabilities: • Presentation of existing observations on a map and on a tabular form
Copyright 2012 Shaker Verlag Aachen, ISBN: 978-3-8440-1248-4
Filtering of observations Offline viewing and reporting of observations Waking up of the application by external alerts/notifications Using Near Field Communication (NFC) for things recognition (e.g. unique IDs for trees), for adding observations as well as for the user authentications. Capabilities of the current prototypes have been described in (Geyer 2012) and (Kobernus 2012). Both prototypes are in very active development and will be downloadable from the project web site (http://www.envirofi.eu/) in the near future. As soon as the applications have reached sufficient level of maturity, they will also be made available on the Google Play Store (https://play.google.com/store). • • • •
4.
Outlook and Conclusions
The Mobile Data Acquisition Framework presented in this paper aims to become a generic framework for collecting, processing and visualization of observations. In addition to providing a very useful set of features for applications relying on mobile observation collection, validation and visualization, MDAF attempts to bridge the gap between interoperability of the OGC SWE and the lightweight design of the IoT cloud services. This will be done on two levels: first through integration in the FI-PPP framework developed by FI-Ware project (FI-Ware 2012), and second through OGC standardization project. On the FI-Ware integration level, MDAF will use the FI-Ware generic security enablers for managing of users, rights and user related data as soon as these become available. In the later development, we expect to: (1) fully automatize the MDAF scaling using the FI-Ware cloud service management functionality; (2) assure the FI-Ware context management and IoT services can be used with MDAF through integration of the pub/sub event handling GE; and (3) assure the MDAF applications can be easily published on FI-Ware marketplace. On the OGC standardization level, it is important to understand that MDAF service interface for observation uploading and retrieval is technically quite different from a standard SOS. For the start, OGC-style web service interface was replaced by RESTful. JSON is used as default data encoding method instead of XML, and the service has been designed in a way which greatly simplifies both complete and partial replication and synchronization of the observation store across multiple instances of the service. In spite of these differences, the underlying data model closely resembles standard OGC observations model, and the standard SOS access to the observations is planned at a later development stage. While the details of the data model and service interfaces still need to be defined, we feel that the future of the mobile observations belong to MDAF-like systems. In order to assure the maximal interoperability between future MDAF-like solutions and those using the standard OGC SWE 2.0 data models and service interfaces, AIT has joined the newly formed SWE-IoT working group as one of the founding members in June 2012. Our intention is to (co-)define a standard JSON mapping for O&M and to develop one of the reference implementations of the future standard based on MDAF server component.
Acknowledgements The research leading to the result presented in this paper has received funding from the European Community's Seventh Framework Programme (FP7/2007-2013) under grant agreement n° 284898 (ENVIROFI).
Copyright 2012 Shaker Verlag Aachen, ISBN: 978-3-8440-1248-4
Bibliography Andreson, J.C., Lehnardt, J., Slater N. (2010). Time to Relax - CouchDB The Definitive Guide, O’Reilly, ISBN 978-0-596-15589-6 Bröring, A. (et al.) (2011). New Generation Sensor Web Enablement. Sensors 11(3). Cox, S. (ed.) (2010). Geographic Information: Observations and Measurements, Version 2.0, OGC Abstract Specification Topic 20 (OGC 10-004r3 and ISO 19156) FI-WARE (2012). FI-WARE Architecture and Open Specifications. Deliverable of the FI-WARE project, http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE_Architecture_and_Open_Specifications Geyer, C. B. (et al.) (2012). A Mobile Application for Tree Observations. In Proceedings of Greening the Forest Sector Engineering with ICT, Plitvice, Croatia Havlik, D. (et al.) (2011). From Sensor to Observation Web with Environmental Enablers in the Future Internet. Sensors 11 (4). Havlik, D. (et al.) (2011b). Leveraging the Future Internet – Public Private Partnership for the Environmental Usage Area. In Proceedings of EnviroInfo 2011, Ispra, Italy. Hřebíček, J., Pillmann, W. (2011) eEnvironment: Reality and Challenges for eEnvironment Implementation in Europe. In: Environmental Software Systems. Frameworks of eEnvironment, Proceedings of the 9th IFIP WG 5.11 International Symposium, ISESS 2011, Brno, Czech Republic. ICSU (2011) Scientific Grand Challenges identified to address global sustainability – ISCU prepublication, http://www.icsu-visioning.org/wp-content/uploads/GrandChallenges_ Klopfer, M., Simonis, I. (eds.) (2009). SANY - an open service architecture for sensor networks. ISBN 978-3-00-028571-4. Kobernus, M. (et al.) (2012). A Quest for Affordable Personalized Atmospheric Exposure, In Proceedings of EnviroInfo 2012, Dessau, Germany. Kobernus M., Pielorz J. (2012b). Functional and Organisational Specification for PIS Pilot II, Deliverable of the ENVIROFI Project (2.3.2). Leroux B. (2012). PhoneGap, Cordova, and what’s in a name? in PhoneGap blog. http://phonegap.com/2012/03/19/ Schleidt K. (ed.) (2012). Functional and Organisational Specification for Biodiversity Pilots II, Deliverable of the ENVIROFI Project (1.3.2). Usländer, T. (ed.) (2009). Specification of the Sensor Service Architecture, Version 3.0 (Rev. 3.1). OGC Discussion Paper (09-132r1).
Copyright 2012 Shaker Verlag Aachen, ISBN: 978-3-8440-1248-4
