Hi Roland,

For long trains like you describe, the platform is usually split up in
zones. I think it would make sense to have platform ways/areas that are
split to describe them in full detail. In practice these zones on the
platforms usually described by letters are not used individually, but
rather grouped together. I think I would create a node for each such group
and then use that one, but I admit, I'm mostly busy mapping bus/tram and
sometimes metro routes.

What I hear quite often in railway stations is: don't use the last three
'cars' if you want to get off in minor station such and so. I almost never
hear them say, get on the train in zone A-E, but I think it is written on
the tickets sometimes, in case people have made reservations for specific

Anyway, you're right in that the main point of my proposal is to get people
to add 1 object per stop to the route relations. The reason I wanted to
also specify platform nodes, is because I think it would be beneficial if
we have 1 way to do it. Otherwise when another mapper comes by, he/she may
want to change it to how they prefer mapping and I would like to see
stability in the data. I think what most people crave is one clear and
specific way of how to map public transport that is easy to describe and
easy to map for the simple cases, without impeding the possibility to add
the necessary detail for the more complex cases.

I'm also for having name/name:xx on the objects that are added to the route
relations. But I don't want to duplicate those names to stop_position nodes
- platform ways/areas. At present somebody changed to wiki to say that if a
stop_position is present it HAS to be added to the route relations. I can
go and change the wiki page back to how it was a few months ago, but it
will probably be changed again, when I'm not looking.

I'm only adding stop_position nodes occasionally in the middle of the
itineraries. And I'm always adding them at the start and end of the lines,
as I need a node there anyway to split the way on. I don't want to add
these stop_position nodes to the route relations and I definitely don't
want to duplicate details like name/ref/etc. to them.

Anyway, requiring to only add 1 object per stop to the route relations is
definitely a step in the right direction, but if we don't specify which
object to use, we will still have groups of mappers using different styles
of mapping. That's why I went one step further and also proposed to use
nodes not on the highway/railway for this purpose. I started calling them
platform nodes, because the answer I got on the mailing lists was to use
public_transport=platform for them. They rather represent the pole, or the
waiting area/zone for the passengers, but it doesn't make much sense to use
another tag for them, even when they are not really platforms. They are not
really highways either, but we still add highway=bus_stop to them. It seems
really hard to come up with a British English tag for them, so we can just
as well stick with


2018-04-16 7:21 GMT+02:00 Roland Olbricht <roland.olbri...@gmx.de>:

> Hi Polyglot,
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public
>> _Transport_map_all_stops_as_nodes
> I do agree that it would be easier for everyone to have one and only one
> member on the line relation per actual stop.
> However, trains and sometimes also trams can have a significant length.
> Walking the full length of a train can take as long as 7 or 8 minutes.
> There are applications that send people before stepping on the train to the
> right section to have a shortest possible walk after getting off (search
> for e.g. "london tube exit routing", no link here to not advertise a
> specific one).
> We render OSM useless for such applications if we force people towards
> adding fictitious nodes for trains. Please note that an easy approach like
> adding a node at the front position of the train does not bail out us
> because there are platforms that are called at in both directions of
> travel. In such cases, also the middle position of a train may vary.
> Therefore I suggest to drop the node requirement and keep up the
> requirement to have only one object per stop.
> A second thing for simplication: I suggest to require always a "name" tag
> on the member object or multiple "name:XX" tags if there is no preferred
> name in a multilingual setting. This way we could safely ignore relations
> for stop related objects.
> When writing both a plugin for JOSM and the display tool
> https://overpass-api.de/public_transport.html
> it was the most frustrating part to go on a quest to find the appplicable
> name if people had hidden it in some special relation, including scores of
> new possible kinds of error if one has no or multiple names from multiple
> stop_area relations and so on. This was the main reason to discontinue the
> development.
> I consider to write a proposal for the "name" requirement. Would it make
> more sense for you to instead include that in your proposal, i.e. add the
> requirement for the member object to have a "name" or multiple "name:XX"
> tags?
> Best regards,
> Roland
Talk-transit mailing list

Reply via email to