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.
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.
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.
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.
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 portal.sdi4apps.eu to test our solutions and see demos of how they may be put to work.