Design of a Generic Mobile GIS for Professional Users

Abstract

There are multiple location-based services (LBSs) and mobile GIS available for a wide range of applications. Usually such applications are developed to solve a restricted task within a restricted environment. The focus on a particular task is strong, and therefore, such applications can usually not be used in multiple environments. To overcome this issue, this paper presents a concept of a generic professional mobile GIS with a focus on interoperability. Firstly, common issues of mobile applications are presented, and their impact on the development of mobile GIS is analyzed. Subsequently, a new approach for a generic mobile GIS for professional users is presented. Based on multiple OGC standards, the approach leads to a system that can be used in various applications where the quality of surveyed data and analysis capabilities are improved. To prove the strength of the approach with GeoTechMobile, a prototype is presented and evaluated in a case study.

1. Introduction

Mobile computing has made large strides within the last 10 years. With the announcement of the iPhone^® in 2007, the development of high-performance and user-friendly mobile devices dragged enormous attention. Especially with the launch and opening of Android^® as an open-source mobile operating system at the Google I/O 2008, the availability of smartphones and tablets reached a new level [1]. In 2014 there were about 2.4 million activations of Android devices every day, while the performance gap between such a device and a regular PC reduces [2].

Not only the performance has increased constantly, but also the handling of mobile applications has been supported by improved user interfaces. The usual input device changed from a pen, as they were used for PDAs, to natural inspired touch gestures. Therefore, it is no longer necessary to use an extra input device such as a pen or an external keyboard. There are multiple sensors built in most mobile devices, for example, a GNSS sensor (supporting GPS, GLONASS, BeiDou and Galileo), a proximity sensor, a gyroscope, a compass, a barometer, an accelerometer, an ambient light sensor and a step counter, in addition to an octa-core CPU and a dedicated GPU, can usually be found in a modern smartphone [3]. Obviously, mobile GIS must take advantage of this development, which has an enormous potential to enhance the fieldwork of professional survey activities [4]. A generic mobile GIS must be able to handle multiple different tasks in multiple environments. To solve this task, it is necessary to review the purpose of various mobile GIS and LBS applications.

Currently there are countless LBSs and mobile GIS applications available for a wide range of applications. The border between an LBS and a mobile GIS application is fuzzy. Therefore, a definition of a mobile GIS application with a precise set of requirements is proposed in Section 3. Although there is mainly one main task for mobile GIS and LBS applications, namely to visualize and survey spatial data, there are different highly specialized mobile GIS and LBS applications available. Most of the LBS applications are designed to support the user in one specific task. This implies several applications which often differ only in a nuance. The fixation on a particular task is strong and usually such applications cannot be used within a different application or data infrastructure. Another issue refers to the quality and consistency of the data to be surveyed, which is a big challenge for the survey of spatial data [5]. The post-processing of vague or invalid data can increase the workload or even disturb automated workflows. In comparison to users of most LBS applications, a professional user of a mobile GIS application expects a tool to alter and survey consistent geodata for his own data infrastructure.

To address these issues, a concept for a generic mobile GIS for professional users with a focus on interoperability, reusability and consistent data is presented in this paper. Firstly, the particular issues of mobile applications in general and their impact on the development of mobile GIS are analysed. Subsequently, prior work on mobile GIS and LBSs is presented, and the addressed problems are discussed. Afterwards, a new concept of a generic approach for a mobile GIS, which is based on the combination of several OGC standards, is presented in Section 3. Subsequently, the mobile GIS prototype GeoTechMobile, an evolution of GeoTab [6,7], is presented as a realization of the concept in Section 4. A case study with GeoTechMobile at the State Agency for Spatial Information and Rural Development Baden-Württemberg (LGL, branch Karlsruhe) is presented in Section 5. Finally, conclusions and an outlook towards future developments are given.

2. Previous Work

Most of the prior work on mobile GIS work focuses on LBS applications that are available in different commercial application markets for smartphones and tablets, for example, Apple App Store, Google Play. Various questions are processed such as “where is the next supermarket, cinema, bar or hotel?” Usually such applications provide additional information about how to get there by offering direction instructions and a matching path on a map; there are several examples of research such as [8,9,10,11,12]. Fernando et al. developed a framework for the development of LBS based on OGC Web services [13]. Thus, such an LBS became interoperable and independent of a certain software. Usually, LBSs are developed to answer location-based queries and provide a location-based decision support. Internally, such applications use GIS analytic functions, spatial queries and map visualisation techniques. Raubal describes in [14] how such applications affect our mobile life.

When comparing conventional desktop applications with mobile applications, the capabilities of the device, input methods, screen size, network connection and a completely different user interface are some of the key differences [15,16]. Additionally, a mobile application can use the potential of various built-in sensors. In most smartphones and tablets, multiple location-based sensors such as a GNSS sensor, a gyroscope, a compass and an accelerometer can be used by a mobile application [3]. Such devices can additionally be coupled with external sensors without restricting the users’ mobility [9]. Therefore, mobile GIS applications have a different set of issues to address compared to conventional desktop applications [15,16,17], and others have developed guidelines and procedures for the development of mobile applications to address such issues. This results in further important implications for development of mobile GIS, as shown in Figure 1.

The implications for the development of mobile GIS include a focus on efficient algorithms and data handling to reflect on the limited resources that are available on a mobile device. Due to the smaller screen size and different input methods, in comparison with a desktop PC, an appropriate user interface must be available. When working with mobile devices, an unstable network connection is to be expected and an offline option with an appropriate synchronisation must be developed. Mobile GIS applications should use integrated sensors of mobile devices such as a GNSS sensor.

One important group of applications that are frequently used on mobile devices are web applications. Such applications are designed to run on multiple kinds of devices, for example, desktop PC, tablet or smartphone. Therefore, such applications need to satisfy different sets of requirements with the same software basis [17]. Once implemented, such applications are platform independent (Windows, Linux, iOS) and offer an adaptable user interface, which can be used in different situations. Such web applications are often useful for lightweight applications that work on mobile and desktop devices simultaneously. More complex mobile applications have the ability to perform heavy tasks on the server-side. Important drawbacks are the requirement of a stable network connection, a loss of performance and fewer opportunities of using the capabilities of the particular device [18,19]. Such drawbacks can be avoided by a native application.

One important aspect for mobile GIS applications is a suitable user interface. Raubal and Panov describe a formal conceptual model for an automatic mobile map adaptation which is supposed to reduce the cognitive load for the user of such applications [12,20]. An abstract model called the Adaptation Model to reduce the amount of information visible to the user at a particular time was established [21]. A mobile GIS application must provide an adapted arrangement of buttons and other suitable input possibilities to support a professional user in current tasks. Previous work done in this field focuses on the reduction of the cognitive load for the user to finish a certain task [15,22,23]. A responsive design can support the layout within the realization of the final application.

The main task of professional mobile GIS is to visualize, survey and alter spatial data, including attributes and metadata. Due to the mobile aspect, such features are no longer limited to a fixed environment [24,25]. One early example of a mobile GIS application is CoMPASS (Combining Mobile Personalised Applications with Spatial Services) that uses a multi-modal interface to provide a more intuitive way of interacting with a mobile GIS by using voice recognition and gestures rather than a keyboard and/or a pen [22]. One of the addressed problems was the restricted display resolution and the sensitivity of the user interface for touch events. Nakayama et al. developed a web GIS framework for participatory sensing using mobile devices [26]. The developed prototype is based on Drupal and focuses on nonprofessional users. MAPDD is a mobile application that was particularly developed for surveying geodata on public transport. It is based on the mobile OS Android [11]. Another LBS application that is based on Android was developed by [16]. It focuses on a simple development approach for an application about the locations of classrooms.

Additionally, there is a variety of professional GIS applications available such as Cadenza, ArcGIS or Q-GIS. Some are specialized for mobile operations, for example, Cadenza Mobile or ArcGIS for mobile. Desktop GIS such as Q-GIS can also be used in the field using a tablet PC. The latter cannot profit from the development of modern smartphone- and tablet-based user input methods, for example, multi-touch gestures. The others lack a generic approach or lead to a vendor lock-in and work only within a specific software suite [6,27].

3. Concept of a Generic Mobile GIS for Professional User

Due to the demand for an open and generic approach of an application-independent mobile GIS for professional users, this paper presents a new concept for such a software. In a first step, a definition of a generic mobile GIS is presented. It is stated that mobile GIS applications for professional users need to solve the following tasks to alter and survey consistent geodata for their own data infrastructure:

• Visualization of spatial data, including highlighting, generalization, symbolizing and so on.
• Integration into an existing geodata infrastructure to exchange spatial data (with appended attributes and metadata) bidirectionally, to be capable of surveying and altering spatial data.
• Support of a large set of different applications such as public transport, surveying of vegetation, land registry and other scenarios where it is necessary to visualize and/or survey geodata (with and without attributes and metadata).
• Arrangements/precautions to avoid corrupt input for a consistent spatial data stock.

The main requirements of a standardized mobile GIS for professional users are a suitable user interface, an appropriate integration into an existing standard-based geodata infrastructure, and the potential to adapt the application to the users’ needs. To solve these tasks, it is necessary to have a closer look at the data model, the process of exchanging spatial data and the user interface with its capabilities of interpreting the user input. Thus, for a generic mobile GIS for professional users, the use of the following concepts is proposed:

• A standardized generic visualization and symbolization for raster and vector data by following the rules of OGC Styled Layer Descriptor (SLD) [28].
• A standardized and conventional spatial data communication following the INSPIRE guidelines [29] by the deployment of the OGC Web Services Web Map Service (WMS) [30] and Web Feature Service (WFS) [31].
• The use of application-dependent templates to alter and survey various kinds of spatial data including attribute data and metadata based on the OGC WFS-T (transactional) concept.
• The Simple Feature Access (ISO 19125) standard as a basic and popular spatial data model [32].
• The OGC WFS-T concept to ensure that only predefined and suitable data can be surveyed.
• The OGC WFS-T locking mechanism for a multiuser support.
• The OGC Web Processing Service (WPS) [33] to provide the ability of handling advanced analysis operations.

The user of a mobile GIS application expects a visualization with a clear focus on the current workflow and the spatial data that is involved. There are two options to achieve an adaptable and generic rendering: Either the mobile GIS application itself takes control of a suitable visualisation of the spatial data, or this is handled by using the concept of Styled Layer Descriptor (SLD). The second option obviously is the most generic one, but is also more challenging, since the mobile GIS application needs to interpret these SLD files. As the mobile GIS application should be as generic and adaptable as possible, it is recommended to use SLD files for the visualisation of spatial data within a mobile GIS application. Whenever the purpose of a mobile GIS or LBS application is to visualize spatial data in a certain way, it is likely that the use of the SLD concept can solve such a task. Due to the SLD concept, it is possible to affect the appearance of raster and vector-based geodata in a mobile GIS or LBS application in several ways, for example, colour, size and symbolization.

To interact with multiple data sources, it is recommended to use one of the most disseminated communication concepts for the exchange of spatial data: OGC Web services. These web services, especially the Web Map Service (delivering prerendered geodata in form of tiles, for example, for a base map) and the Web Feature Service (handling vector-based geodata, for example, points, lines and polygons) are widely used and tested in various application scenarios. Due to the realization of the INSPIRE directive within the European Union, such web services are still extending. To maximise the coverage of possible sources for geodata, the two web services WMS and WFS should be implemented.

The ISO standard 19125 (Simple Feature Access) defines basic geometries such as points, lines and polygons, and is used as a data model in several GIS software products. In combination with the OGC WFS-T, these enable a wide range of possible applications for a mobile GIS. An overview of the requirements of generic mobile GIS and related appropriate concepts is illustrated in Figure 2.

Once the mobile GIS needs to handle additional information, for example, metadata or attribute data of certain spatial objects, such information is queried in a standardized way by a WFS. For such tasks, the getFeature operation of the WFS concept is applied to solve queries such as “is this building a fire station?” or “what type of tree do we have here?” Most of the information is available for such objects and is provided by a datahub. Due to these web services, it is possible to access additional information about spatial objects in a prescribed generic way. The mobile GIS application processes the query and visualizes the result. Some queries can be calculated on the server using the WPS, for example, to answer queries of the type “calculate the area covered by this certain object”. This approach leads to a generic solution for various kinds of spatial analysis operations.

When it comes to surveying new spatial data, there are several constraints that must be considered: usually the user intends to store additional data as metadata (for example, estimated accuracy = 3 cm) and attribute data (for example, type = tree, height = 8.2 m) in combination with spatial data. The concept of the Web Feature Service transactional (WFS-T) can fulfil these needs for points, lines and polygons (with and without holes), which cover most of the application areas of mobile GIS. The mobile GIS application itself needs to provide a suitable template form for the user. Following the WFS-T concept, all templates for specific spatial data are predefined before the user works in the field. This may seem to be a disadvantage at the first sight due to less flexibility for the user, but it is a huge advantage to achieve consistent spatial data. The number of input errors (wrong data type, misspelled names and so on) is reduced significantly. Due to the use of the WFS-T concept, the data surveyed by the user is in a consistent state. All attribute names are predefined by the indoor services and have an equivalent on the data server. The indoor services or the user itself can define the attribute types including the parameter values in the office instead of doing it in the field. Following these rules, typical errors such as spelling errors or invalid parameter values are avoided. Such a template can be defined by multiple GIS software products, for example, PostGIS (PostGIS—an open-source geodatabase, based on the object-relational DBMS PostgreSQL: http://postgis.net) or QGIS (QGIS—an open-source GIS: http://www.qgis.org). Figure 3 illustrates the workflow between the indoor service (office) and field users.

One key functionality for mobile GIS is to extend or alter existing geodata, that is, the spatial data itself or its attribute and metadata. To achieve this, the rules of the locking mechanism of the WFS-T are followed. Therefore, it is possible to establish a lock on certain spatial data for a specific amount of time. Within this time, only the system/user that allocated the lock can alter the data. This concept is used to alter/update either the spatial data itself or the metadata or attribute data [28]. It also sorts out multiuser issues by prohibiting other users from acquiring a lock for the same area.

4. Implementation of GeoTechMobile

The implementation of GeoTechMobile is based on the predecessor GeoTab [6,7] and is a prototype realization of the concept for a generic mobile GIS presented in the previous section. The software is completely written in Java and was developed for the Android platform. The structure of the implementation is separated into four different modules:

• MainUI—user interface and project design.
• Transaction—querying and transferring spatial data.
• Data handling—handling spatial data on the device itself.
• Visualisation—visualisation of the spatial data.

The first module provides a general project design for different applications. The user can specify a project name, a reference system, and multiple WMS and/or WFS servers. Such information is mainly handled by the classes ProjectHandler and ServerHandler. The second module mainly consists of the packages wmsHandling and wfsHandling. In these packages, the specific web services (WMS, WFS-T) queries are invoked. Every project can work with multiple WMS- and WFS-based layers. In most cases, a WMS layer defines the base layer of a project. On top of such a base layer it is possible to have multiple feature layers, that is, vector-based spatial data. A query session starts with a getCapabilities request to retrieve important information about the server itself and the available set of layers. The user chooses a specific layer and either a getMap (for WMS) or a getFeature (for WFS) request is generated in the WMSLayerImportQuery and WFSLayerImportQuery class, respectively. The request is transferred by the WMSLayerImport or WFSLayerImport class and the queried spatial data is handled by the data handling module.

The third module handles the underlying database, which is SQLite in this implementation. Therefore, the package dbHandling not only stores all project-based information (project-relevant metadata, server URLs, and so on), but also matches the queried vector-based feature layer into the database. Due to this approach it is only necessary to query the templates once. Afterwards, it is possible to work offline. To avoid multiuser issues, the layers can also be queried with a LockFeature query type; this implies that this functionality is supported by the server.

The visualisation module handles the drawing of the present spatial data and is mainly implemented in the class DrawingPanelView, where at first a base map is drawn on the main frame of the user interface, as shown in Figure 4.

The user can either query WMS tiles or use a preassembled base map based on OpenStreetMap data. For the latter, the free and open-source (FOSS) library osmdroid is used. The vector-based feature data is drawn on top of the base map. The basic geometries are internally handled by the FOSS library JTS Topology Suite. The actual sequence of vector layers can be adjusted by the user. The module visualisation frequently interacts with the modules Transaction and Data handling, that is, all changes of the map, for example, zooming or panning, are causing queries to update the base map and the vector data. The data of both types is stored in the internal database, that is, a relational SQLite database with a capacity corresponding to the available internal storage of the device.

Once the user has selected the appropriate layers and the template, it is possible to alter existing data and survey new data. For this purpose, the user can select existing data on the device and then modify vertices and attributes. Alternatively, he can draw appropriate geometric data types (depending on the respective template) on top of the background map by, for example, successively adding the vertices of a polygon. Afterwards, the user is shown a template mask to enter corresponding attributes. Firstly, all changes are available offline on the device, but can be transferred to the data-server at any time using a mobile data connection. An overview of the system design is shown in Figure 5.

The final prototype of GeoTechMobile runs on a Sony Xperia Z^® tablet, containing a GNSS (GPS + GLONASS) sensor, WiFi and LTE capabilities. Thereby the user can self-locate easily in almost any environment, and send and query spatial data where WiFi or a mobile network is available. With GeoTechMobile running on the Sony Xperia Z^® tablet, a portable mobile GIS based on the Android operation platform was developed, as shown in Figure 6.

5. Case Study: Surveying with GeoTechMobile

GeoTechMobile, the prototype of the concept for a generic and application-independent mobile GIS, was used by the State Agency for Spatial Information and Rural Development Baden-Württemberg (LGL, branch Karlsruhe) for surveying spatial data in different use cases [24]. The geodata infrastructure setup for this surveying work was built up as follows:

• PostGIS—the internal datastore for handling the spatial data on the server. Used for the management of the surveyed data and as a storage for multiple vector layers.
• GeoServer—a java-based data server with the capability of handling WMS/WFS requests and SLD files. It is a free open-source software that connects well to a PostGIS database.
• QGIS—a popular open-source GIS desktop client for the use within the office.

One important reason for the choice of these software products was the usage of open standard-based software, which is widespread and frequently used in the GIS community. Due to this geodata infrastructure, it was possible for the LGL to create templates in the QGIS desktop client for their surveying purposes. One of the applications was the surveying of agriculture and forestry data. Therefore, in QGIS, two layers were built: AD_feld and AD_forst representing the two classes agriculture and forestry, respectively. Both were subsequently integrated into a PostGIS database. The GeoServer was used to publish two correspondent layers AD_feld and AD_forst. Both layers were used as templates on the mobile device. Such templates specify the attributes of the data to be surveyed. An overview of the AD_feld template is shown in Figure 7.

In the field it was possible to use the GNSS sensor as a location and to display already existing data on top of a base map. Due to a mobile network, it was possible to query the base map directly from the GeoServer. Alternatively, it is possible to use an offline version of the base map and the templates, which can be transferred to the tablet via WLAN in the office before the start of a surveying session.

For the survey of new items, the user uses one of the layer categories, that is, agriculture or forestry. Subsequently, the user is able to create new polygons via GNSS locations gathered by the device or by manually inserting vertices on top of the base map. The accuracy of the GNSS sensor of the device used in this case study is approximately 5 m and was sufficient for this case study. In most cases, the background map was used as a reference for new objects. It is also possible to alter attribute values of already existing objects, for example, alter the cultivation of a field. For this purpose, the user selects a feature, for example, a polygon, and reviews the current data of the spatial object. Within a mask, the user is able to alter any available attribute directly on the device. In such a workflow, the GNSS sensor is used only for a rough localisation on-site. Figure 8 shows the handling of GeoTechMobile during the study.

Due to the usage of the WFS-T locking mechanism, the user needs to specify a lock period when querying objects if an update of the objects is intended. For a better usability, a standard time of 24 h is chosen automatically. After creating or altering objects, it is possible to transfer the changes to the GeoServer via a mobile network. It is also possible to store the data internally in a SQLite database and to send them to the GeoServer via WLAN, for example, after returning to the office. In both cases, the data consistency is preserved due to the use of WFS and the WFS-T locking mechanism, respectively.

6. Conclusions and Future Work

In this paper, a concept for a generic and standard-oriented approach of a generic mobile GIS for professional users was presented. In contrast to a specialized system that is suitable for only a specific application, it is possible to use the presented approach with different templates for various applications. The implementation of the generic concept resulted in the software GeoTechMobile and was successfully tested within a first case study. The device used in the case study has a GNSS sensor with an approximate precision of 5 m. This was sufficient for the present case study but could be insufficient for different applications. The use of additional sensors such as an external GNSS receiver could improve the positioning.

Due to the usage of open standards, it is possible to work with a wide range of software products. Common geoservers provide the support for web services such as WMS or WFS. Thereby, it is possible to avoid vendor lock-ins and adopt the mobile GIS easily into an existing infrastructure. In future research it is intended to improve the human–computer interaction due to the evolution of smartphones and tablets with a focus on mobile geo-applications. It should also be considered to transfer workflows of a mobile GIS application to a desktop GIS application user interface. The analysis capabilities of mobile GIS applications must be further examined. Here, the proper use of a Web Processing Service is helpful and will be integrated into GeoTechMobile. Currently, the WFS-T locking mechanism is used to handle multiuser issues, thus a single user can allocate a template for a specific amount of time. To deal with versioning and concurrent users, the concept must be extended. The presented case study represents a classic task of a surveying authority. The generic aspect of the mobile GIS allows it to be used in a wide range of applications, such as smart cities, eTourism, and intelligent transportation systems. A professional mobile GIS might also integrate complex workflows such as the organisation of rescue services in a case of an emergency. These aspects require further investigation.