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

Michael von Glasow michael at vonglasow.com
Thu Dec 9 00:49:48 GMT 2010


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



More information about the Talk-transit mailing list