This paper describes a few ideas concerned with geographical information systems (GIS) development. Those ideas come from a GIS development project named GeKon, which is now held on the Department of Computer Science at CTU. The first of them deals with a huge semantic gap between the complex structure of real world and its representation in GIS. Some papers describe this problem as a consequence of wide usage of procedural programing languages and relational database management systems in contemporary GIS development. The object-oriented approach is usually recommended as a better way of constructing such systems. We demonstrate here our findings in object modelling, programing and data management achieved in GeKon project. The other idea shows the fact, that not always the term object-oriented is understood in the same way. People usually have in mind some specific programing language and its structures, instead of the real problem and its solution. In this paper we want to clarify those misleadings and try to describe requirements, that should be fulfilled to achieve expected benefits of this approach. We also introduce next supposed steps in the GeKon project.
At the beginning, we have to slightly describe geographical information systems (GIS) evolution process to reader be more familiar with questions connected with this area of research. Present GIS were principally constructed as tools for computer based maintenance of geo-referenced data formerly kept in cartographical tools, like maps, atlases, cadastral plans, etc. Evolution of such systems probably started with the idea of cartography digitalization drawn ahead by the vision of map producing acceleration, and also faster access to carographical data, including sorting, searching, and other functions that could lead to better utilization of geo-referenced data. 1.1
Present problems of GIS systems have probably their origin in the way of GIS data production. The process of cartography digitalization consists of scanning cartographical tool, and then its vectorization by laying vector paths over the lines in the map. The data produced by this process tend to come under three main geometry types: – spotted, when some interesting spot had been captured, like a church, a tree, a well, etc. – linear, when some linear data had been captured, like roads, borders, railways, networks, etc. – planar, where some area of interest had been captured, like cadastre area, city district, etc.
This separation lead to three main data types used in present GIS: points, lines and polygons. Almost all such systems use as its storage device those three elements. One of the first companies in GIS field named ESRI had invented special file format named shapefile (SHP) for storing these data. SHP becomes something like a standard in GIS data management. Probably for better preservation of cartographical information, data were collected separately in thematic parts. It means, that all churches in observed area were vectorized in one pointbased shapefile, all roads in one line-based shapefile, etc. This approach lead to very discrete representation of real world. When the map is to be retrospectively reconstructed in GIS, all thematic files has to be layered over themselves to obtain proper cartographical representation. Layers are not connected among themselves, so ie. the information about roads leading to a well is not present.
Further needs of additional information capturing and storage lead to extension of shape format with so called attribute data component like names, numbers, etc. At the same time as this problem arose, the relational approach to data management achieved great concern. So the GIS files were extended with database file (DBF) including attribute data, connected to their geometry representation in shapefiles. Both those files were stored separately. Relational tables consist of domains, and records, so the real world information has to be separated and simplified into these parts to be stored in DBF. This approach also lead to more discrete GIS data quality and omitting of more complicated information.
Both stated approaches have not changed since the beginning of GIS. The only novel approach is to store SHP and DBF files into relational database management system and reach them through the SQL. But this way only leads to bigger conservation of the problem. 1.2
Wikipedia describes semantic gap as a mismatch caused by some conflicts
emerging in layered systems, when a high level of abstraction need to be translated
to lower, more concrete artifacts [
Merunka recommends an object-oriented approach (OOA) as a good solution of
semantic gap in information systems development [
Comparing OOA ideas with GIS problems gives a new horizon to their solution. Our natural way of perception of material aspect of the real world is that everything is an object, and now with OOA everything is possible to be an object in our computer memory. What we only need is to start using OOA in instant. No more thinking about geometrical representation of objects or the way how to store them into tables.
Of course, this is not the novel idea. Mitrovic and Djordjevic-Kajan described
in 1996 OOA as natural paradigm for highly complex domains, especially
because it maintains a direct correspondence between real world and application
objects [
Looking for some indications of OOA emerging in GIS, we could find a few
papers describing object modelling in GIS, especially when the 3rd dimension
has to be introduced to those systems. For example, Nebiker wrote in 2003 about
his fully object-oriented model for 3D geo-objects [
There are also some projects, that have already implemented parts of GIS using
OOA. One of them is already cited in Koflers PhD. thesis [
Balovnev et al. implemented software for 3D/4D geo-scientific applications
developement named GeoToolKit [
One of the other projects is GeoViewer implemented by Lurie et al. in 1997
[
Because we see all of those projects very important as a way to improve present GIS applications, we have also opened research project concerning OOA used in GIS development. The name of this project is GeKon an it was started as a semestral work in one of our Software engineering courses. Members of the development team were three undergraduate students - Ivo Kondapaneni, Petr Novosad, Jiri Verunek, and author himself. Ivo Kondapaneni had to leave our project later for his other academic duties, so project extent had to be partially narrowed.
GeKon system is now able to load data from shapefiles and display it on the computer screen. It is also possible to zoom displayed data and move over it. As a test case the city GIS problem was chosen and as a development platform we used Squeak Smalltalk dialect. In Fig. 1. we introduce our object model.
This model shows the GeKon structure - space subdivision, geometry and city object model. In the space subdivision part we formed our idea that it was necessary to maintain some sophisticated indexed structure that allowed fast searching. We use two trees here. First one is responsible for logical subdivision of the city (city districts, basic settlement units, and counting districts) and it is implemented with collections. Second one is responsible for searching the physical space within the counting district and it is implemented as a R-tree. Loaded objects are primarily classified according to the logical space subdivision and then inserted into R-tree of relevant counting district.
Geometry part of our model is responsible only for the geometric representation of objects. Now it contains only necessary representations - point, line and polygon, expanded with 3D solid representations. Each shape has its own bounding box which is stored in space subdivision structures.
The logical object structure of city is the only demonstrative example of part of the city configuration. Its main purpose is to show how we need to model the reality - naturally. We expect that in the future this part of the GIS will be constructed in some visual metamodeller directly by the GIS user at the moment of data import. This approach assumes strict clear disjunction of the data and its representation.
Visualization was partly implemented using OpenGL, but after loss of I. Kondapaneni we had to choose easier way. So we used Squeak morphic visualization system, which is sufficient, but lacks possibilities to improve graphics performance in the future like redrawing using textures etc. So we plan to redevelop OpenGL rendering engine for GeKon in future.
Data management has not been covered yet, we are storing all data in Smalltalk image. In future, we plan to incorporate OmniBase as a database management system, which ensures native storage and retrieval of objects. We also plan to cooperate with another project held on our department named CellStore, which deals with heterogeneous data storage and now serves as native XML database.
During the development we used sample data from the ICIP (Institute of City Informatics - Prague), covering the Josefov city district. The average loading time was 1749ms per 1MB and the refreshing time about 320ms, which is not bad. But we see these results orientational only, because the sample is too small to give evidence of the GeKon capabilities. Further we want to use bigger data collections for testing, but they were not available at the moment.
In this paper we described semantic gap problem between the real world and its computer based representation. This problem was described from the GIS point of view. GIS are still very tightly coupled with the old fashioned representation of the real world by using files and relational tables. We discussed here OOA as one of the approaches that are able to overcome semantic gap. Some interesting projects concerning object modelling and object-oriented implementations of GIS systems were slightly introduced. In the end of our paper, we also presented our own project GeKon, in which we developed the prototype of object-oriented GIS. Now we want to summarize discovered requirements for the GIS development and also planned work in the GeKon project. 3.1
Based on our experience in GeKon system development and also on the
knowledge from previously cited papers we strongly recommend following rules to be
applied in OOA GIS development:
– Separate geometric representation from object itself to be independent on
its shape.
– Use R-trees or other indexing structures for fast searching in space and
efficient data retrieval.
– Pay attention to very fast rendering algorithms to prepare the most
comfortable environment for users.
– Use metamodeller controlled by the user to obtain the logical structure of
the place of interest.
– Use strictly pure non-hybrid object-oriented language to avoid programmers
cheating (for details see [
In future, we want to continue in development of GeKon system on our department, partly in the form of dissertation, diploma and other thesis, partly as student semestral projects. Fig. 2. describes the roadmap of planned work.