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
[email protected]
http://lists.openstreetmap.org/listinfo/talk-transit
