[OSM-dev] API/XAPI caching proxy server
Frederik Ramm
frederik at remote.org
Thu Dec 16 21:38:24 GMT 2010
Hi,
Peter Körner wrote:
> The osmosis simple schema would be a better start. It also supports
> hstore and an geometry column but stores full meta information.
I don't want to interfere with anybody's plans but I would recommend to
not automatically assume that a relational database (or a relational
database with spatial extensions) is the best way to approach this.
There are a number of different use cases. Geometry does not always play
a major role.
* Some people want to use the XAPI to simply get all data for a given
area. For such use cases, some kind of tiled storage is probably
superior to scraping the data from tons of different sectors of a 400 GB
database hard disk. Other uses are more along the lines of classic
relational database queries.
* Remember topology. For most XAPI use cases, it is not sufficient to
hand out a geometry; you will need to return the ways or nodes, plus any
relations using them, plus perhaps other nodes/ways used by the returned
ways/relations etc., so you will require efficient navigation along the
connections between objects.
Before you build something grand based on PostGIS, also check out these
links which may mean that PostGIS' R-Tree indexing is not very well
suited for what we're doing.
http://blog.cleverelephant.ca/2010/08/take-this-tree-and-pack-it.html
http://cognitivelychris.blogspot.com/2008/10/nitpicking-pick-split.html
http://cognitivelychris.blogspot.com/2009/09/send-your-r-trees-packing.html
I am by no means advocating one of those new buzzword databases, I
haven't checked any of them and frankly I believe that there are not
many open source databases out there that regularly cope with stuff like
XAPI use would throw at them. Every now and then someone comes along and
believes they have the best thing since sliced bread ("it has WEB
SCALE!") but whether they can prove their salt in real-world use is
another matter...
Bye
Frederik
--
Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"
More information about the dev
mailing list