incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Miles Fidelman <>
Subject Re: Best stack for querying spatial locations
Date Wed, 06 Jun 2012 13:11:27 GMT
On Tue, 5 Jun 2012 11:56:19 +0200 Luca Matteis<>  wrote:

> >  - what kinds of queries are going to be made against the data?
> The idea is that the UI will be built using Google Maps. Some layers
> are going to appear to let users filter the data. Like to layers for
> countries and maybe other areas with specific climate information, so
> that users can filter on that. The logic to define these "layers" I
> expect is going to be on the client, so Couch doesn't need to worry
> about that, it only needs to answer with the coordinates given a
> specific area (which GeoCouch does perfectly already, right?).
> Also simple queries like "give me all the missions with these date
> ranges". So Couch does this quite easily, all I need is to build a
> view.

> > - RESTful API implies a liklihood of combining the data with other > 
> data/services - so what kinds of things will people be doing? Yes 
> indeed. One of the reasons I want to use Couch is because of its REST 
> capabilities. We don't have any plans for now to make the data 
> available to other services, but the idea that we can in the future is 
> what gives us confidence to go ahead with Couch.

It all sounds fairly simple. The one comment I'd make is that you'd be 
well off looking around for tools and libraries that you're likely to 
use for mashing your data with Google Maps - e.g. libraries that munge 
data into KML to feed to Google Maps.  If a lot of the code you need is 
available for Couch, use Couch; if it's available for something else, 
use that.

>   >  When I hear "geospatial stack" I don't generally think MS Access and
> >  CouchDB. =A0I tend to think more:
> >  - Google Maps&  KML, and/or
> >  - GeoServer + PostGIS, and/or
> >  - OpenLayers, and/or
> >  - ESRI ArcGIS (for really serious commercial capabilities)
> Yes, We tried ArcGis in fact. But it's a very complicated piece of
> software which is very hard to customize. It also appeared to be quite
> slow with our ~2gb points. So we decided that a customized solution
> might be best.

Well yes, ArcGIS is about the last thing to use if you can avoid it. 
It's expensive, and very hard to customize (that's what their VARs do 
for a living).  If you're managing huge geospatial datasets (property 
records, military stuff), or doing serious cartography, it's the best 
way to go.  Otherwise, to be avoided.  (Think Oracle vs. MySQL.  If 
you're a bank, you go with Oracle, otherwise MySQL or NoSQL.)

> >  Or, you might think about something more like:
> >  - MS Access ->  GeoServer (w/ some RESTful glue) ->  CouchDB ->  user
> What's a GeoServer? How is it different than CouchDB + GeoCouch?

Well, first off, it's a REAL spatial database. It's a geodata server 
built on top of PostGIS (PostgreSQL with geospatial extensions).  The 
key thing is that it supports both SQL and all of the standard 
geospatial interfaces (Open Geospatial Forums WMS and WFS, KML) and 
provides some RESTful interfaces as well. (WMS=Web Mapping Service, 
WFS=Web Feature Service - APIs for accessing geodata.  They're primarily 
SOAP style web services, but there are RESTful bindings as well.)

> >  Or it might make sense to keep some stuff in a geodatabase, other stuff in
> >  Couch, and mash stuff together in browser-side code.
> What do you mean by "geodatabase". Like ArcGIS?

Well, actually ArcGIS isn't a spatial database, as much as a set of 
tools (analytics, GUI, libraries) written on top of a spatial database 
(in their case Oracle Spatial).  What distinguishes a spatial database 
are additional fields and indices that make it easier to query along 
spatial dimensions - say to select all records within a bounding box.  
In general, these are implemented as extensions to SQL databases.  
GeoCouch is the equivalent for CouchDB.

> Thanks for this, answering these questions made the situation a bit
> clearer for me as well.
> Let me know what you think would be the best way to go. I still think
> that maybe going with CouchDB + GeoCouch would be the simplest
> solution given the queries that we need to make against the system,
> but there might be something else which is 100 times better.

Well... it doesn't seem like load, performance, or multi-user issues are 
going to be a problem, so it really comes down to how much code you're 
going to have to write & maintain, and maybe single-query performance.

Seems like your first choice is Architectural focusing on the UI.  As 
far as I can tell, it comes down to:

1. Google Maps - with a processing chain that looks like this:

Access -> [data conversion & upload] -> some-other-database -> [query 
processing] -> [KML generation] -> Google Maps

implication: you're looking for the easiest way to generate KML, and the 
choice becomes one between

Access -> [SQLtoJSON] -> CouchDB -> [Couch views that produce KML] -> 
Google Maps
Access -> [SQL dump] -> GeoServer -> [some pre-existing tool/library 
that produces KML] -> Google Maps

2. A Mashup that draws from your API and Google's API:

Access -> [data conversion & upload] -> some-other-database -> [query 
processing] -> JavaScript in the Browser
Google Maps Data -> Google Maps APIs 

implication: you're looking for JavaScript libraries,  and what they 
"eat" will determine whether you're better off with an SQL or a Couch 

3. Some other geospatial GUI, like OpenLayers.  Like choice 1., it comes 
down to what that GUI "eats" and libraries/tools for generating 
appropriate input.

The advantage of CouchDB, of course, is it's simple to get up, running, 
and define documents and views.  But... if you have to write a lot of 
code to get from SQL -> JSON -> KML you've given up that advantage 
(there's a lot of code for going from SQL -> KML, possibly by way of 

Having said all this, the tools and libraries available for geospatial 
SQL and KML are probably a lot more numerous and mature than what's 
available for geoCouch.

My suggestions:

1. start googling for various combinations of CouchDB, geoCouch, KML, 
"google maps" and so forth - look for examples and libraries

2. look at - nose around for some examples:  the plusses 
are that it already has a lot of capabilities and supports all the 
standard geospatial data formats and APIs, the downside is that it's 
Java, with all the associated baggage when it comes to doing simple stuff

3. look at - a JavaScript mapping library, and 
probably the most common starting point for building geospatial mashups/apps

4. take a look at for APIs that relevant 
to what you want to do - that might lead to you libraries, tools, examples

5. take a look at as a starting point for learning 
about available open source geospatial tools - I direct your attention 
to the box on the lower right-hand of the page - with a list of 
libraries, servers, and other tools

6. join - post a query there, describing what 
you're trying to do, and asking for suggestions about starting points -- 
I expect you'll get more relevant answers - the open source geospatial 
community is a lot larger than the geoCouch community.  You'll probably 
find some folks who've done just what you're thinking about and compared 
different options.

One final comment:  Focus on the problem you're trying to solve, pick 
the best tool.  Not the other way around.

Hope this all helps.


In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

View raw message