Geo-BASE : A Spatial DBMS for GIS applications 1

Transcription

1 Geo-BASE : A Spatial DBMS for GIS applications 1 Hemalatha Diwakar Aditya Pidgu 2 Rahul Bhagwat 3 Reader, Dept of Computer Science Dept of Computer Science, Dept of Computer Science, University of Pune University of Pune University of Pune, Ganeshkind, Pune Ganeshkind, Pune Ganeshkind, Pune hdiwakar@cs.unipune.ernet.in Aditya.Pidugu@indsys.ge.com ABSTRACT A Spatial Database Management System, named as Geo- BASE, to handle spatial data and non-spatial attribute data has been developed to support the application needs of Geographical Information Systems. Geo-BASE, is modeled using an Object-Relational approach and implemented with spatial data (vector data) stored as objects and the related nonspatial attribute data stored as relations in any ODBC compliant RDBMS. Geo-SQL, a new spatial data language, an extension of ANSI SQL has been evolved to manipulate the spatial and nonspatial data. A Geo-SQL Parser, Query Planner and optimizer have also been developed to process queries written in Geo-SQL. The spatial query constructs introduced in the Geo-SQL are Open GIS compliant and various algorithms have been developed to implement the same. The Geo-Spatial Database Management System runs on the Windows NT environment and provides both a front-end interface for end users and a set of APIs for program interfaces. 1. INTRODUCTION Management of Spatial data is an important component of Geographical Information System (GIS) applications. The Data management system to store this kind of data, must be capable of storing and retrieving spatial as well as non-spatial entities. More over, the aim of a spatial DBMS, is to provide the users a clean interface to handle and interrogate the spatial model. The Spatial Database Management System must have the ability to structure the model in layers; have a well-defined topology to retrieve any meaningful connection between spatial and nonspatial entities. In addition to it, standard features of a conventional data base system like data integrity, access control, recovery, are also to be present in the system [4]. Various spatial database models have been proposed and developed to support GIS but these models are faced with the problem of elegant and efficient implementations. Especially the seamless integration of the geographic and non-geographic data, storage of geographic data in suitable data structures, and a powerful query language to query them has been important areas of research in GIS. In this paper, a spatial database management system called GEO-BASE, is developed and the significant feature of this system are :- The object relational model used for modeling the Geo- BASE; Object data modeling used for representing the geographic (geometric) objects and relational modeling for capturing the non geographic properties of the geometric objects Extensive spatial query language, which is compliant with the spatial constructs specified in Open GIS standards. Simple query processing strategy, as the spatial and nonspatial ( ANSI SQL) are easily separable.in the query language named as Geo-SQL. Robust algorithms for implementing various spatial constructs. GUI for users and API for GIS application programmers. In this paper, the spatial architecture of the Geo-Base system is discussed in section 2. The next section introduces the object relational approach followed in the system. The main emphasis of the paper is the powerful spatial query language, named as Geo-SQL, and it is discussed in detail in section 4. Brief views of the various geometric algorithms for the spatial constructs and the query processing strategies are discussed next. The paper 1 This work is sponsored by UNDP and DST, India under "GIS- Based technologies for local area development planning" project. 2 Currently with Satyam Computers Ltd, Hyderabad, India 3 Currently with SNR India Ltd,Pune ADVANCES IN DATA MANAGEMENT 2000 Krithi Ramamritham, T.M. Vijayaraman (Editors) Tata McGraw-Hill Publishing Company Ltd. CSI 2000

2 concludes with the status of the work, its applicability and further extensions. 2. SPATIAL DATABASE ARCHITECTURE Spatial Databases are required to capture and manipulate spatial data as well as non-spatial data, both of which are interrelated by their semantics. Three popular architectures based on which most of the spatial DBMS are built are[2]: Dedicated Systems such as QUILT Integrated architecture Dual architecture Dedicated systems are application specific and are not extendible to develop any other spatial database applications. Integrated systems[1] use the same relational tables for storing both spatial and non-spatial data; Co-ordinates, line segments are stored in relational tables. These are normally stored in bulk as strings in columns, or two-dimensional co-ordinates converted into onedimensional spatial keys stored as database columns( Earlier Oracle Cartridge). This method results in inefficient storage of spatial data and. In another approach, changes to the source code of the DBMS packages are made to take care of new spatial objects such as Geo2, Geo-Sabrina. In dual architecture the spatial database is kept separate from the non-spatial database (which could be stored using any back-end DBMS package) and both are linked and integrated using a Spatial Data Base engine. This approach is used in ARC /INFO, INTERGRAPH IGDS/DMRS, and ORACLE-MULTIDIMENSION. This separation does not require any change in the chosen DBMS package at the software code level, but integrity constraints, concurrency and security are maintained within the Spatial Data Base engine. Applica tions Spatial Database AP I Query Processor Engine Fig 1. Spatial Data Architecture GRAM Vector Data RDBMS The dual architecture, gives the flexibility to use any ODBC compliant RDBMS package for storing the non-spatial data, and the freedom to use any suitable spatial data structure for storing the spatial data. Hence the Spatial Database architecture, chosen for the Geo-BASE is dual architecture. This is shown in fig 1. The input to the system is a set of map layers, with their associated attribute data available as Relational tables. This input is made available in a specially designed format called as Gram Vector Format. 3. SPATIAL DATA MODEL OF Geo-BASE In a spatial database, the spatial objects are objects that occur in map layers. The geometric objects that are referenced in maps like city, village, river, state etc belong to any one of the data types point, polyline, or polygon. The Objects City, village etc. are called as spatially referenced objects and the data types point,polyline, polygon are referred to as spatial objects. As the spatial objects follow a natural class hierarchy, an object oriented data model seems appropriate to capture the spatially referenced objects. At the same time, the availability of robust commercial relational database management systems with standard SQL support makes it logical to use these systems for storing non-geometric or non spatial data of the underlying spatially referenced objects. Hence, an object-based approach for capturing the spatial properties of the map objects and the relational model for storing their abstract characteristics is used in the Geo-BASE. Region Layer Point Hybrid Polyline Polygon Fig 2. Object Relational Data Model Fig 2 describes the Object Relational data model used for representing the above said system. The object/data types supported are regions, layers, points, Polylines (Polyline is a sequence of segments that in turn comprise of lines), polygons and hybrid. Regions comprise of layers. A region comprises of map layers, of a particular geographical area. For example, it could be map layers pertaining to a country. A Layer is a geographical map based on a single theme like rivers, land use covers of a country, and is of only one data type. Layers are of type points, Polylines, polygons or hybrid (containing more than one type, allowed only for display purposes). Each object has data items and methods associated with it. For instance, data items for a region are Region name, scale, origin of reference etc. Spatial data or the geometric objects present in a map layer are stored using tile structures. Each spatial object has a unique identifier termed as SID, which is also referenced, in the corresponding non-spatial RDBMS tables. Each spatial object also has a user-defined identifier that need not be unique. For example, a country may comprise of many spatial components and hence those many unique SIDs will represent it; but all of them will have the same country name. The country name is nothing but the user defined identifier. For every layer, there is an associated relation( called base relation) in which each of the spatial objects of the that layer is represented by an instance (tuple) in the relation. There could be more than one relation associated with a map layer and these relations in turn

3 depend on the base relation for existence. Spatial operations are implemented using methods for the spatial objects. A few of the methods from the set of implemented methods for their respective objects are given in Table 1. Table 1: Spatial Operations Region Set Region, Reset Region, GetRegionInfo, CreateRegion, DeleteRegion Layer Point Polyline Polygon GetLayername, GetLayerType, Add Layer, Delete Layer, WithinLayer, Circle, Overlay, Union, Intersect, Length etc. Distance, Equal, Within Buffer etc Buffer, Meets, Within, Intersect, Length etc. Buffer, Touches, Merge, Disjoint, Within, Perimeter, Overlay, and Holes in polygon etc. 4. SPATIAL QUERY LANGUAGE Any interaction with a database is done through a query language. Structured Query Language, called SQL is the standard query language used in any commercial RDBMS package. But the SQL for these packages is tailor made for dealing only with non-spatial data[3]. At the time of development of Geo-BASE, a through survey on spatial query languages indicated that some spatial data base packages such as ESRI s spatial data base engine, had their own proprietary spatial query language[2].the non-spatial data was allowed to reside on any ODBC compliant database. Also, the functions making the ODBC calls were to be explicitly embedded into a query by the user, which makes a simple two map, overlay query to run into pages. At the same time, certain other commercial Spatial Database packages such as ORACLE, Geo SABRINA, used SQL as the base. Abstract Data Types (ADTs) were introduced in SQL and extended to accommodate spatial constructs[7],[5].. The spatial and non-spatial constructs are intermixed in the spatial SQL, as spatial objects in both the products are also stored as tuples in tables. The expressive power of such a language is extremely good but the user has to learn the new SQL to know the new language constructs, types etc. In order to avoid these drawbacks, a spatial query language called Geo-SQL,has been designed, in which standard ANSI SQL has been extended to support spatial extensions. To illustrate, a selection query has the following syntax. Select <spatial objects>, < non-spatial attributes> From <relational tables>] {Where <non-spatial query> AND/OR Sbegin <Spatial query> Send}* Here the spatial query component is separated from non-spatial constructs, keeping in mind the following factors: The non-spatial query is a standard SQL statement. So, the Geo-SQL parser separates out the SQL component and sends it as such to any ODBC compliant commercial RDBMS package. The query planner becomes simple if this approach is adopted. All the requirements of the general GIS user queries are expressible in the Geo-SQL. Later, when Open GIS consortium, led by major GIS and database vendors, proposed a specification for incorporating 2D geo-spatial ADTs in SQL, the Geo-SQL was revised. Hence, it can be easily shown that the Geo-SQL is a spatially complete language as it conforms to the spatial constructs given by the Open GIS [6]. A brief overview of the kind of constructs Geo-SQL has and what they mean are summarized below. Full details of all the constructs are available in the online Geo-SQL user manual provided with the system. 4.1 Geo-SQL Constructs Queries on Region: Create REGION region name FROM Path SET REGION region name CLEAR REGION region name DELETE REGION region name These constructs are provided for creating a region from a file containing spatial (vector) data of all layers and their associated non-spatial tabular data, setting a region for querying, clearing a region before ending a session and deleting a region completely. Create REGION is a construct which is very unique to this system. All the related map layers of a region ( may go up to 64 layers) with their attribute data are available in the Gram Vector Format file. Using a single create command, all the map layers get created in the Geo-BASE, with their related tables into the ODBC compliant DBMS. (The current implementation supports ORACLE and MS ACCESS as the destination DBMS, accepts input tables in DBASE or MS ACCESS format ). This feature is unique to this system as no currently available commercial GIS package supports this feature. Also the common tables which are sharable across different layers, get loaded into the backend database, with their relationships and constraints in tact. Queries on Layers CREATE LAYER layer name FROM Path CREATE LAYER layer name AS (Select Query) DELETE LAYER layer name The construct CREATE, is used for either adding a new layer externally or a new layer that results by the use of the predicates such as UNION, INTERSECT, OVERLAY. The Equals predicate will return the set of points/polygons that are equal

4 between two layers. Union and overlay predicates are the same in the case of points. But for lines and polygons, union is not applicable. The parser takes care of such semantic constraints. Select Queries SELECT projection attributes FROM table list [WHERE (nonspatial_predicate SBEGIN spatial_predicate SEND)+] ; Projection attributes:spatial_attributes Nonspatial_attributes Spatial_attributes:LENGTH(mapname1.maptype1, mapname2.maptype2) DISTANCE(mapname1.maptype1, mapname2.maptype2) Nonspatial_attributes:[aggregate_fn] mapname.attribute_name aggregate_fn: MAX MIN AVG mapname: name attribute_name: name maptype: POLYGON POINT POLYLINE table_list: name [,name]* All Non-spatial projections are the same as in standard SQL. In addition, the predicates that find relationships between objects such as WITHIN, CONTAINS, ADJACENT, MEETS, TOUCHES are introduced. The constructs MERGE and SPLIT are used in a polygon layer to take care of merging of adjacent polygons and splitting an existing polygon. The constructs LENGTH and DISTANCE are provided as predicates as well as functions. A buffer construct is introduced for lines and polygons to take care of queries such as find all the schools that are within a distance of 5Kms from highway #100. Another salient feature of the Geo-SQL is direction-based constructs. To show the elegance and power of the Geo-SQL, a sample query taken from a user site of ESRI s SDE is given below: Query: Find out all the areas where logging can be done with following constraints : 1. It should be within 5 kms from any road. 2. It should be away from water areas by a distance of 1 km. 3. It should be away from shrine by 10 kms 4. The area should be below snow line (1000) and its slope should be less than 5 degrees. The Geo-SQL query :- SELECT MAP(P.POLYGON) FROM Road, Water, Building, Snow, Slope WHERE Snow.snowline < 1000 AND Slope. Slope < 5 AND Building.uid = shrine AND SBEGIN P = INTERSECT( BUFFER(Road.POLYLINE,5), SEND NOT (BUFFER(Water.POLYGON,1)), NOT (BUFFER(Building.POINT,10)), Snow.POLYGON, Slope.POLYGON) The above said query is expressible as a single query using Geo- SQL, whereas the same query will require many statements, each statement to take care of a single spatial construct, in other GIS packages. Allowing multiple spatial constructs in a single query is a unique feature provided in Geo-SQL. Many sophisticated queries involving multiple invocation of spatial and non-spatial constructs have been tested during implementation. 5. COMPONENTS OF Geo-BASE The Geo-Spatial Data Management System comprises of a Geo- SQL Parser, a query planner, query optimizer, and query executor to handle all Geo-SQL queries. The Geo-SQL Parser accepts a query string written in the Geo-SQL language and generates a parsed spatial tree for the spatial part of the query to be used by the executor and also returns the SQL string as such for accessing the ODBC compliant backend database. The Executor handles both DDL and DML queries for the spatial and non-spatial parts of the query. It receives the spatial parse tree and the SQL statements from the Geo-SQL parser and generates an execution plan, which in turn gets optimized. The optimized query is then executed. Results of the executor are written in a workspace comprising of attribute data outputs, spatial outputs and errors detected if any, that are to be picked up by the GIS applications. The Geo-SQL parser is capable of detecting errors that arise due to (1) syntax and (2) semantic. Semantic error includes notifying that a particular spatial operation is not applicable to Point type and so on. A variety of algorithms have been developed and implemented as part of the Geo-BASE. The list of these algorithms with a brief description is given below: 1.Algorithm for Create Region This algorithm is used for converting the map layers data of a region (given in the vector format) and their associated tabular data (given as Dbase or MS ACCESS files), into tile form and associated relation tables of any ODBC compliant RDBMS respectively. The spatial data is stored in tiles. The information such as Maximum, Minimum of the earth co-ordinates of the region is stored in the corresponding region file. In case the map layer is of polygon type, then separate files are maintained to notify the tiles in which each of the polygon is lying and the hole information. These are used in filtering out the unwanted polygons while processing the queries. 2. Algorithm for overlay A new algorithm for vector data, which is simple and elegant, is developed] to take care of Overlay of two layers (available in vector format) of Polygon type in polynomial time. This algorithm uses the underlying tile structure effectively to filter out unwanted polygons. The algorithm also takes care of holes in multilevel. The new layer is created and its topology and the

5 related attribute data table are added into the spatial database. The new layer is also stored in the Vector file back. Overlay of point layers is also developed. Both the algorithms are tested on various real data. 3.Algorithm for intersection of two layers A new algorithm is used for finding the intersection of two layers of polygonal type based on non-spatial selections done on the individual layers. Besides these, algorithms for Equals, within, adjacent, touches, length etc are developed using simple algorithms of computational geometry. Buffer of a polyline, polygon have been developed and the resulting shapes were tested using the visual test tool called Geosoft, developed along with Geo-BASE[9]. The testing for the same was also performed using ARC INFO and the resulting polygons were found extremely satisfactory. 4. Query processing Algorithm A brief idea of the query-processing algorithm is given below: - Any query Q is a union of a spatial sub query SQ and a nonspatial sub query NQ. The Geo-SQL preprocessor will take Q and generate SQ and NQ. The query processor will append all the selected layers SID to NQ and sends to the backend DBMS through ODBC. From the result, the query processor will find out for each of the spatial constructs the list of SIDs, and send to the spatial side the relevant SQ part, along with the SIDs appropriately attached. After processing is over on the spatial side, once more, a modified NQ is constructed, including the spatial results as tables. The backend DBMS processes the query and sends the result. The query executor then processes this result which then be appropriately handled by the spatial display routines and the routines managing the attribute data. Depending on the kind of constructs, it could be a three way or four way processing. In case of a not operator appearing in the spatial part say not SQ, the query processor works in the following way:- Process the SQ Take the negation of the result from the Sid set, of the underlying layers and fill the temporary tables. 6. CONCLUSIONS The Data Management System has been implemented in the Windows NT environment using Visual C++ version 6.0, WINDOWS SDK tools and ODBC libraries. The Geo-SQL parser is developed using LEX and YACC in UNIX based M/c and later ported onto the Windows NT. The system is developed with both ORACLE and MS ACCESS as the backend database and the attribute data can be taken from DBASE or MS ACCESS or any ASCII data. The APIs to be used by GIS application developers is implemented as DLL functions. The constructs of the Geo-SQL conform to the standards specified by OGIS. The Data management system is tested extensively for a wide range of queries and now Version 1 is released to the GIS developers. The user can query the system using a GUI and the results are shown as map display. Further enhancements are in the direction implementation of certain constructs such as complement of a spatial object(t topologically), touches and equals; View management and security maintenance will also to be incorporated. 7. REFERENCES 1. Claudio Esperance & Hanan Samet, An overview of the SAND Database system,technical Report, Computer Science Dept., University of Maryland. 2. ESRI, Spatial database engine, Technical document, Max. J. Egenhofer, spatial SQL : A query and presentation language, IEEE Trans on knowledge and Data egg, Vol. 6, No 1, Feb Nabil. R. Arya Gangopadhyoy Database issues in GIS, Kluber Academic Publishers, Nick Roussopoulous, Steve Kelley PSQL : An inexpensive GIS solution for ORACLE, Advanced Communication Technology INC., Report Open GIS Simple Features specification for SQL, Open GIS, consortium Inc, 1998, ORACLE & spatial cartridge, Advances in Relational Database Technology for Spatial Data Management, An ORACLE Technical white paper, June S.Shekhar, S. Rawada etal, Spatial Databases : Accomplishments & research needs AHPCRC pre-print , University of Minnesota, Sep Shirwaikar, H.Diwakar, A graphic test tool for Geo-SQL in spatial data base management system,third IAPR international workshop on Graphics recognition, GREC 99,Jaipur,India,1999.