[OSM-dev] API/XAPI caching proxy server
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):
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