[OSM-dev] API/XAPI caching proxy server

Peter Körner osm-lists at mazdermind.de
Thu Dec 16 21:36:22 GMT 2010

Am 16.12.2010 22:17, schrieb Ian Dees:
>     The osmosis simple schema would be a better start. It also supports
>     hstore and an geometry column but stores full meta information.
> I'm working on this exact setup as we speak. I wrote an XAPI querystring
> parser in ANTLR (https://github.com/iandees/xapi-antlr) and plan on
> writing the rest of the server piece tonight while I wait for a planet
> to import into an EC2 instance. I'd be happy to have help -- if you're
> interested let me know before I pick a language to use in the next 6
> hours or so.

As the serverside code would not need to work so much but would wait 
most of the time for the database to answer, php or python would not be 
the best choice in my opinion.

I'd suggest an asynchronous language like node.js instead. If you'd like 
some help I'd happy to try to develop an xapi-query-system using node. I 
never developed a completed app in node but I played around with it.

I'm curious how fast the EC2 disks are (I heard some bad things about 
them). You'll see this when osmosis starts to CLUSTER the database which 
is a very disk intensive task.

Btw: Instead of using a custom url scheme like the current xapi does, 
I'd suggest some well proven scheme (classic &'s and ='s):

GET /osm?bbox=a,b,y,z&key[highway]=residential
GET /osm?bbox=a,b,y,z&key[highway]&key[name]
GET /osm?bbox=a,b,y,z&key[place]=city&key[name]=B*
GET /osm?bbox=a,b,y,z&key[place]=city&type=node

Additionally to /osm an api sitting on top of this database could 
provide a /gis query, which returns geojson or sth. instead of osm-xml 
with pre-assembled geometries.


More information about the dev mailing list