incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luca Matteis <lmatt...@gmail.com>
Subject Re: Best stack for querying spatial locations
Date Tue, 05 Jun 2012 09:56:19 GMT
On Tue, Jun 5, 2012 at 11:38 AM, Miles Fidelman
<mfidelman@meetinghouse.net> wrote:
> - what kinds of spatial data?

He's storing something called "missions". Basically the location
people have been to collect certain types of plants. So his data
contains lat-lng coordinates and some other information of the mission
(such as the name of the collector and date).

> - is one person updating the data, or more?

For now just him. He changes the MS Access db and that's it. But with
Couch I can expect to plug it to other systems so that other people
could be adding it as well in the future - but for now it's not
needed.

> - does the database live on a single PC, or on a server?

It lives on his local PC.

> - how frequently is it updated?

Probably around once a month or so.

> - is it preferable for updates to propagate live to the online serve, or is
> a periodic dump enough (or preferred)?

Given the fact that it's only once a month, a periodic dump is
probably more efficient.

> - 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.

> - how many queries per unit of time?

I'm not sure, but I suspect very little. Not expecting high traffic at
all. But it needs to be responsive and I'm confident GeoCouch is quite
fast for the simple queries mentioned above.

> - 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.

> When I hear "geospatial stack" I don't generally think MS Access and
> CouchDB.  I 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.

> Or, you might think about something more like:
> - MS Access -> GeoServer (w/ some RESTful glue) -> CouchDB -> user facing

What's a GeoServer? How is it different than CouchDB + GeoCouch?

> 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?

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.

Mime
View raw message