[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