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.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
