A core concept of GIS is answering questions about datasets. From the point of view of a database; SQL with spatial extensions is a way of asking such questions. What other ways can questions be expressed in a machine readable text based form? What are the benefits of different approaches?


2 Answers 2


I can only think of 3 types of spatial query, ignoring any attribute or hash based queries.

  1. Spatial queries based on geometry, and are used to find the relationships between vector features. SQL spatial queries are really just an API low level alogorithms such as Bentley-Ottmann - used in OpenLayers to check if two lines intersect.

    As Kirk mentioned the types of relationship between features have standardised on the dimensionally extended nine-intersection model:

    • Equals
    • Disjoint
    • Intersects
    • Touches (meets)
    • Crosses
    • Within (inside)
    • Contains
    • Overlaps
    • Covers
    • CoveredBy

    It can be argued that Spatial queries based on indexes are a simplified form of geometry queries. Most geometry queries use a spatial index as a first pass query to filter out irrelevant features before comparing individual geometries which is more time consuming. These are also implemented in NoSQL databases such as MongoDB.

  2. Spatial queries based on graph theory. These types of query are implemented in GIS through tools such as Network Analyst, and again at a low level are algorithms.
  3. Spatial queries based on raster grids and set theory (and fuzzy set theory).

There are a few implementations that combine the above, such as StarSpan that combines raster and vector queries - although it really hides a preprocessing step.

There are numerous APIs that implement these types of queries that are both machine and text readable. There's a good discussion on different implementations and their problems here.

The paper Towards a 3d Spatial Query Language breaks spatial operators into 4 types, based on the query rather than datatype (which perhaps makes more sense):

  1. directional operators (such as above, below, northOf, southOf)
  2. topological operators (such as touch, contain, equal, inside)
  3. metric operators (such as distance)
  4. Boolean operators (such as union, intersection)

It also brings in terminology to deal with 3d features (body and surface), which are not included in DE-I9M.

  • So beyond the dimensionally extended nine-intersection model we can only express questions in forms that are borrowed from other domains? May 24, 2011 at 11:44
  • 1
    Define your question in any GIS domain specific language you wish, but in the end the machine will query using one of the above methods (although I may be missing a few). May 24, 2011 at 12:27

1 - There are some studies with this software: http://nlp.uned.es/MLQA06/papers/ferres.pdf
Despite it's more related to internet searches, it could provide some guidance on how to translate human language to computer language.
Googling 'GeoTALP-Q' also provides more articles on the subject.

2-GeoDjango provides an API for spatial queries, it's a translation from SQL to a Object Oriented language that can speed up a lot of tedious work like writing PL/python functions for complex spatial queries. It's limited by the database you use.

  • That's an interesting find. Because we like this site to stand alone and provide immediately useful answers, it is best to accompany a reference like this with your own summary of its relevant conclusions. Could you do this here? My very quick perusal of the paper suggests it may be focusing more on extracting geographic attributes from Web-based data rather than on processing queries about spatial relationships.
    – whuber
    May 23, 2011 at 17:40
  • @whuber. Ok, thanks for the tip. I'll take that into account for future answers.
    – Pablo
    May 23, 2011 at 18:01
  • 2
    +1 The unfortunate thing about SQL is that so many of its spatial-sounding reserved words have little or nothing to do with space: WHERE, FROM, IN etc. May 23, 2011 at 20:22
  • @Kirk Funny, I never thought of it, that way. The difference between location and space is enough to give a guy a headache. :)
    – Nathanus
    May 23, 2011 at 22:01
  • @nathanus Yeah, and then there's even the notion of lexical distance between two soundexes which can be used by a dbms to find the closest matching street. May 23, 2011 at 22:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.