When spatial technology is properly applied to the database almost all of the databases core capabilities can be extended to handle spatial data. This includes the database's scalability, security, and replication capabilities. An open spatial database also enables all of the applications that connect to the database to take advantage of the spatial capabilities. GIS intensive applications such as property mapping and maping of street networks are able to leverage the central database, resulting in a comprehensive spatial and non-spatial enterprise storage solution. However, traditionally non-spatial application such as a human resources application can also be easily modified to do things such as find the nearest co-worker to where an employee lives. While this is not one of the biggest areas that one would want to integrate spatial capabilities, it is a good example of what is possible once an enterprise's systems have been spatially enabled.
Without spatial capabilities the database cannot to anything beyond serve as a data store for point information. It cannot manipulate the data without additional GIS tools. It cannot store data such as lines and polygons, which often represent things such as roads and election districts. Without a spatially enabled database the capabilities available to the user are quite limited. This is what a spatial database is the cornerstone of spatially enabling the enterprise.
Evaluating spatial databases
When determining the approach that is best suited for an organization there are several factors that must be taken into account. If an organization has already established a database standard then there are options available from both GIS and database vendors. However, when considering which option to choose the most important things that must be considered are integration with non-spatial data inside of the RDBMS and the adherence to open standards.
Some spatial database systems use a middleware approach. This approach limits the integration of spatial and non-spatial data. While the spatial data gets stored inside of the database all manipulation must take place through the middleware layer. This approach restricts the users ability to access data directly from the database. Instead of choosing a middleware solution one should look at options that operate within the database kernel. This approach preserves all of the database's core capabilities including security, replication, the use of triggers, and use of the native database interfaces and tools to access the spatial data.
Additionally it is important that a spatial database adheres to open standards. By adhering to open standards one maintains flexibility and is able to acquire technology from a wide range of vendors who also support the standards. Adherence to open standards ensures interoperability.
What are the core components of a spatial database?
Although different vendors approach spatially enabling the database in different ways, there are several key components that must be present in order to fully leverage the power of the database to manage spatial data. There are three main components that should be present as part of the spatial relational database management system. These components include a spatial data type, a spatial indexing scheme, and spatial operators.
Spatial Data Type
The spatial data type allows the database to recognize points, lines, and polygons as spatial objects inside of the database. The database natively has the ability to recognize data types such as floats, integers, and chars. However a new type must be added in order for the database to comprehend spatial objects. The Open GIS Consortium (OGC) has defined a structure for a spatial data type. This type has been defined as an ST_Spatial type. The ST_Spatial type is comprised of point, line, and area types that can be combined to represent virtually any spatial object.
The second component of the spatial
database is the spatial index. Virtually all databases include indexing
schemes to enable quick lookup and retrieval of the data. However,
these schemes are designed to work with the native data types. The
nature of spatial information is quite different from traditional non-spatial
data. In an effort to enable users to quickly retrieve spatial data
from their database most vendors add a spatial index. There are several
different indexing schemes that are well suited for spatial data.
Recently there has been a move from B-trees or quad trees to R-trees as
the preferred indexing mechanism of spatial database and tools vendors.
The primary difference between these indexing schemes is the way that the
data is partitioned. The diagram below helps to illustrate these
various indexing schemes.
Spatial data types and spatial indexing allow data to be stored and retrieved from the relational database. However, this is useless unless you have a way to manipulate the data. Data manipulation occurs through the use of spatial operators. Spatial operators fall into several categories, which include spatial functions, predicates, measurement, constructor, and observer functions. The Open GIS Consortium (OGC) defines all of these functions, but they are extensible and some vendors offer more capabilities than others. All of these functions can be accessed using standard SQL commands.
Spatial functions allow users to perform operations such as creating a buffer around an object. Spatial functions take an input, perform an operation on that input, which in turn results in a new geometry.
Spatial predicates allow users to query the database to return a true or false answer. An example of a spatial function is "does voter a fall in election district x?"
Spatial measurements do what it sounds like they do. A spatial measurement can return the area or length of a given geometry.
Constructors allow users to create new spatial objects using SQL commands. By inputting X,Y coordinates a point can be created. A series of points can be inputted to create a line or polygon.
Observer functions can be used to determine the information about a given geometry. An observer function would be used to derive the X coordinate of a point or the starting point of the line.
When selecting the spatial database that will best suit an enterprises needs the operators are perhaps the biggest differentiator between products. The greater the number of operators available, the more ways one can manipulate the data.
In order to implement spatial capabilities on an enterprise wide scale, a spatially enabled RDBMS is a critical success factor. Look for products that will not only meet the needs of today, but also the needs of tomorrow. Products that leverage the database's core capabilities while adhering to open standards enable the enterprise to grow and meet present and future spatial needs.