----- 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
On Wed, Jun 08, 2011 at 03:20:31PM +0200, Beni Buess wrote:
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?
Yep, these stations certainly belong to the 5% that really benefit from the extended tagging schema. I think I see what you are planning, I'm looking forward to see the results.
Speaking of consolidation: at the moment I'm quite busy resurveying the bus stops we imported from DIDOK. For this it would be really helpful to have a map where you can check what stops have already been corrected. I always wanted to do this myself but this needs information about the last editor and last version and I currently don't save this in the database. As you are already extracting all PT information, would it be possible to add a layer with such a map?
Basically, three states are needed: user=DidokImportCH, version=1: added with Didok, needs resurvey user=DidokImportCH, version>1: added by user, changed by Didok (most probably ok) user<>DidokImportCH: resurveyed, OK
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.
I annotate the hiking routes by country using postgis functions. For just one polygon that is very fast, especially as you only have to check updated nodes and not the entire database. I can run a few tests, if you like. The tricky part is actually the ways. There are some corner cases which are hard to catch. (For example, somebody moves all nodes of a way into Switzerland. There is no way to know about that because the way wasn't in the database before and will also not be part of the update.) Dito for relations.
Gruss
Sarah
-
Beni Buess -
Sarah Hoffmann