----- Ursprüngliche Mail -----
On Wed, Jun 08, 2011 at 12:58:17AM +0200, Beni Buess wrote:
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].
Sorry to jump on this, but I hope 'consolidation' doesn't mean to mass retag things. I think this 'new' schema allows the 'old' tags to co-exist, so just leave them be.
I won't mass retag anything. I'm with you about the coexistence. By consolidation i basically mean inheriting values from the relations, since the new schema introduces some kind of hierarchy. i'll do some logic to get the uic_ref and uic_name from a stop_area relation for every stop_position that doesn't have this information. thats how some people are going to tag things to avoid redundancy in the osm db. but i need the uic_ref and uic_name to get the timetable information.
Personally, I prefer the 'old' schema because the 'new' proposal is about as simple and readable as a IEEE standard (or, if you prefer these things: the German tax laws). I mean: two nodes and one relation for a simple one way bus stop? Why? In 95% of cases the 'old' schema will do the job just fine and your map proves that.
one thing that is really cool about the new schema is this: if the routes are properly defined with the right stop_positions (not the stop_areas), it will be possible to display very detailed timetable information since the timetable data could be filtered by the route information to display just the next departs for the clicked stop_position and not the stop_area, that would be cool and really unique. if there is a stop_area relation, it would still be possible to display all the departs from zurich hb for example. have you ever searched the right stop position for a certain bus line in bern or zurich?
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?
Maybe you should have a look how I do the hiking map [1]. The philosophy is basically to derive specialised database schemata instead of using the one-size-fits-all version. This way you get tables that are suitable for both rendering and fast online queries.
I solved that by deriving table from a osmosis planet database. (There is the beginning of a framework [2] but really just the beginning.) The advantage is that it has full updating support.
Another library which has the same philosophy is imposm[3]. It imports specialised schemata directly from a osm-file. It might be a bit more mature, but there is no update-support.
i'm sure going to look into your framework. thank you.
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).
Cool.
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?
I would create an osmosis psql DB from the Swiss extract and then use the planetary minute update to keep it up-to-date. After each update the DB needs to be cropped to Swiss size. This step actually needs some thinking but it should be possible. (If you want to do it really well, you should write a special osmosis task that takes a polygon as input and crops the data already while updating the DB.)
have you ever cropped by polygon and not by bbox? maybe it would also be possible to use postgres/postgis for this task. but then the data needs to get into the database first, which would not make it any faster i think.
auch gruss
beni