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