SDI 4 Apps - Uptake of open geographic information through innovative services based on linked data

The first release of the s4a.js library was somewhat of a silent affair. A more boisterous release is envisaged once it falls into line with the project’s business strategy. S4a.js is however out, and while we are still working on adding documentation and examples, we thought this could be a good time to highlight some of the new possibilities that are put at the finger tips of SDI4Apps users through this release.

Just because a problem is well-known and has been around for some time doesn’t necessarily mean that has stopped being a problem and has found a conclusive and permanent solution. It often just means that we have learned to work around it or — more commonly — learned to live with it. Three such problem domains are indexing and information retrieval, route solving problems and sensor data collection.

Indexing and search

It is amazing,really, how much user interface ‘heritage’ from 1990s desktop GIS applications has been brought along into the web application eco-system — and equally amazing how many constraints are still being imposed by ‘ageing’ data formats like the ESRI Shapefile or the MapInfo TAB file.

User interface heritage from the 1990s

The GIS query dialogue: why are you still here in 2016?

One of the least likely survivors of this era, I find, is the search utility that is commonly found in both web applications and contemporary desktop GIS applications. Typically, this is a dialog window where you have to construct a ‘semi-human-readable’ query expression, reminiscent of SQL, that uses cryptic field names and non-intuitive syntax for specifying operators and functions.

This is great from the perspective that it keeps query in the hands of GIS experts who can feel safe in their positions; it is less great from the perspective that much of the business value in querying spatial data likely lie with non-GIS professionals; people who need to solve problems in their own business domains without having to obtain higher degrees in GIS first.

In addition to being cumbersome for the operator, GIS systems are also poor performers when it comes to search speed. Instead of scanning a single index, like Google, it has to loop through files, for each file loop through rows and for each row, loop through all fields — effectively causing millions of CPU-hogging comparison iterations for simple search operations.

SDI4Apps proposes an alternative approach. We have constructed something  we call a ‘GeoDoc’ that corresponds to the ‘snippet’ you see on the search result pages in Google – except it has been extended with a couple of additional properties. Through our indexing submission service you can map a multitude of different datasets to the GeoDoc data model and ingest it into a single index. The GeoDoc stores both the full geometry and a representation point (for use in search results and on small and intermediate map presentations).

This index is stored twice. First in an Apache Lucene index to permit high-performance full-text searches; second in PostgreSQL/PostGIS to allow sophisticated spatial operations. This dramatically improves the scalability of spatial indexing and search. We experience response times of ~10-50 ms for searches of indices of more than 20 million GeoDocs.

Cloud-based routing from JavaScript

Let me first reassure you that we are perfectly aware that routing is nothing new. It has been around for ages — and solutions like Google Maps, OpenTripPlanner and the Open Source Routing Machine have perfected the performance of searches based on pre-cached data. These services and their peers, along with the traditional providers of navigation solutions Here (formerly Navteq) and TeleAtlas cover the majority of routing requirements from the consumer markets.

What these solutions do NOT offer is the facility to solve professional routing problems like ‘travelling salesperson’, ‘origin-destination matrix’ or ‘reachable area’, all of which are highly useful but mainly inaccessible to professionals like service, transportation and infrastructure planners – lest they go to the GIS department, request an audience with the resident GIS dictator/dictatress and pray that he or she  wields some magic using a USD 20 000 piece of software with a USD 2  000 program extension. Due to lack of data and complexity of process, this is typically a problem that people learn to live with.

Using routable Open Street Map data and pgRouting, a Java servlet and the s4a.js library, the SDI4Apps platform exposes a routing module as a programmable object in JavaScript. Building an application capable of performing the above tasks is a matter of minutes — hours at most and the functionality is already implemented as a sample in the SDI4Apps template client ‘HS Layers NG’.

Smartphone sensors made easy

One of the use cases for GIS that originally got me interested in this very interesting domain back in the middle of the 1990s was fleet tracking. I was born in the west of Norway, an area rich in natural beauty, narrow roads, authoritarian small-scale bureaucrats — and fish.

Export of fish was, and is, a booming industry in Norway. Strangely enough, an important part of the consumer market for ‘our fish’ is southern Europe and the Mediterranean countries — this requires cooling trucks, big cooling trucks, many cooling trucks — expensive cooling trucks.

In Italy, there existed at the time, and perhaps still exists, an organization made ‘popular’ by films like the Godfather, whose business model relied on expropriation of these trucks and their contents. At night, while the driver was sleeping at some rest area, representatives of this organization would sneak up on the vehicle, squeeze a hose into its ventilation system and deposit a generous quantity of knock-out gas into the cabin. The driver thus being pacified could be disposed of — and the vehicle taken into possession.

Understandably, this was a rather unattractive proposition for the owners of the trucks and cargo — and likely also for the marauded drivers.

The technological advances at the time made it possible to build a neat, albeit expensive, solution to this problem. A positioning device was placed somewhere hidden on the truck, emitting signals via a mobile phone modem. A small explosive device was embedded in the fuel-pump of the truck allowing it to be ‘disabled’ demand by calling up the mobile phone modem on the truck device. The truck having been stolen, an arrangement could be made with the local police to meet up with it at a convenient place at which time the fuel-pump would be disabled and the vehicle could be transferred back to its original owner.

I liked this — I liked this a lot.

Now, 21 years later, standardization of sensor communication and querying interfaces has been ongoing for a long time. The Sensors Web Enablement (SWE) initiative has been an engine of this work and the Sensor Observation Service (SOS) standard one of the key results. However, we still see that the community is divided between the sensor manufacturers who run their own proprietary protocols and data formats on the one hand; the standardization crowd with their XML and SOS on the other.

Despite two decades having passed, sensor solutions are expensive and only available to people with significant purchasing power. This is surprising, because we are all now walking around with state-of-the art sensors in our pockets: smartphones. All of these are capable of running native, hybrid and web applications – and implements the HTML5 Geolocation API. Effectively, we have the means to collect sensor data without any additional investment.

We need to store the sensor observations somewhere. Relying on the hybrid mobile application framework Cordova (aka PhoneGap), s4a.js implements SensLog as a programmable object in JavaScript making it easy both to insert and retrieve observations from sensors with single lines of code. Before calling these methods, the units and sensors should be registered using the SensLog administration tool. Once you have done that, inserting the position of your unit as well as observations from the sensors on the device are a matter of single lines of JavaScript code.

Now, we have both the sensors and the means to store and retrieve the sensor data — all accessible from simple JavaScript using the Cloud infrastructure of the SDI4Apps platform. This significantly leverages the cost and complexity of setting up sensors solutions and opens up this market to a completely new set of users.

That’s it for now. We’ll be back with an update once all the documentation and samples are in place. In the meanwhile, check out our repositories on GitHub and check in at our demo portal to test our solutions and see demos of how they may be put to work.

Share this: