[Talk-transit] Proposed Feature - RFC - Public Transport

Sam Vekemans acrosscanadatrails at gmail.com
Sat Dec 11 15:33:47 GMT 2010

I'm just blogging this for later, the Oxoma Schema sounds interesting
to investigate further.

On 12/8/10, Michael von Glasow <michael at 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 at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit

Twitter: @Acrosscanada
Blogs: http://acrosscanadatrails.posterous.com/
Facebook: http://www.facebook.com/sam.vekemans
Skype: samvekemans
IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room)

More information about the Talk-transit mailing list