Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

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?

share|improve this question
+1 Would be interested in hearing alternatives to Clementini Operators –  Kirk Kuykendall May 23 '11 at 15:40
@whuber, I should have been more specific. I'm interested in alternatives to Clementini operators in ArcGIS queries, or queries against databases to which ArcGIS can connect. While at first glance Clementini seems both human and machine readable, as a human I often have difficulty. –  Kirk Kuykendall May 23 '11 at 16:20
@Kirk OK, but it seems that ArcGIS is having the difficulties, not you! :-) It is interesting that Clemintini et al end their original paper with the remark "Another point in our wish list is related to test if the calculus-based method is really suitable for end-users." –  whuber May 23 '11 at 17:33
@Matthew Could you be a little clearer about the scope of "questions" in which you are interested? For example, are you mainly interested in questions that are answered by discovering and processing spatial relationships among features (which presumably would need the power of GIS to carry out) or would it suffice just to look up static attributes of individual named entities or locations (which need no spatial processing)? –  whuber May 23 '11 at 17:43

2 Answers 2

up vote 6 down vote accepted

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.

share|improve this answer
So beyond the dimensionally extended nine-intersection model we can only express questions in forms that are borrowed from other domains? –  Matthew Snape May 24 '11 at 11:44
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). –  geographika May 24 '11 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.

share|improve this answer
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 '11 at 17:40
@whuber. Ok, thanks for the tip. I'll take that into account for future answers. –  Pablo May 23 '11 at 18:01
+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. –  Kirk Kuykendall May 23 '11 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 '11 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. –  Kirk Kuykendall May 23 '11 at 22:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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