Home Articles Making of spatial reality

Making of spatial reality

Srikrishna Pothukuchi
Navionics Technologies Pvt. Ltd.
[email protected]

Most of the present day business solutions enforce intelligent usage of data; spatial data is of no exception. As the situation demands for higher accuracy levels in the findings/results, the Applications Analyst has to do more rigorous analysis, i.e., more parameters to work with, more relations to make on, and more permutations & combinations to arrive at while formulating conclusion(s).

‘Making of Spatial Reality’ explores the possibility of a spatial system that works not only in the real-time, but also in a predefined spatial context that matches the needs of the analyst, reducing the burden of working on multiple parameters for analysis. Spatial Reality spawns beyond the Data Mining & OLAP technology. Besides formulating a rulebase, this paper defines ‘Spatial Events’ corresponding to a particular scenario of spatial design in the real-time. These spatial events can be classified further based on each scenario and there comes the Spatial Reality.

This paper does not describe functioning of a real-time spatial system per se, rather it discusses the need of such system in the Analysis & Design for the Application Domains like Telecommunications, Highway Engineering or Business Geographics.

We can see the proliferation of end-user systems deploying some of these fundamental concepts but there is need for deployment of such concepts in Analysis & Design as well. This paper also elaborates few principles behind making of the spatial reality true, within the framework of contemporary Software Engineering principles. This paper also advocates simplification of spatial/aspatial data design by introduction of the software tools corresponding to the ‘Spatial Events’.

This paper is aimed at the needs of a typical GIS Analyst, who works on various datasets, both similar as well as dissimilar and performs hectic task of running various permutations and combinations, and finally arrives at finalising an end schema. The analyst puts also the expertise combined with intuition gathered over years of field exposure into his/her analysis. Even though it is true for all seasoned professionals to encounter such situations in their daily routines, the degree of working on multiple parameters should be reduced in some way in order to arrive at a more accurate result. It is the Spatial Reality that assists the analyst in several ways over solving a problem.

Spatial Reality, here onwards referred to as SR in short, is a conceptual framework that implies the capability of an Application System, for realising the locational factors of an entity or group of entities in space and time, and its capability for recognising and responding to the events generated either by the very existence of such entities in space or by the interaction among entities in space.

Spatial Reality is based on spatial events, those comply the rules of the spatial algebra. We will be achieving the SR, if we are able to capture the events based on intelligent actions of entities and ready to use that knowledge in order to automate the analysis & design process. SR is not a pure decision support tool, rather it forms a framework upon which many DSS tools can be built, which are spatially enabled.

The Need
Any designer could start with a paper and pencil in the beginning of the analysis/design phase. As the complexity of the problem domain creeps up, this simple tool will be upgraded to electronic computer with sophisticated software. For sometime this is going to be a finer solution as it automates many of the manual processes. Again our original problem creeps up, whenever the design complexity tends to grow more.

Here the designer stops and he may even have to adapt to his previous tools – the paper & pencil. Most of us might have faced this problem in our professional lives. The problem lies here is not in the capability of the software, but it is the limited capability of the humanwear.

A human being arrives at a right solution if he applies rationale on a problem, provided if the inputs are conceivable and optimal. He fails drastically in providing an accurate solution if he has to work with multiple inputs and aiming at multiple outputs with a backdrop of multiple processes.

GIS analysis is no exception while delivering the promises. This statement becomes true for Enterprise GIS systems especially at the conceptual phase. Let us assume the professional stinct of an analyst working on an outside plant of a utility company. He has the task of identifying ground for laying long-distance underground utilities. If we try to arrange the tasks – he got to identify the terrain over which he is working, then the climatic conditions of the work area, rock formation, socio-economic conditions of the terrain under study, demographic details, history of natural calamities, etc., apart from the basic engineering parameters like the tolerance levels of utility for laying, pressure and temperature, etc. If we try to order the activities, two major classes could be identified: 1. Planning Activities complying with basic Utility Engineering Principles, 2. Planning Activities complying with Geotechnical Engineering and allied subjects.

Any activity done after planning affecting the plant should always comply with the principles given under the first set of principles. For example, the facility (like the gas duct) manual prescribes a maximum 15o bend, that facility should not be bent further to accommodate any correction as per the ground truth. Henceforth these principles form engineering knowledge base of the domain.

If the utility company is a conglomerate dealing with multiple distribution services like the gas, power and telephone, then the work of the analyst is going to be multifold. This implies more domains to analyse, more principles to adopt and more recommendations to make.

The Spatial Reality Framework
So far the assumption spanned around a single person performing the tasks of domain expert, utility planner and GIS analyst. However in reality this single person is replaced with multidimensional teams. Still the problem lies where it was or still more complicated with relative inter-communication problems.

If we have system that automates the functions of a domain expert and the GIS analyst, we could give more freedom to the utility planner or vice versa. Subsequently we will be building an intelligent system, that could respond to various events either business events or spatial events. The following picture depicts such a system.

This diagram contains three swim lanes for guidelines, framework and implementation respectively. The first swim lane guidelines provides the guiding principles within a particular subject area that drive a concept. The second swim lane framework provides conceptual limitations under which the subject could be implemented. The third swim lane implementation provides overall system comprehension meticulously.

As per the schematic, spatial events form the basis of conceptual pyramid. Spatial events are generated by the system based on the well-established principles of spatial algebra. For example, a new line segment drawn inside the buffer zone would trigger a spatial event. Spatial events are supplemented by geotechnical events. The major difference between spatial events and geotechnical events is that while the former is based on geometric primitives, the later adds quality to it. For example gradient of a field exceeding the predetermined value would raise a geotechnical event. Other major difference is that a spatial event is formed by well-established principles of GIS and spatial algebra and it could not be altered. Major portions of geotechnical parameters could be set by the qualified user.

Domain events are generated by predefined parameters set by the qualified domain expert. These could be tolerance values of an element, geometric constraints, etc. In fact domain events and geotechnical events form business rules for the system.

Automation corresponds to the translation of various events to the analysis domain. This is rather an internal function of the system and an end-user could have barely control over automation, even though he utilizes the automation benefits while analysis.

The framework is formulated in a flexible way such that it could accommodate any number of sub-classes of events as long as the logical relationship exists. However introduction of new event classes should be regarded carefully so that the automation could yield expected results.

The implementation swim lane gives out an architectural overview of components corresponding to the conceptual framework. An operating system kernel forms the foundation for SR implementation. This OS kernel differs from traditional OS kernels, because it has to support different type of events altogether. It would certainly be a debatable issue of introducing a new OS kernel, even though it is obvious to implement with existing operating systems within the market. The new OS kernel will not replace the functionality of the traditional OS completely – it enhances the traditional OS while performing the typical OS tasks.

The OS kernel besides the RuleBase Engine, Application Programming Interface and the Event Listener forms Spatial Operating System, also known as the SOS. Although need for a special operating system like the SOS is out of scope, this paper commends it because of certain unaddressed problems in the spatial technologies by the traditional software. One typical and most obvious advantage of the SOS is that, it relieves responsibility of a typical GIS application package while performing many tasks common to major spatial platforms.

RuleBase Engine maintains a repository of events that could be classified according to the events as presented in the framework. This repository is programmable in order to give flexibility to the end-user enabling him to adopt the solution tailor-made to his requirements. It validates the events captured by the Event Listener and passes the SOS Kernel with an appropriate request.

An Application Programming Interface or API is provided to customise the SOS Kernel and/or RuleBase Engine. It facilitates the end-user or a package vendor to program his application for the SR.

GIS Application Package coexists with the SOS and forms the top layer. This is the most visible component from the user perspective.

Technology Adaptation
Since this paper is neither technology specific nor implementation specific, various alternatives could be studied for viability. If the SOS portion of the implementation swim lane is ignored, the GIS application package has to provide all the functionality indicated by the conceptual framework. Because of the nature of software reusability and wide usage of component technologies spatial reality could be possible on existing GIS packages within short span of time.

If the decision for development favoring the adaptation of architecture and the SOS, considerable amount of effort has to be invested on development. Here the time spent on development for the SOS compensates future efforts on developing the GIS Packages because, as described in the paper previously, the SOS identifies and relieves any GIS Package of common tasks. However this approach requires consensus and standardisation among various vendors and the governing bodies like the OGC or ISO sub committees.

Once the SR technology matures, it would benefit the spatial scientist in many ways one among them is creation spatial analysis tools in lines of CASE tools for a typical software engineer. Description of such tools is out of scope for this paper, however its significance should not be ruled out. One analogy is that of an Integrated Development Environment enriching the productivity of a developer could be well compared off these future tools.

Once the need for implementation of Spatial Reality intensifies, definitely it is going to have impact on the paradigms of all stakeholders in the GIS industry. It will influence other technologies one among them being the Spatial Operating System. Successful implementation of SR will not affect coexistence of other systems like the RDBMSs, but its commercial implications on them are quite obvious.


  • Demers, Michael, 1999, Fundamentals of Geographic Information Systems, John Wiley & Sons.
  • M. Milenkovic, 1987, Operating Systems: Concepts and Design. McGraw-Hill.
  • Pothukuchi, S. 2001Know Thy Customer – An Introduction to Event-Reaction-Response Model, Proceedings of the Geomatica 2001:3-34, Indian Society for Geomatics
  • Silberschatz, H. Korth and S. Sudarshan, 1997, Database System Concepts, McGraw-Hill, 1997.