Geography Reference
In-Depth Information
same things as a normal database, but use specialized processes that perform particular
operations in better, more efficient ways.
Looking at a GIS database through the lens of a non-GIS connection, the geometric data is
nothing more than a custom binary field, or blob, that the software and processes working
with the system know how to interpret. In fact, it's possible to take a normal database engine
and write your own routines, either in the database or in external code, to perform all of the
usual operations you would expect but with GIS data.
In general, when a database is spatially enabled, it will have much more than just the ability
to understand the binary data added to it. There will be extensions to the SQL language for
performing specialized GIS data operations, new types of indexes to help accelerate
lookups, and various new tables used to manage metadata pertaining to the various types of
GIS data you may need to store.
I'm not going to list every available operation in this topic, only the most important things you
need to know to get started. At last count, however, there are more than 300 different
functions in the last published OGC standards.
OGC What?
The OGC standards are the recommendations set by the Open Geospatial Consortium.
They define a common API, a minimum set of GIS-SQL extensions, and other related
objects that any GIS-enabled database must implement to be classified as OGC compliant.
Because of the diversity of GIS and their data, these standards are rigorously enforced. This
enables nearly every bit of GIS-enabled software on the planet to talk to any GIS-enabled
database and vice versa using a common language.
Note that when selecting a database to use, there are many that claim to be spatially aware
but are not OGC compliant. Prime examples are MS SQL and MySQL.
In general, MS SQL features the OGC-ratified minimum GIS-SQL and functional
implementation, but its calling pattern varies significantly from most GIS software. MS SQL
also features changes to column names in some of the metadata tables, which means most
standard GIS software cannot talk to a MS SQL server. Note also that MS SQL didn't add
any kind of GIS extensibility until 2008, and even in the newer 2008 R2 and 2012 versions,
the GIS side of things is still not completely OGC compliant.
MySQL has similar restrictions, but also treats a number of core data types very differently,
often leading to rounding errors and other anomalies when performing coordinate
conversions. You can find the full list of OGC standards documents on the OCG website at
A good place to look for information comparing various databases is on the BostonGIS
website at
There are also a number of other good starter articles on the site. The downside is that the
site is cluttered and sometimes very hard to read.
