Spatial Information Systems (SIS) Spatial data modelling COMP 30110 Spatial data modelling GIS and SDBMS

Spatial data modelling Spatial data models must allow the representation of the spatial extent of data and support spatial queries Two types of models: Object-based model: also called entity-based or feature-based Field-based model: also called space-based

Object-based model Individual objects are represented explicitly using their geometric counterpart The representation of the spatial extent (e.g., lines representing the boundary of a lake) using directed line segments (vectors) has given rise to the term vector model More suitable for applications requiring high quality cartographic operations, coordinate geometry, and networks

2D Vector-based representations Primitive spatial data objects are points, lines and polygons located by Cartesian coordinates in a spatial reference frame These geometric primitives indicate static locations and spatial extents of geographic phenomena in terms of XY coordinates

2D Vector-based representations Point object marks the location of a geographic entity (e.g., a paper mill) by a pair of XY coordinates Line object shows location and linear extent of a geographic entity (e.g., a river) by a series of XY coordinates Polygon object shows location and 2D extent of a geographic area (region), e.g. a lake, by a series of XY coordinates along the boundary of the region. major road river minor road A B creek mouth paper mill lake creek

Field-based model The underlying (geographic) space is partitioned (also tesselated) into cells that cover it entirely. Spatial objects are embedded in the space and are described and manipulated in terms of the cells they intersect. Example: lake described by the cells that cover its interior rather than by the lines that form its boundary

Raster-based representations Usually the partition is composed of polygonal units of equal size (fixed or regular grid: raster) Each cell in the grid has two associated values: a positional value that marks its identity attribute values of the underlying area it represents (e.g. land elevation, land use, etc.)

Spatial data formats Vector Raster

Spatial data in vector format Sets of spatial entities (points, lines, regions) and spatial relations e.g. geographic maps, digital terrain models, etc.

Spatial Relations Topological Relations: containment, overlapping, etc. [Egenhofer et al. 1991] Metric Relations: distance between objects, etc. [Gold and Roos 1994] Direction Relations: north of, south of, etc. [Hernandez et al. 1990; Frank et al. 1991] A B 1 Km A B A B

Spatial data in raster format Sets of pixels e.g. satellite images, aerial photos, scanned maps

DBMS: motivations Organizations depend on the ability to efficiently – acquire, – manage, and – analyse (spatial) data. Data Management Aspect: – Data needs to be accurate and timely, and also stay accurate even if many people access and use the same data – Amount of spatial data is exploding – how to find data ?! Data Analysis Aspect: – Quickly find the data that is relevant to a given question powerful data management systems are needed

DBMS and Spatial Data In a GIS/SIS we need to store and manipulate both spatial and non-spatial data Storage can be controlled directly by applications programs or by a DBMS Early GIS built directly on top of file systems: No DB used Spatial and non-spatial data both stored in files controlled by the application Functions are defined on the data Problem with this approach: no data independence, data security, concurrency Solution: using a DBMS

Use of Relational DBMS Each relation/table represents a theme (e.g., country, landuse, etc.) A geographic object is a tuple/row of such relation Each column is an attribute Attributes have alphanumeric types (non-spatial aspects) SQL-based querying

Example COUNTRIES BOUNDARIES name capital population Id-boundary Germany Berlin 78.5 B1 France Paris 58 B2 … Id-boundary Id-contour B1 C1 B2 C2 C3 B3 C4 C5 … CONTOURS Id-contour Point-num Id-point C1 2 P1 1 P2 3 P3 … C2 P4 P5 POINTS Id-point x y P1 452 1000 P2 365 875 P3 386 985 P4 296 825 P5 589 189 …

Example (cont.d) Relation COUNTRIES with schema (name, capital, population, id-boundary) Id-boundary is the spatial attribute corresponding to the boundary of the country A boundary is made of several components (contours) when a country is made of several parts. A contour is characterised by an Id and a list of points, each of which is stored in relation Points. Point-num is used to represent an ordering of the points along the boundary of a country. For example, contour C1 is represented by the sequence {P1,P2,P3} of points, although the points are not stored in that order

Example (cont.d) Querying via SQL: “Return the contours of Italy” select B.Id-contour, point-num, x, y from COUNTRIES C, BOUNDARIES B, CONTOURS CT, POINTS P where name=‘Italy’ and C.Id-boundary=B.Id-boundary and B.Id-contour=CT.Id-contour and CT.Id-point=P.Id-point order by B.Id-contour, point-num The query involves retrieving the set of coordinates of the vertices on the boundary of the polygons (objects) that represent Italy

Use of relational DBMS: pros & cons PRO: use of standard DBMS and languages (SQL) CONS: Querying requires knowledge of the structure of the spatial objects (no data independence from this point of view) Representing spatial information requires a large amount of tuples (inefficient) Need to manipulate (possibly very large) tables of points (no user friendliness) Difficult to perform spatial computations (e.g., “when are two objects adjacent?”) and to define new “data types” for spatial objects Spatial queries (see example) are not directly supported and require join of several different tables (inefficient)

Loosely coupled approach Separation between spatial and non-spatial data Approach used by the majority of traditional GIS vendors (ESRI, MapInfo, Intergraph, etc.) Two systems coexist: - A (usually relational) DBMS, or some component of it for descriptive alphanumeric data A specific module for spatial data management Application programs DB files Relational DBMS (standard SQL) Spatial data processing

Loosely coupled approach: pros & cons Proper geo-spatial data management Spatial queries are directly supported Cons: difficulty in modeling, using and integrating heterogenous models within the same system partial loss of basic DBMS functionality (e.g., for querying spatial data) need to learn complex sw packages

Integrated approach: SDMS Based on DBMS extensibility Main concept: ability to add new types and operations to existing relational DBMS For geo-spatial applications, extensions to relational DBMS include: extension of the query language SQL to allow for manipulation of spatial data as well as descriptive data. New spatial types (points, lines, and regions) should be handled as alphanumeric types adaptation of usual DBMS functions (such as indexing, query optimisation) in order to handle also spatial data efficiently Only few of the available DBMS offer a spatial extension: Oracle 8i/9i (more later) Postgres

Summary: GIS vs SDBMS Classical GIS systems adopt a hybrid management for data Non-spatial (attribute) data is stored in “standard” DB Spatial data is stored in proprietary (vector) files and spatial objects in these files are linked to tables containing corresponding attribute information SDBMS adopt an integrated approach Better for data integration but still “behind” from the point of view of functionality (will see Oracle Spatial later)