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.
Peter
_______________________________________________
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
