-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am Tue, 7 Jun 2011 21:08:17 +0200 schrieb Sarah Hoffmann lonvia@denofr.de:
Hi,
On Tue, Jun 07, 2011 at 09:00:20PM +0200, Stefan Keller wrote:
2011/6/6 Sarah Hoffmann lonvia@denofr.de wrote:
Using JXAPI now. That should work reliably. Restricting the request
Thanks for bringing this Taginfo Switzerland service to us!
We really need a Swiss XAPI.
To me XAPI has such a limited query syntax (assuming you mostly use something like this http://jxapi.openstreetmap.org/xapi/api/0.6/*%5Bkey=value]). What is the use case for the XAPI button? What are you doing with the raw OSM XML reponse?
In case of Taginfo if is really meant for correcting errors. You can load the raw XML into JOSM although the remote control ist much more confortable. You can also just have a look at it to further look at the tag combinations used.
Would it be also acceptable if there would be a webservice which would respond with a webmap of switzerland (instead of an OSM XML file)?
That can actually easily be done with some OpenLayers magick because OpenLayers allows to directly display the XML files. Interesting idea but nothing I would want to bother the global XAPI with.
Apart from this, I think there are a ton of uses for a Swiss XAPI even if it has limited capabilities. Benni could get the data for his public transport map easier, for example. And maybe there are other people who would want to experiment with very special data without having to process the entire Swiss extract. Even the pbf has now 80MB, nothing you want to download and process every day.
Actually I've already setup a Postgres/PostGIS DB on my server to get the data because the geocoding API from cloudmade has very limited capabilities, it's actually abstracting the tags which is not really what I want. I used o5mfilter[2] to get just the public transport related stuff out of a planet dump in 3 hours, which is really cool. I'm now working on something like a public transport API, which would make it possible to get data consolidated by the rules of the new public transport feature, but with respect to the situation, that there are thousands of stations with the "old" scheme. See some simple stats on this [1]. The API is not yet open for public use since I'm still experimenting with the DB scheme best suited. I've tried the scheme used by osm2pgsql, since it would then be easy to also render the data with mapnik, but it is not really suited for complex querys like all nodes/ways in the same stop_area as the given one. maybe i have to get some data redundant in the DB, just to speed things up and still be able to feed mapnik from it. But that would make the upgrade process more complicated, any ideas? Anyway I'm already using this data on [3], so it basically works, and is so many times faster and more flexible than using the cloudmade service.
I'm going to try setting up a XAPI Switzerland using the new JXAPI code, doesn't seem to be too hard (at least I hope so).
And, of course, it would be just fun to try. ;)
thats the reason we are doing all this anyway, isn't it?
The challenge is to maintain an up-to-date Swiss extract in the osmosis Postgresql DB.
Do you think that would be a problem, is the available software (osmosis) not capable of doing this in a more or less automatic way without to much fiddling? Any hints? It would be a challenge to get it minutely updated just for switzerland, since then the provided osc files need to get filtered somehow. But by using the daily language extract from geofabrik, and then creating a osc against the version from last day and write that to the DB with osmosis, i think it should work. I don't mind to download the 80MB once a day.
Cheers Beni
[1] http://osm.xiala.net/statistics/public-transport.html [2] http://wiki.openstreetmap.org/wiki/O5mfilter [3] http://dev.map.xiala.net