cool, I'm just blogging this for later, the Oxoma Schema sounds interesting to investigate further. cheers, sam
On 12/8/10, Michael von Glasow <mich...@vonglasow.com> wrote: > On 12/08/2010 08:44 PM, Dominik Mahrer (Teddy) wrote: >> Hello >> >> Yes, the Public Transport proposal is basically based on Oxomoa, but >> in some details different. >> >> unified stoparea would "redefine" highway=bus_stop from beside the way >> to on the way. I'm quite sure this would reject the proposal in a vote. >> >> unified stoparea and public transport can and do exist beside each >> other. But you are right, it does not make sense to approve both >> proposals. >> >> I do not care about which of the two proposals will be approved. But I >> think it is time to get a more exact schema approved then the >> fuzzy/non-existing schema (A railway station of 400m length and 20 >> platforms or a bus stop for 3 buses per direction of 50m length is >> reduced to one node) we have now. >> >> Regards >> Teddych >> >> >> On 12/08/2010 06:02 PM, Oleksandr Vlasov wrote: >>> Dominik Mahrer (Teddy<teddy<at> teddy.ch> writes: >>> >>>> I want to invite everyone to comment the (in central europe) already >>>> widely used new Public Transport Schema: >>>> >>>> http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport >>> > Good work - a few months ago I started mapping the public transportation > network in Milan and started out by looking around how other cities were > doing it. My aim was to use a tagging scheme which is easy to > understand/learn, minimizes data entry effort (it makes a difference > whether mapping a single line takes half an hour or two hours) and is > supported by the common renderers. > > The results of the research I did back then is at: > > http://wiki.openstreetmap.org/wiki/Milano/Trasporti_pubblici > > (unfortunately it is in Italian only, but maybe non-Italian speakers can > still get some information on tagging out of it). > > The differentiation between stop_position and platform elegantly solves > the dilemma on the position of the node (on the way or next to it). For > routing applications it is definitely more convenient if the node is > part of the way. However, two stops located on either side of the road > would thus collapse into one point and it would no longer be possible to > tag explicitly one or the other. (For example: here in Milan each stop, > i.e. pole, has a unique number, which I tag as ref. If there is a double > tram stop, there is a single node but two numbers. Using only this > single node, there is no easy way to tell which number belongs to which > side of the road. Or another example: what if there is a shelter on one > side of the road, but not on the other?) > > In the new proposal I am missing some details on how to build relations: > > 1. Should the outward and return trip be represented as two separate > relations, as a single relation or is that up to the mapper? > > I would favor separate relations: The ways used may be different (a road > with two physically separated lanes, or a labyrinth of one-way streets > in a European city), and with one relation per direction it is easy to > sort the ways and detect holes in the route. > > 2. Which members should the relation contain, and in which order? > > My approach to this: all way segments, tagged as role=forward or > role=backward. The way segments should be sorted; where a bus passes the > same way twice, it should be added twice - this allows for easy > verification if the route is complete. Additionally the relation should > contain all stops, which must also be sorted (some rendering > applications, e.g. sketch-route, need the correct order of all stops). > Stops should not be mangled with the ways - either insert ways first, > then stops, or vice versa. Again, this is for better overview and makes > the process less error-prone. > > 3. Which data primitive should be added for stops? > > My suggestion: the one which best identifies the actual position at > which the vehicle stops (and passengers board). This can be either the > platform, the stop position or the stop area relation. Given that the > stop position is always a node while the platform may be a node or an > area, the stop position is probably the less problematic one to use > (some renderers already support the combination of role=stop, > public_transport=stop_position). I would recommend against adding the > stop group relation as stop, since this does not provide sufficient > information as to where passengers can really board the vehicle (stop > groups can be huge). > > 4. How are line variants mapped? > > One relation for each variant? Or one relation for the common part and > one for each alternative? Sincerely, this is where I'm myself at a loss. > Imagine a bus line with the following stops: A - B - C - D - E1 - F1 - G > - H - I - K. > > Now as for the variants. It's a made-up example, but there are lines in > Milan which are hardly better: > - Stops E1 and F1 are in a street which is regularly closed for the > weekly market (suppose Wednesday from 6:00 to 16:00). During that time, > the bus takes a detour, on which two other stops (E2 and F2) are located. > - The first courses in the morning (6:00 to 7:00) begin at B rather than > at A. (For instance because B is near the depot.) > - Every second course ends at H; only the other half of the courses > serve I and K. > > That would leave us with a total of eight possible combinations: > * A - B - C - D - E1 - F1 - G - H - I - K (half the courses after 7:00 > except Wednesday before 16:00) > * A - B - C - D - E1 - F1 - G - H (the remaining courses after 7:00, > except Wednesday before 16:00) > * B - C - D - E1 - F1 - G - H - I - K (half the morning courses, except > Wednesday) > * B - C - D - E1 - F1 - G - H (the remaining morning courses, except > Wednesday) > * A - B - C - D - E2 - F2 - G - H - I - K (half the courses Wednesday > 7:00 - 16:00) > * A - B - C - D - E2 - F2 - G - H (the remaining courses Wednesday 7:00 > - 16:00) > * B - C - D - E2 - F2 - G - H - I - K (half the Wednesday morning courses) > * B - C - D - E2 - F2 - G - H (the remaining Wednesday morning courses) > > Looks confusing? And this is only one direction. Now imagine editing the > relations for that... so far I've cheated and mapped only the main > course (the equivalent of the first in this example). > > As for pure telescope lines (first or last stops are omitted), we might > resolve the problem by just marking them as such. For instance, we might > change their role in the relation to stop:alt_from or stop:alt_to. > > That would reduce the above example from 8 to 2 relations. B would be > added as stop:alt_from, H would be added as stop:alt_to. (We could even > handle the additional case of evening courses terminating at G.) > > Drawbacks: this example does not express which of the combinations are > "allowed" (some lines might serve either from A-H or B-K, but not A-K or > B-H), and we have no information of which combination is served at a > particular time. But it's enough for drawing maps and line sketches, and > (with some limitations) routing. More detailed information would > probably require a timetable - here I would hope for transiki to provide > something useful someday. > > OK, I admit that was a lot... but public transportation is a complex > thing, as I suppose most of can tell from their own experience. > > Michael > > _______________________________________________ > Talk-transit mailing list > Talk-transit@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-transit > -- Twitter: @Acrosscanada Blogs: http://acrosscanadatrails.posterous.com/ http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans Skype: samvekemans IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room) @Acrosscanadatrails _______________________________________________ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
