The web frontend is mainly for searching - it needs fast reads,
horizontal scaling across several servers.
In the backend it needs functions that check for geometric relations or
that compute new geometries. It must be able to handle huge, complex
geometries.
Fast geo indexes for both frontend and backend.
I can drop the C in CAP.
I don't want to use both PostGIS and Couch for the search frontend, so I
want to decide by some clear metrics what to use.
My plan is to use Couch as soon as I need to scale the frontend, and
PostGIS will still be used for complex computations in the backend.
However, it would be great, if the community can experiment with your
code and proove how well a NoSQL solution will perform compared to a
RDBMS for the OpenStreetMap tool layers.
Andi
Am 02.07.10 00:58, schrieb Lars Francke:
were there any successful attempts to read OSM data into CouchDB and
Geocouch? Does somebody know of a backend?
I have done something like that and can provide some code at the end
of July (I won't be back home before then). It really is just a
different kind of schema. But the exact schema depends on what you
want to use it for. Do you want to use it as an alternative to the
API/PostgreSQL or a convenient storage on mobile devices, routing
data, mapnik backend etc.
CouchDB is kinda great (even though the documentation sucks) but it's
just one out of many tools and may or may not be a good fit.
Cheers,
Lars
_______________________________________________
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
