A Javascript GIS Platform Based on Invocable Geospatial Web Services

Abstract

Semantic Web technologies are being increasingly adopted by the geospatial community during last decade through the utilization of open standards for expressing and serving geospatial data. This was also dramatically assisted by the ever-increasing access and usage of geographic mapping and location-based services via smart devices in people’s daily activities. In this paper, we explore the developmental framework of a pure JavaScript client-side GIS platform exclusively based on invocable geospatial Web services. We also extend JavaScript utilization on the server side by deploying a node server acting as a bridge between open source WPS libraries and popular geoprocessing engines. The vehicle for such an exploration is a cross platform Web browser capable of interpreting JavaScript commands to achieve interaction with geospatial providers. The tool is a generic Web interface providing capabilities of acquiring spatial datasets, composing layouts and applying geospatial processes. In an ideal form the end-user will have to identify those services, which satisfy a geo-related need and put them in the appropriate row. The final output may act as a potential collector of freely available geospatial web services. Its server-side components may exploit geospatial processing suppliers composing that way a light-weight fully transparent open Web GIS platform.

1. Introduction

Geospatial functions range from simple image map acquisition to a complex geoprocess over a Spatial Data Infrastructure (SDI). Nowadays, a wide range of users exploit geospatial functions in their routine activities. Such users are practitioners, scientists and researchers involved in geosciences and engineering disciplines, as well as individuals employing Geographic Information Systems (GIS) [1,2]. In addition, today we face the ever-increasing access and usage of geographic mapping and location-based services via smart devices in people’s daily activities [3]. For this reason, emerging computing paradigms show high penetration rates in geospatial developments, with the latest and yet most significant one the Cloud computing [4,5]. As a result, existing systems are transformed from proprietary desktop GIS software applications of the early 80′s to free and open source interoperable Cloud GIS solutions built upon geospatial Web services (GWS) [6].

GWSs and service-oriented architecture (SOA) are the key components to achieve interoperability in Web GIS applications. GWSs allow self-contained geospatial functions to operate over the Web while SOA facilitates interoperability between these GWSs by establishing communication and data exchange for requesters and providers in a uniform way [7,8]. The dominant GWS standards adopted by the geospatial community are those introduced by the Open Geospatial Consortium (OGC) including the Web map service (WMS) to visualize [9], the Web feature service (WFS) and the Web coverage service (WCS) to acquire [10,11], the catalogue service for the Web (CSW) to discover [12] and also the emerging Web processing service (WPS) to process, spatial data [13].

In this respect, numerous research projects and business solutions rely on the above standards to achieve geospatial data interoperability between custom applications and to satisfy project-specific needs [14,15]. Furthermore, in European Union (EU) level, project actions have to be aligned with regulation No. 1312/2014 [16], implementing INSPIRE directive [17] as regards interoperability of spatial data services. According to this, all geospatial data have to be served under invocable spatial data services. As a result, most applications are nowadays based on Web services, use data provided over the Web or generated by users [18] and are executed on cross-platform browser-based interfaces. In the geospatial community, GWSs and XML-based open geospatial data formats, such as Geography MarkUp Language (GML), have become basic components of desktop and Web GIS software solutions. For example, the ESRI’s ArcGIS commercial product supports WMS connections through its popular ‘Add data’ interface [19]. QGIS open solution also supports connection to GWSs through appropriate plug-ins [20]. For individual Web-based applications it is possible to develop a custom GIS capability through open JavaScript libraries such as for example Openlayers (http://openlayers.org/) and GeoExt (https://geoext.github.io/geoext2) and have it executed on the client-side without the need of installing anything but an updated Web browser.

The development of research and commercial projects that utilize open or proprietary Web services and spatial application frameworks is rapidly growing. [21,22,23,24,25,26,27,28]. Several other Cloud GIS solutions are served as software, as platforms, as infrastructure under the popular service models, SaaS, PaaS and IaaS respectively [4]. A separate and special reference has to be made for Boundless Server [29] very recently announced: a reliable server solution for publishing a range of data and workflows over the web. However, an exclusively service-based application composed of open interoperable Web services could be an effective case. The developer would have to identify the appropriate GWSs and bind them between each-other in the correct order, same way as it happens in the well-known “ArcGIS model builder” [30]. The final outcome would be transparent to the user Web interface consisting of an interconnected set of Web services. This case may be extended to a Web GIS platform that gathers available GWSs and acts as a platform for building GIS projects.

In this paper, we explore the developmental framework for exploiting invocable GWSs, which satisfy routine geospatial needs. A comprehensive and sophisticated implementation might include a Web interface allowing the end user to select between task descriptions composing a GIS project. We demonstrate (http://gws.prieston.tech/) such an implementation which is exclusively based on open standards and services, a light-weight client-side pure JavaScript platform that performs: (a) data discovery from public data providers; (b) layer-based data view; (c) data selection by attributes; (d) feature data acquisition and preview and (e) simple geoprocessing tasks. For the last ones, we also explore the applicability of JavaScript, for implementing geoprocesses. Prior to this, the paper explores the effects of semantic Web technologies on fundamental geospatial elements and discusses critical architectural and development issues.

2. The Influence of Geospatial Web Semantics on GIS

The major components and principal operations and characteristics of an interface implemented according to geospatial Web semantics technologies, are identified and reviewed throughout GIS timeline from desktop and proprietary Web applications to open service-based GIS systems in the Cloud. The historical point that generally represents the geospatial evolution is when Web semantics technology standards were adopted by the geospatial community [31]. The three major areas briefly discussed in the following are (a) Formats, (b) Interoperability and (c) Automations.

2.1. Geospatial Data Formats

2.1.1. Vector Data

Vector data are considered the dominant component of a GIS System, holding the critical properties of the spatial entities that they represent such as their shape and spatial representation and topology. Traditionally, vector data were handled by geographers and GIS experts as the valuable form of spatial data, beyond others, for two reasons: their independence from scale and the capability of associating on them, unlimited amount of descriptive information. In addition, vector data production is expensive and time consuming since they are obtained by digitizing map images or as a result of GPS field data collection.

Various forms of vector data were adopted throughout GIS timeline from coverage and shapefile to proprietary and open geographic database formats. Today spatial coordinates of the vertices composing a vector graphic may be easily modelled through XML-based open formats (KML, GML, SVG) and transferred through OGC-WFS service requests.

2.1.2. Raster Data

Traditionally, raster data in the form of scanned maps (gif, jpeg, tiff etc.) were used as the base for producing vector data through digitization tasks. Therefore, the more detailed and of high resolution, a raster was the more analytical and precise was the digitization process. As a result, raster data were usually heavy-sized and their management in a desktop GIS environment required high efficiency computer hardware resources. Servicing maps and satellite images through static Web pages or through raster data repositories were also tasks dependent to hardware efficiency including internet infrastructures.

When the first map servers appeared, raster data were being served over the Web as textures of the ground surface, mainly satisfying navigation experience in earth browsers. Today image compression and tiled rendering techniques along with extremely high wireless internet connections make it possible to employ high quality raster data as the background for location-based services provided to smart device users. Raster data used as cartographic background are transferred through OGC-WMS service requests. Other raster formats like GeoTIFF that are used for coverage purposes (e.g., elevation or results from geoprocessing) are served via OGC WCS standard.

2.1.3. Descriptive Data

A fundamental structural characteristic of a GIS is the capability of associating the spatial features with descriptive data related to them. That way it is possible to perform sophisticated cartographic representations for decision and policy makers as well as to execute complex processes over descriptive data and produce valuable geoinformation. Descriptive data were normally easy to manage throughout GIS timeline because of the simultaneous emergence of database technologies. The external data sources to be associated with spatial features included a wide range of alternatives from simple comma separated values and single database files to relational geographic databases installed in remote servers.

Today the Web of Data and associated semantic technologies, support interoperability and standard formats to model and transfer descriptive data. ISO 191xx series and RDF are XML encoded data standards employed in the geospatial web [32].

2.2. Geospatial Interoperability

Geospatial interoperability became an issue, when the need for data communication and exchange between diverse geospatial stakeholders became a necessity. Till early ’90s, GIS vendors used their own proprietary formats, however they agreed to common standards and formats and they established connections to commonly shared repositories. As the technologies that developed by World Wide Web Consortium (W3C) matured, OGC introduced appropriate spatial related technologies to achieve syntactical and semantic interoperability.

2.2.1. Syntactical Interoperability

Syntactic interoperability assures data transfer between connected systems through Web services. In the geospatial community, it is currently achieved through OGC Services. For example, the WFS/GetFeatures request provides the standard interface and message types for Web services transferring features through XML. In the past, syntactical interoperability could be considered as the result of applying SQL commands through ODBC connectivity.

2.2.2. Semantic Interoperability

Semantic interoperability is the ideal situation where the exchanged content is machine understandable. To be such it has to be conceptualized formally and explicitly through appropriate specifications, such as GML, the standard for the exchange of service-based spatial data. Traditionally, semantic interoperability could only be achieved via pre-constructed data formats resulting from predefined domain specific data models (e.g., ArcFM [33], UML data models).

2.3. Geospatial Automations

A GIS project is usually a composition of single geospatial activities which normally begin with the acquisition of thematic layers and other data involved and the application of geospatial processes, depending on the exact domain of the geoscientific field of expertise. Automating these activities under a workflow of sequentially executed processes may be achieved by creating specialized batch files, or scripts. Traditionally, geospatial automations are implemented through sophisticated modules of the popular desktop GIS environments offering tools to manage geospatial processes, such as, for example, ModelBuilder [30] or Processing Modeller [34].

Now that all types of geospatial activities may be served through geospatial Web services, automation is achieved by ‘orchestrating’ these Web services. Orchestration “describes collaboration of the Web services in predefined patterns based on local decision about their interactions with one another at the message/execution level” [35]. OGC WPS can be designed to call a sequence of web services [13].

Table 1. Impact of Web semantics on geospatial technologies.

Title	Past	Today
Geospatial Data Structures
Vector data	Binary files (Shapefiles, coverages etc.), proprietary database formats (e.g., ESRI geodatabase)	Text files in XML-based formats (GML, SVG, KML)
Raster data	Image files (Raster)	Image files (Raster)
Descriptive data	Text files, proprietary database formats	Text files in XML-based formats (ISO 191xx, RDF etc.)
Geospatial Interoperability
Syntactic	Common data formats, ODBC connections to spatial databases	OGC Services
Semantic	Common data models (e.g., UML data models)	OWL, GML, RDF
Geospatial Automations
Workflows	Batch files and scripts Special model builders and process modellers	Web service orchestration (OGC WPS)

collects all related terminology in the above specified sections before and after Geospatial Web Semantics influence.

3. Software Prototype Design & Development

3.1. Functional Architecture

The successful operation of an application based on GWSs prerequisites the existence of available open geospatial Web services for data acquisition and data processing purposes. The end user interface should support access to the services via a Web browser, without the need of installing additional software. Figure 1 represents graphically the functional architecture of such an implementation, which includes:

• Free WMS and WFS geospatial services provided either by open-source (e.g., Boundless) or commercial (e.g., ESRI) GIS product leaders, satisfy the need of obtaining features and images
• Accessible processing platforms like 52° North initiative, or JavaScript node servers developed to support custom WPS implementations.
• a HTML browser-based interface developed in JavaScript, undertakes to serve user needs over a functional GIS-based environment as described below

3.2. Development

3.2.1. Raster and Vector Layer Views

To get raster and vector layers, WMS and WFS services, respectively, are employed. The user interacts with the following ways:

• Asking for available maps in the form of raster or image views of vectors through a WMS/GetCapabilities request and receiving a list with the offered layers along with further metadata descriptions in XML format
• Requesting for available features through a WFS/GetCapabilities request and receiving a list with the offered feature layers along with further metadata descriptions in XML format
• Requesting for a specific raster (or image views of a vector) layer through a WMS/GetMap request and receiving an image file
• Requesting for a specific vector layer through a WFS/GetFeatures request and receiving an XML file

Figure 2 illustrates an example of a WMS/GetCapabilities request coded in JavaScript along with the server XML response:

• The client makes an AJAX (Asynchronous JavaScript and XML) request using the XMLHttpRequest, either WMS or WFS with a URI parameter ‘request = GetCapabilities’.
• The server responds with XML data that will thereafter be parsed to JSON object and finally be viewed by the user as paged table data.

Practically, the above interaction takes place, whenever the user declares a potential service provider and checks geospatial data provision.

3.2.2. Geospatial Processes

Geospatial processes were implemented by employing the 52° North WPS HTML interface freely provided through the wps-js JavaScript library. This way, an HTML form was generated, through which it is possible to encode and parse XML-based WPS requests (GetCapabilities, DescribeProcess, Execute) for the geospatial processes offered by 52° North initiative WPS interface implementation, as well as some other OGC WPS compatible geoprocessing servers (e.g., GeoViQua) [36].

To contribute over the above, a Node.js server was developed in the present work, in order to interface user generated WPS requests with GDAL/OGR library functionalities. These OGC compliant WPS requests are transmitted through 52° North WPS client interface where the Node.js server was also declared in it.

Figure 3 provides a step by step representation of how interaction between client (WPS Client)—server(Node.js)—Cloud servers (WPS Servers) is taking place to complete a WPS request with wps-js and Node.js server.

3.2.3. Descriptive Data Management

Descriptive data involved in OGC services are an essential part of the development process because they specify the parameters of any type of request. These parameters are composed/expressed/edited in many ways and four of them are mentioned below. (1) and (2) concern requests submitted to geospatial servers, while (3) and (4) concern handling of the requests on the client-side:

(1)  HTTP GET Requests

HTTP is the simplest way to submit a request to an OGC service implementation through the browser’s URL bar and may also be incorporated in a JavaScript interface using AJAX requests. The URL expression below represents a WFS request for getting features from a geospatial server

          http://nsidc.org/cgi-bin/atlas_north?
          service=WFS&
          version=1.1.0&
          request=GetFeature&
          typename=greenland_elevation_contours
        

(2)  HTTP POST XML Requests

OGC services may support the “POST” method of the HTTP protocol and the request message is formulated as an XML document. XML tags, host the values of the parameters composing a request in a tree structure. In addition, they host the features and attributes of a vector layer. In any case, XML files establish OGC based interoperability acting as the medium for data and processes exchange between machines. The XML code represented below provides a WPS request which returns to the requester the description of all the geospatial processes offered by a WPS server.

<?xml version=“1.0” encoding=“UTF-8”?>
<wps:DescribeProcess service=“WPS” version=“1.0.0”
         xmlns:wps=“http://www.opengis.net/wps/1.0.0” xmlns:ows=“http://www.opengis.net/ows/1.1”
         xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
         xsi:schemaLocation=“http://www.opengis.net/wps/1.0.0
http://schemas.opengis.net/wps/1.0.0/wpsDescibeProcess_request.xsd”>
            <ows:Identifier>all</ows:Identifier>
</wps:DescribeProcess>
 

Another example has been presented in Figure 2.

(3)  GeoJSON

XML files are transformed to GeoJSON using the new specification RFC 4976 in order to be expressed as native JavaScript objects and handled appropriately, in terms of parsing and generating the parameters of OGC service requests. Being JSON objects they may be easily visualized as paged tables, may be modified by the end-user and may be reconstructed in XML code. An example of the bounding box property of a layer coded as properties of a JSON JavaScript object is shown below:

         “type”: “Feature”,
          “geometry”: {
          “type”: “Point”,
          “coordinates”: [125.6, 10.1]
           },
          “properties”: {
 

(4)  Paged Tables

A paged table can contain inner tables in its rows and this way of representation is convenient when dealing with layers and their properties (e.g., bounding box, EPSG etc.). In addition, it is possible to provide domain values for every attribute assisting further request manipulation to the end-user, as shown in the Figure 4 below:

3.3. End-User Interface

3.3.1. User Interaction

The end-user interface implements request and response interaction with the available OGC services (e.g., WMS, WFS, WPS). As already discussed the results of the above interaction may be XML-based files or images as shown in Figure 5 [15].

Specifically, user interaction results involve:

• Tabular data with (a) the available raster or vector layers or processes formed by WMS/WFS/WPS GetCapabilities XML-based files and (b) attributes of selected layers or process descriptions/results formed by WFS/GetFeatures and WPS/Describe-ExecuteProcess respectively, XML-based files
• Vector data coded in GML, the prevailing XML-based format
• Raster data in image file formats representing maps

3.3.2. Major Operational Areas

A prototype service-based end-user interface has been proposed [15] and is adopted in the present work as the base for the presented implementation. In the presented work this is extended to include geospatial data processing functions. Aim of the final prototype design is to achieve a typical desktop GIS-based ‘look and feel’ interface, exclusively exploiting geospatial Web services for data retrieval and processing purposes and this is performed with a completely transparent to the user manner. The following major operational areas for both advanced and simple operations are identified:

•  Data Management Area

At this area it is possible to declare the geospatial service providers. As soon as a server is declared WMS-WFS/GetCapabilities requests are submitted to it, resulting to the development of lists with the available raster and vector data. By selecting a layer from the above lists, either raster or vector it is possible to view and select its parameters, preparing that way the exact WMS/GetMap or WFS/GetFeatures respectively, request for submission. Alternatively, the user is capable of uploading layers to be included in the project.

Since, the whole environment is a service-based environment the presented layers are dynamically requested by the servers offering them, whenever the user checks for their visibility. To permanently obtain desired layers, at this area it is possible to clarify which of the requested layers will be cloned to form the GIS project on a local environment. Metadata information may also be retrieved and presented as long as this is supported by the standard specifications, as for example happens in WFS standard through metadata parameter.

•  Content Area

As already stated, layers selected in the Data Management Area are requested on a real time basis directly from the service provider. Whenever the end-user performs additional requests according to a desired parameterization, the server responds accordingly and the result is temporarily rendered in the front-end. This area contains the spatial content that has been permanently selected to form the GIS project and is therefore stored locally.

•  Data Visualization Area

This area is charged with visualizing the desired spatial content. Visualization concerns either the results of the service requests individually, such as for example an image returned or an XML file itself, or various themes overlaid to form a GIS project.

•  Messages Area

This area provides feedback to the end-user by presenting messages returned by server responses.

•  Data Processing Area

This area provides the necessary capabilities for declaring a geoprocessing server compatible with OGC/WPS specification and parameterizing a data processing request. The WPS implementation of this area is dynamically formed according to the type and the complexity of the requested geoprocessing job.

Figure 6 provides a visualization of the end-user interface operational areas. A video demonstrating the presented platform is available at goo.gl/f54X6Q.

4. Demo Presentation

A demonstration case containing routine geospatial activities is presented, implementing the following scenario:

‘Create a simple layout of the world overlaid by the country boundaries and export a vector layer of the boundaries in a shapefile format’

The scenario is further analysed for the following geospatial activities:

• Import a world map
• Import country boundaries
• Export the features of the buffer in shapefile format

Each of the above mentioned geo-activities will be performed by employing respective geospatial services by different servers. In detail:

(1)

The ArcGIS online sample server (http://sampleserver1.arcgisonline.com/) will be employed to provide the world map through the appropriate WMS service

(2)

The Boundless demo Geoserver (http://demo.boundlessgeo.com/geoserver/web/) will offer features of the country borders through its WFS services

(3)

A custom Node.js server was developed for the purposes of the present work and was registered in 52° North WPS HTML interface developed with wps-js JavaScript library (https://github.com/52North/wps-js), with the aim to transform the GML file in to shapefile format, by exploiting GDAL/OGR libraries as described in Section 3.2.2

Table 2. User actions, interface handling and server reactions.

Actor	User Action—Interface—Server Reactions
U	Declares WMS and WFS servers
I	Submits WMS-WFS/GetCapabilities requests to the declared servers
S	Return XML files with the offered raster and vector layers
I	Transforms XML files to lists of available raster and vector data in the Data Management area
U	Scans the lists with the available raster data and selects a layer of the world map
I	Submits WMS/GetMap request to the WMS Server offering the requested map
S	Returns the requested raster image map
I	Displays raster image map in the Data View area
U	Scans the lists with the available vector data and selects a layer of the world boundaries
I	Submits WFS/GetFeature request to the WFS Server offering the requested features
S	Returns GML file with the requested features
I	Displays raster image in the Data View area
U	Selects layers to form Layout
I	Permanently stores locally the selected layers which are overlaid in Content area
U	Selects Geospatial Processing Tools and declares WPS server
I	Submits WPS/GetCapabilities request to the declared Server
S	Returns XML file with the offered processes
U	Selects the Convert file process
I	Submits a WPS/DescribeProcess request
S	Returns XML file with a description of the specifications of the requested process
I	Displays the specifications of the requested process and prompts for user action in filling out parameters and, if required, providing data
U	Fills the requested data/parameters and submits a request to execute the process
I	Submits a WPS/ExecuteProcess request
S	Returns the results of the requested process
I	Provides the results

below, presents the end-user (U) actions and the subsequent server (S) reactions, both handled by the JS interface (I). All tasks are placed in a chronological order in the workflow of the presented scenario. The scenario is demo

Figure 7 visualizes the above scenario workflow:

5. Conclusions and Future Outlook

The presented work deals with invocable geospatial Web services and explores the potentiality of re-serving them under a fully transparent Web-based cross-platform interface in order to satisfy routine GIS functionalities. As such, the presented solution, is based on JavaScript, relies on open standards, is independent of additional software components, add-ins or APIs and all is needed is an updated Web browser. Even in the case of utilizing a server to implement a custom WPS service to satisfy a specific geo-process, the presented solution remains in JavaScript. This way both server and client components are light enough to reside on the client side, making the whole venture highly efficient and unique.

An interesting topic worth discussing in the present work is the development of the geospatial processing service provided by Node.js server which is invoked through 52° North wps-js interface. This task is subdivided into two discrete subtasks:

• the creation of the appropriate XML content modelling the description and execution of an OGC WPS compatible process and,
• the employment of a GIS engine performing this geospatial process.

The first subtask is a matter of editing the exact parameters of the WPS requests inside the appropriate XML tags. The second subtask requires the existence of GIS engines inside the WPS server and thereafter the establishment of an interaction between the engines and the server. In this respect Node.js was proved to be a convenient solution due to the direct communication with GDAL/OGR libraries command line. Extending this to other GIS APIs is expected to be a quite efficient and easy to implement task due to the capability of calling functionalities in most free and open source projects like those supported by the open source geospatial foundation, OSGeo (e.g., GRASS GIS and QGIS). Even more, in the case of ArcGIS the JavaScript API may also be employed to facilitate the Node.js communication with its GIS engine. Therefore, building WPS geospatial processes through Node.js may be considered as a great opportunity for further developments and extensions of the presented work.

Some of the most representative projects of the geospatial community, dealing exclusively with WPS standard are briefly cited: (a) 52° North initiative serves a significant number of WPS implementations and offers wps-js, a JavaScript library that makes possible to register WPS implementations and provide Web access for requesting and executing geospatial processes, (b) ZOO-Project, an OSGeo incubator project, offers an integrated WPS suite covering all the way from server to client including a server solution with a huge collection of implemented WPS services, a JavaScript API for services creation and a JavaScript library for Web interaction (c) PyWPS, also an OSGeo incubator project is a server side Python solution assisting the development and exposure of custom geospatial calculations and (d) Boundless Server, which is actually a complete server suite, consisting, beyond typical server components, of a WPS builder for server-side processes [29]. The presented work is in its very early stages, however it may potentially be enriched with stuff provided by all of the above mentioned. For the time being it adopts wps-js, registers in it a Node.js server and implements a demo WPS service. Thus, it provides a client interface together with a WPS server, that both of them employ JavaScript libraries. In addition, the presented work does not focus only on WPS and extends its vision to satisfy a complete geospatial environment offering routine GIS functions.

Having said all that, one may realize the applicability of the presented research: a free and open source platform dealing with freely available OGC services may potentially satisfy any geospatial need, either for gathering or for processing data or for undertaking a complex GIS project. Limitations are mainly depending on external factors: the system relies on the availability and function of publicly available invocable web services, therefore, in case of a server malfunction there’s no other choice, than find other functional geospatial servers. Concluding, potential applications of the presented research include the public reusability of any geospatial process that is already or is expected to be freely provided and may be executed with user-owned or other discoverable geospatial data. As such, is expected beyond others, to contribute also to the management of data and the development of geospatial processes related to the assessment of pressures exerted on the environment [37] acting as one more tool towards tackling environmentally related societal changes.