Department of Geoinformation Science Technische Universität Berlin Geo-Databases: lecture 8 Management of Spatial Data Prof. Dr. Thomas H. Kolbe Institute for Geodesy and Geoinformation Science Technische Universität Berlin Credits: This material is mostly an english translation of the course module no. 8 (‘Geo-Datenbanksysteme‘) of the open e-content platform

2 T. H. Kolbe – Geo-Databases: lecture 8 Department of Geoinformation Science 14/11/2006 Management of spatial data

3 T. H. Kolbe – Geo-Databases: lecture 8 Department of Geoinformation Science 14/11/2006 Motivation The purpose of a Geographic Information System is the integrated management of spatial and thematic data. Additional requirements wrt. general information systems are:  Representation of spatial data: All forms of spatial data that are relevant for the application must be storable in the system, e.g. property boundaries  Spatial queries: The information system should support queries with spatial reference or context Which properties lie next to a main road?  Integration with thematic data: users must be given the ability to combine thematic and spatial data in an adequate form. E.g. associate property boundaries with owner, bulding characteristics, etc. In queries like: Which properties in corporate ownership lie next to rivers?

4 T. H. Kolbe – Geo-Databases: lecture 8 Department of Geoinformation Science 14/11/2006 Forms of Integration The task of integrated management of spatial and thematic data can be solved in different ways:  Thematic data can be managed on the basis of existing DBMS data models (e.g. relational model).  Spatial data may be integrated in different ways: 1. by employing a DBMS data model 2. by separate management in a specialised storage system 3. by extending a given DBMS data model In this lecture: Brief review of solution 1) and deeper investigation of 3), which offers advantages in many aspects.

5 T. H. Kolbe – Geo-Databases: lecture 8 Department of Geoinformation Science 14/11/2006 Utilisation of the Relational Model, Example In the design process of a database schema for a Geographic Information System, spatial data structures can be modeled just as thematic data structures: 1. Creation of a conceptual model, e.g. using UML 2. Transformation into the relational data model Example: modelling of a type for polygons with non-redundant point management node see node

6 T. H. Kolbe – Geo-Databases: lecture 8 Department of Geoinformation Science 14/11/2006 Utilisation of the Rel. Model - Discussion Although spatial data can be represented this way, a number of important questions arise:  Is the reconstruction of the geometry via selection and join as efficient as having a “native“ support?  Index support for spatial queries?  Operations and predicates have to be evaluated outside of the DBMS!  Violation of data independence: reorganisation of storage structure requires changes to the application programs. Significant improvement: specific spatial data types, which are implemented as so called abstract data types (ADT) within the DBMS.  Usage in analogy to primitive SQL data types  Spatial index structures can be used within the query process  Spatial operators and predicates may be evaluated using special algorithms within the DBMS

7 T. H. Kolbe – Geo-Databases: lecture 8 Department of Geoinformation Science 14/11/2006 Abstract Data Types (1) An abstract data type (ADT) is an implementation independent representation of a set of value domains and operations to form a unit. In our context ADTs have the following desirable characteristics:  Complex data types are easier to use: a polygon type may for example be used to specify the value domain for a column in a relational schema  Encapsulation: The internal data structure is hidden from the user  Interface: The access from outside is limited to predefined operations  Interface and implementation are separated (on the conceptual level)

8 T. H. Kolbe – Geo-Databases: lecture 8 Department of Geoinformation Science 14/11/2006 Example for Abstract Data Types (Polygon) The actual data structure of the abstract data type POLYGON is hidden to the outside. A comprehensive specification for the embedding of spatial types into SQL- DBMS is provided by the Open Geospatial Consortium (OGC).

9 T. H. Kolbe – Geo-Databases: lecture 8 Department of Geoinformation Science 14/11/2006 OGC Simple Features The Open Geospatial Consortium (OGC) is a non-commercial organisation, consisting of authorities, companies and universities. Among other things, OGC offers the Simple Feature Specification for SQL:  Describes a set of geometry data types for SQL based on the OGC geometry model  Describes a set of SQL operations on these types Characteristics:  Term “feature“: abstraction of a phenomenon of the real world (“geo-object“); a feature is stored as a dataset in a feature table  Modelling of the geometry of spatial objects: Only 0-2 dimensional objects Only linear interpolation between points No explicit representation of topology

10 T. H. Kolbe – Geo-Databases: lecture 8 Department of Geoinformation Science 14/11/2006 Simple Features Geometry Model (1) Hierarchy of geometry classes for 0-2 dimensional objects (according to OGC):

11 T. H. Kolbe – Geo-Databases: lecture 8 Department of Geoinformation Science 14/11/2006 Characteristics of the Class “Geometry“  It is the superclass of the entire hierarchy; it is abstract, that means that no instances can be created from that class  It supports different operations in the following areas: Basic operations Testing of topological relationships Spatial operations  Each object of this type is assigned a spatial reference system (class SpatialReferenceSystem ).  The subclass GeometryCollection represents sets of simple geometric objects. Such sets also belong to the type Geometry. All elements of a GeometryCollection must refer to a common spatial reference system.

12 T. H. Kolbe – Geo-Databases: lecture 8 Department of Geoinformation Science 14/11/2006 Basic Operations The OGC specification defines the following basic operations (g stands for a geometry).  Dimension(g) : returns the dimension of the geometry g  GeometryType(g) : returns the name of the geometric type of g (e.g. LINESTRING, POLYGON, MULTICURVE, …)  AsText(g) : converts the geometry g into the “SQL text format“ for export into other applications (e.g.: POLYGON(0 0,0 1,1 1,1 0,0 0))  AsBinary(g) : converts g into binary format (also specified) for export into other applications  SRID(g) : returns the ID of the spatial reference system of g  IsEmpty(g) : tests, if g is empty  IsSimple(g) : tests, if g is simple (defined in the OGC geometry model)  Boundary(g) : generates a common contour of an object  Envelope(g) : generates a minimal enclosing, axis-parallel rectangle around an object (“minimum bounding rectangle“, MBR)

13 T. H. Kolbe – Geo-Databases: lecture 8 Department of Geoinformation Science 14/11/2006 Predicates for Testing Topological Relationships In an OGC conforming SQL environment the user is also given the ability to test topological relationships. Example: Through which cities flows a river? SELECT cities.name FROM Cities JOIN Rivers ON CROSSES(Cities.Geometry, Rivers.Geometry)=1 The operations relating to topological relationships are based on the so called „dimension extended nine intersection model“ and are directly available in SQL queries like in the example (for details see literature).

14 T. H. Kolbe – Geo-Databases: lecture 8 Department of Geoinformation Science 14/11/2006 Testing Topological Relationships (2) The predicates in detail: the parameters are in each case two geometries, the return value is an integer : 0/1 for: The relationship between spatial objects is not true / is true -1 for: unknown, that means one of the arguments contains NULL value  Equals(g1,g2) : g1 and g2 are spatially identical  Disjoint(g1,g2)  NOT Intersects(g1,g2) : g1 and g2 are spatially disjoint  Touches(g1,g2) : The boundaries of g1 and g2 intersect but not their interior  Crosses(g1,g2) : The dimension of the intersection of g1 and g2 is lower than the maximum dimension of g1 and g2 and the intersection comprises interior points of g1 and g2 and the intersection is not equal to g1 or g2.  Within(g1,g2)  Contains(g2,g1) : g1 lies fully within g2  Overlaps(g1,g2) : The dimension of the intersection of g1 and g2 equals the dimension of g1 and g2 and the intersection is not equal to g1 or g2.

15 T. H. Kolbe – Geo-Databases: lecture 8 Department of Geoinformation Science 14/11/2006 Spatial Operations The metric operation Distance computes the shortest distance between two geometries in the corresponding reference system. The following operations generate new geometric objects:  Buffer(g,d): computes the geometry of a buffer of size d around the geometry g.  ConvexHull(g): Computes the geometry that is the convex hull of g.  Intersection(g1,g2) : computes the geometry formed by the intersection of g1 and g2.  Union(g1,g2): Computes the geometry formed by the set union of g1 and g2.  Difference(g1,g2): Computes the geometry formed by the (closed!) difference set of g1 and g2 ( g1-g2 )  SymDifference(g1,g2): Computes the geometry formed by the (closed!) symmetric difference set of g1 and g2

16 T. H. Kolbe – Geo-Databases: lecture 8 Department of Geoinformation Science 14/11/2006 Geometric Types in SQL Text Format For data exchange and for construction of geometric objects, for example in queries, the OGC-specification provides a text format – the so called “Well- known text representation (WKT)“. Examples: Geometric typeSQL text formatComment Point POINT(10 10) A point LineString LINESTRING(10 10,20 20,30 40) A LineString with 3 points Polygon POLYGON((10 10,10 20, 20 20,20 15,10 10)) A Polygon Multipoint MULTIPOINT(10 10, 20 20) A MultiPoint with 2 points MultiLineString MULTILINESTRING((10 10, 20 20),(15 15,30 15)) A MultiLineString with 2 LineStrings Geometry Collection GEOMETRYCOLLECTION (POINT(10 10), POINT(30 30), LINESTRING(15 15, 20 20)) A GeometryCollection comprising 2 points and one LineString

17 T. H. Kolbe – Geo-Databases: lecture 8 Department of Geoinformation Science 14/11/2006 Insertion of a Polygon using SQL Paunzhausen8500 POLYGONFROMTEXT : Translates SQL text data into a polygon!

18 T. H. Kolbe – Geo-Databases: lecture 8 Department of Geoinformation Science 14/11/2006 Query: Printing a Geometric Object Desired: The polygon that marks the city Paunzhausen is to be printed in SQL text format. SELECT Name, ASTEXT(Geometry) FROM Cities WHERE Name = "Paunzhausen" Result:

19 T. H. Kolbe – Geo-Databases: lecture 8 Department of Geoinformation Science 14/11/2006 Queries for Testing Topological Relationships Wanted: What lakes lie (completely) within the states Hessen or Bavaria? SELECT Seen.Name FROM Seen JOIN Laender ON (Laender.Name='Hessen' OR Laender.Name='Bavaria') AND WITHIN(Seen.Geometry, Laender.Geometry)=1 Wanted: What cities are neighboured to "Paunzhausen"? SELECT b.Name FROM Orte o1 JOIN Orte o2 ON o1.Name="Paunzhausen" AND TOUCHES(o1.Geometry, o2.Geometry)=1

20 T. H. Kolbe – Geo-Databases: lecture 8 Department of Geoinformation Science 14/11/2006 Query Type: Spatial Join One of the most important query types in spatial databases is the spatial join: A spatial join is a “general“ join, that comprises a spatial predicate within the query condition. Example: Through which cities flows a river? SELECT Cities.Name, Rivers.Name FROM Cities JOIN Rivers ON crosses(Cities.Geometry,Rivers.Geometry)=1 set of objects 1 (Cities)set of objects 2 (rivers) Computing of MBBs (Minimal Bounding Boxes)! Computing potential candidates via MBBs! (efficient algorithms of the DBMS avoid comparison of all pairs) No candidate if MBBs don‘t intersect! Which objects do really intersect? Return of object pairs!

21 T. H. Kolbe – Geo-Databases: lecture 8 Department of Geoinformation Science 14/11/2006 References Overview:  Richard Groot, John McLaughlin, Geospatial Data Infrastructure: Concepts, Cases and Good Practice, Oxford University Press, New York, 2000  Philippe Rigaux, Marc Scholl, Agnes Voisard, Spatial Databases - With Applications to GIS, Morgan Kaufmann, 2002, Seite Original work:  Open GIS Consortium, OpenGIS Simple Features Specification for SQL, http://  E. Clementini, P. Di Felice, A Comparison of Methods for Representing Topological Relationships, Information Sciences 80, 1- 34, 1994  E. Clementini, P. Di Felice, A Model for Representing Topological Relationships Between Complex Geometric Features in Spatial Databases, Information Sciences 90 (1-4): , 1996