|
Making of spatial reality 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. 
Implementation 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. Conclusion 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. Reference
Page 2 of 2
| Previous | |