Currently we use PostGIS to store thousands of MULTIPOLYGONs and we can then use ST_Intersects to return any that rows contain any point in an input collection of points. Are there any other open source databases that can support this type of functionality, or is this unique to PostGIS?
EDIT: WE need to have proper intersects functionality, not just MBR, all our geometries will be in 4326, and we are interested in solutions for mobile devices, going forward.
Answer
Geocouch (which provides R-tree indexing for CouchDB) and CouchDB only support bounding box intersections at this time, though I know that more extended functionality has been in the pipeline for some time. So, if you need a proper intersects function, you will have to write your own Map-reduce function on the results of a bounding box query, which is probably less than ideal. CouchDB has many strengths, such as being mobile ready and having extreme partition failure tolerance.
MongoDB does allow intersects via the $geoIntersects function and you can also get results ranked in order with geonear or use the aggregation version for further attribute processing, after a geo filter has been applied. Spatial indexing in Mongo is based on geohashing, which reduces two dimensions to one, so that it can be indexed with a B-tree. This can lead to worse query times than an R-tree index, such as used by Postgres/Postgis. Further, MongoDB does not have a mobile version, which you have expressed an interest in.
Of the NoSQL offeringd, Neo4J is worth mentioning as it does have a bit more spatial functionality than Couch or Mongo, but it is such a different beast, being based around graph search, that it probably doesn't meet your needs at all.
Postgres/Postgis is by far the most fully functional, from a spatial perspective, handling not just hundreds of vector functions, but raster and topology too. However, it is in a different part of the Cap Theorem triangle than the other two -- being fully ACID compliant, and therefore favoring consistency, over partition tolerance and availability, which may or may not be what you are looking for. Having said that, a properly configured Postgres cluster, can handle serious load, and it is a bit of a myth that you can't scale traditional RDBMS.
If you are attracted to the schema-less nature of NoSQL, you might be interested in a feature of Postgres coming out in 9.4, namely JSONB, which is a proper binary JSON type, but with good indexing on top (unlike Hstore, which always felt a bit bolted on to me). Postgres is not mobile ready, of course, but lots of people combine an RDBMS with something else these days, if the use case really demands it.
No comments:
Post a Comment