Geo-enabling CouchDB
Interesting. It occurs to me that SQLite, even, is overkill for this purpose. A relational database isn't necessary and the unavoidable duplication of data is undesirable. All that is needed is an R-Tree index and, eventually, the capacity to use spatial operators and predicates in views. The Rtree package that Howard and I have been working on could serve well. It need store only the keys of CouchDB documents, so there's no duplication of spatial data. SpatiaLite (which appeals to me in many ways) uses the same geometry library as Shapely does (GEOS), so a Python query using Rtree and Shapely has essentially the same implementation as an OpenGIS SQL query of SQLite/SpatiaLite. I suggested in comments that GeoCouch might want to take advantage of the GeoJSON group's work, on geometry formatting at least.
Via Simon Willison.
Comments
Re: Geo-enabling CouchDB
Author: Jan Lehnardt
Hi, that's what we are thinking :) CouchDB's external-indexing API is fairly simple. What Volker did is a proof of concept of how to get something up and running as fast as possible. Directly working with RTree would be pretty cool. Are you up for some collaboration? :) Cheers Jan --Re: Geo-enabling CouchDB
Author: Volker Mische
Hi, I actually tried the R-Tree package first, then I found SpatiaLite. I wanted to keep it as minimal as possible and as you say, I only need an R-Tree. The reason for switiching was file locking. There might be an easy workaround for having one script having right access and another one read only access, mine was using SpatiaLite as it offers equal functionality with not that much overhead (and as Jan aready said, I wanted to get something running asap). Another reason that was that the sptialindex kind of broken when I added to manay point >300000 iirc (though I haven't tested it with SpatiaLite yet). When I can overcome these issues I'd be happy to give R-Tree package another chance and see if I can work it out, as it really does everything I need (especially Shapely). About GeoJSON: sounds like a good idea, though I might use only GeoJSON-like structure to make lat/lon vs. lon/lat more obvious. I don't want to confuse people as I will use lat/lon in the future, and the prefered GeoJSON coordinate order is lon/lat.Re: Geo-enabling CouchDB
Author: Sean
I can't fault anybody for using a working solution and getting things done, and had no idea you'd tried Rtree already. I'm using it in an application, one that doesn't have to be as concurrent as yours. Do you think it would be helpful to queue Rtree access, perhaps using multiprocessing's Manager class? Having asked the question, I really must try it. About GeoJSON coordinate order: we got it right :) What you get out of following it is easy integration with OpenLayers, Shapely, etc. I also can't deny that if all you have is points, {"lat": 0.0, "lon": 0.0} is most clear ... but only until you encounter different coordinate systems.Re: Geo-enabling CouchDB
Author: brentp
knowing very little about couchdb, except that it has uses btree, this seems like the good application for geohash.Re: Geo-enabling CouchDB
Author: Volker Mische
Sean, yes I know that you got the coordinate order right. I might use something like coordinate_order and make the default order lon/lat, as I want to support more than just points. But that's a detail, I'd rather spend some time on trying the R-Tree package again :)