On Tue, 5 Jun 2012 11:56:19 +0200 Luca Matteis<[email protected]> 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 facing
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
or
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
approach.
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
WMS/WFS).
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 geoserver.org - 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 http://openlayers.org/ - a JavaScript mapping library, and
probably the most common starting point for building geospatial mashups/apps
4. take a look at http://www.programmableweb.com for APIs that relevant
to what you want to do - that might lead to you libraries, tools, examples
5. take a look at http://www.osgeo.org/ 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 [email protected] - 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.
Miles
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
