10
Codd’s Rules Codd’s Rules for for Spatial ORDBMS” Spatial ORDBMS” How the assumptions of the Relational Model have been relaxed to accommodate geographic data Spatial ORDBMS implementations with Oracle Spatial, PostGIS, and ArcSDE Matt Stuemky Presentation based on Final Paper GEOG 582 (Spring 2008) University of Southern California Department of Geography May 13 2008 1

“Codd’s Rules for Spatial ORDBMS” How the assumptions of the Relational Model have been relaxed to accommodate geographic data Spatial ORDBMS implementations

Embed Size (px)

Citation preview

““Codd’s Rules Codd’s Rules for for

Spatial ORDBMS”Spatial ORDBMS”How the assumptions of the Relational Model have been

relaxed to accommodate geographic data

Spatial ORDBMS implementations withOracle Spatial, PostGIS, and ArcSDE

Matt Stuemky

Presentation based on Final Paper

GEOG 582 (Spring 2008)

University of Southern CaliforniaDepartment of Geography

May 13 2008 1

Some issues and challenges with storing Some issues and challenges with storing geographic data in a RDBMSgeographic data in a RDBMS

Traditional relational model is excellent for storing and managing business and transactional data, not as well- suited for handling spatial data

Spatial data, even simple features (geometry - points, lines, and polygons), are more complex than business data

Going beyond storing just vector-based spatial data: how to efficiently store complex, raster-based spatial data?

All spatial ORDBMS should incorporate SQL-99 MM Spatial / Open Geospatial Consortium (OGC) standards and specifications to assure interoperability & consistency

OODBMS? Why are ORDBMS products favored over true object-oriented DBMS? “Square pegs into round holes”

Support object-oriented concepts such as objects, classes, methods, properties, and inheritance

RDBMS vendors provide high performance, high security, scalable, very reliable RDBMS products that IT industry has gotten very familiar with for several decades, including for GIS usage

Easier for RDBMS vendors to incorporate basic OO concepts into their existing products and provide support for complex data types compared to new vendors introducing true OODBMS solutions

2May 13 2008

Database

Spatial ORDBMSobject-relational

database management system

• Storage• Indexing• Security• Backup• Versioning• Long transactions

Spatial ORDBMS vendor solutionsSpatial ORDBMS vendor solutions

Middleware solutions ESRI: ArcSDE

Spatially enables RDBMS including ESRI file geodatabases, Oracle, IBM DB2, Informix,and SQL Server

◦ MapInfo: Spatialware

Integrated server solutions◦ Oracle: Oracle Spatial

◦ PostgreSQL: PostGISopen-source spatial ORDBMS solution

◦ Microsoft: SQL Server Spatial(coming, late as usual, in 2008)

3May 13 2008

Oracle

RDBMS

ArcSDE

Oracle Spatial

PostgreSQL

PostGIS

Some advantages of direct integration:

All DBMS core capabilities including security, replication, use of triggers in one place

A common DBMS interface and tools to access both spatial and non-spatial data

Rule 1: Basic framework for spatial databasesRule 1: Basic framework for spatial databases

Enhancement of Codd’s First Rule: The Information Rule

Spatial ORDBMS must be able to support the storage of geospatial data; all subsequent “rules” are the detailed specifications that support this first rule.

Spatial databases in ORDBMS must support (at minimum):

Complex (geometry) data types Spatial data within related tables – feature classes, feature datasets Validation rules - subtypes and domains Spatial metadata Spatial reference (coordinate) systems and transformations Topologies and methods for analyzing spatial relationships Geometric networks Multi-dimensional, hierarchical indexes for searching spatial data Storage of both spatial and non-spatial data in the same database

4May 13 2008

PARCEL features

Instances of a Feature class

Instances of an Object class

Rule 2: Simple features and geometry data typesRule 2: Simple features and geometry data types

Abstract real-world spatial information into distinct, identifiable entities – objects for representing real-world geographic features (Shekhar & Chawla, 2003)

Amendment to the relational model: support for geometry data types, including points, lines, polygons, and aggregations of these

Conform to the Open Geospatial Consortium (OGC) Simple Features standard

Complex (composite) objects, representing real-world geographic features, can be created by incorporating these spatial data types.

Examples: Roads from lines, Parcels from polygons, etc.

Instances of these spatial objects must be able to be stored and managed within the logical framework of relational tables.

5May 13 2008

Geometry object model

© 2005 John Wiley & Sons, Ltd

Rule 3: Comprehensive spatial data language Rule 3: Comprehensive spatial data language

Enhancement of Codd’s Rule #5: comprehensive data sublanguage and Rule #7: High-level insert, update, and delete

“Spatial SQL”: OGC specification, Simple Features for SQL (SFSQL)

Use of WKT (Well-Known Text) and WKB (Well-Known Binary) formats for inputting/outputting data

Basic methods for creating, updating and deleting spatial data using SQL syntax

Operators and methods for querying spatial data

Support for spatial analysis functions Examples: distance (between two points), length (of a line), area (of a polygon), buffer, etc.

6May 13 2008

PostGIS: Create a new table; add a spatial column (attribute) to it

PostGIS: Create a new instance of a Road feature (spatial object, linestring)

CREATE TABLE roads (road_id INTEGER,road_name VARCHAR);SELECT AddGeometryColumn( ’roads’, ’roads_geom’, -1, ’GEOMETRY’, 3 );

INSERT INTO roads (road_id, roads_geom, road_name)VALUES (1,GeomFromText(’LINESTRING(191232 243118,191108 243242)’,-1),’Jeff Rd’);

PostGIS:Select query

SELECT road_id, road_nameFROM roadsWHERE roads_geom ~= GeomFromText(’LINESTRING(191232 243118,191108 243242)’,-1);

Rule 4: Topologies and evaluation of spatial Rule 4: Topologies and evaluation of spatial relationshipsrelationships

Enhancement of Codd’s Rule #10: Integrity Independence

Spatial ORDBMS must support topologies Store / manage shared geometry (node, edge, and face elements) Enforce spatial data integrity rules

Examples: no gaps between parcels, no overlapping parcels, etc.

SQL operators and methods for evaluating spatial relationships

7May 13 2008

Equals – same geometries Disjoint – geometries share common point Intersects – geometries intersect Touches – geometries intersect at common

boundary Crosses – geometries overlap Within– geometry within Contains – geometry completely contains Overlaps – geometries of same dimension

overlap Relate – intersection between interior,

boundary or exterior

PostGIS:Select geometry objects based on spatial relationship with other geometry objects

SELECT id, the_geomFROM geotableWHEREthe_geom && ’POLYGON((0 0, 0 10, 10 10, 10 0, 0 0))’AND_ST_Contains(the_geom,’POLYGON((0 0, 0 10, 10 10, 10 0, 0 0))’);

Spatial relationship methods

Rule 5: Spatial access methods (SAMs)Rule 5: Spatial access methods (SAMs)

Single-dimensional index methods such as B-trees not sufficient for indexing spatial data; spatial ORDBMS must support multi-dimensional indexing

Common spatial access methods (SAMs): Grid, Point Quadtrees, Region Quadtrees, R-trees, and variations of these

Oracle Spatial primarily uses R-tree indexes but supports Quadtree-based indexes; PostGIS uses an R-tree index implemented on top of a GiST (Generalized Search Trees) index

8May 13 2008

© 2005 John Wiley & Sons, Ltd

Region Quadtree R-tree

No OGC-based standards for raster-based spatial data?

More complex implementation than simple (geometry) features

Support for storing both image-based (satellite remote sensing, airborne photos, etc.) and grid-based (digital terrain elevation, land cover information, etc.) raster data

ORDBMS raster architecture: Raster object type Indexing of raster data Raster metadata SQL API for inserts, updates, and queries

◦ Requires a substantial amount of storage space and numerous tables in database

Proprietary solutions: Oracle Spatial: GeoRaster; now available PostGIS: PGRaster is a very similar

implementation to Oracle’s GeoRaster; product is still under development

◦ Further demonstrates how far the relational model has been relaxed to accommodate geographic data

9May 13 2008

Rule 6: Raster-based geospatial featuresRule 6: Raster-based geospatial features

© 2008 Oracle Corporation

Enhancement of Codd’s Rule #11: Distribution Independence

Allow seamless storage, retrieval and exchange of data in spatially-enabled databases (queries with both homogonous and heterogeneous databases) across distributed systems, including network servers and the Internet for web-based systems.

Older OGC specifications for simple features distribution between applications and other RDBMS: OLE/COM and CORBA specifications Define how APIs should handle the storage, retrieval, and exchange of vector-based (point, line,

polygon) spatial data

Newer OGC standards and specifications for spatial data distribution on the Internet/World Wide Web: Web Feature Service (WFS) specification for simple features (vector-based) data Web Coverage Service (WCS) standard for raster-based data Geography Markup Language (GML) encoding standard for exchanging geospatial data

Oracle Spatial, PostGIS, and ArcSDE provide support for: Synchronized replication of spatial data between databases over local and wide area networks

(also: version reconciliation and long transaction support) Exchange of spatial data on the web using WFS, WCS and GML.

10May 13 2008

Rule 7: Spatial data across distributed systemsRule 7: Spatial data across distributed systems