Spatial database

Spatial databases, also known as geo-databases, are implemented directly on existing DBMSs using extension software to allow them to handle spatial objects.

With raster representations, each raster cell stores a characteristic value. This value can be used to look up attribute data in an accompanying database table. For instance, the land use raster of Figure 1 indicates the land use class for each of its cells, while an accompanying table provides full descriptions for all classes, perhaps including some statistical information for each of the types. Note the similarity with the key/foreign key concept in relational databases.

With vector representations, our spatial objects—whether they are points, lines or polygons—are automatically given a unique identifier by the system. This identifier is usually just called the object ID or feature ID and is used to link the spatial object (as represented by vectors) with its attribute data in an attribute table. The principle applied here is similar to that in raster settings, but in this case each object has its own identifier. The ID in the vector system functions as a key, and any reference to an ID value in the attribute database is a foreign key reference to the vector system. For example, in Figure 2, Parcel is a table with attributes, linked to the spatial objects stored in a GIS by the Location column. Obviously, several tables may make references to the vector system, but it is not uncommon to have some main table for which the ID is actually also the key.

There are several advantages in doing this, as we will see below. Put simply, spatial data can be stored in a special database column, referred to as the “geometry” or “feature” or “shape data type”, depending on the specific software package. This means GISs can rely fully on a DBMS support for spatial data, making use of a DBMS for data query and storage (and multi-user support), and a GIS for spatial functionality. Small-scale GIS applications may not require a multi-user capability; these applications could be supported by spatial data support from a personal database.

A spatial database allows a wide variety of users to access large data sets (both geographic and alphanumeric) and manage their relations, while guaranteeing their integrity. The Open Geospatial Consortium (OGC) has released a series of standards for geographic data formats that (among other things), define:

• which tables must be present in a geo-database (i.e. a geometry columns table and a spatial reference system table);

• the data formats, called “Simple Features” (i.e. point, line, polygon, etc.);

• a set of SQL-like instructions for geographic analysis.

The architecture of a spatial database differs from a standard relational DBMS not only because it can handle geometry data and manage projections, but also because of the availability a larger set of commands that extend the standard SQL language (distance calculations, buffers, overlay, conversion between coordinate systems, etc.). A geo-database must provide a link between the spatial data represented by rasters or vectors and their non-spatial attribute data.

The capabilities of spatial databases will continue to evolve over time. Currently, ESRI’s ArcGIS “Geodatabase” can store topological relationships directly in the database, providing support for different kinds of features (objects) and their behaviour (relations with other objects), as well as ways to validate these relations and behaviours. Effectively, this is the same type of functionality offered by traditional DBMSs, but with geospatial data. Currently, some spatial database packages, such as PostGIS, have full 3D support, as opposed to the 2D support offered by many.