[Tagging] rail routes: how are platforms and stops associated (rail question 2)

Fri May 12 18:37:46 UTC 2017

My preference is to make the platform part of the route. A node tagged

public_transport=platform
railway=stop /highway=bus_stop (so they render on carto)
name=
ref=

This works particularly well for bus, tram, metro. It doesn't work all too
well for trains, as they often arrive at different platforms, depending on
the situation at the particular moment.

I like to consider the passenger perspective. I map the
public_transport=stop_position node on the highway or railway from the
perspective of the 'driver'. Those nodes don't need too much extra detail
though. What I basically use them for is to split the way on them for the
first and terminal stops of a line.

Would it be conceivable to come to a simplified way of mapping the route
relations (at least for buses, trams and metro) to only include those
public_transport=platform nodes?

I am converting many route relations from "public_transport:version=1" to
"public_transport:version=2". And it's a hassle, but still feasible.

The point where I'll throw in the towel is if every stop needs to be in
those route relations twice.

Some people add the stop_position nodes to the route relations and platform
ways. Often duplicating all the details on both those stop_position nodes
and the platform ways. From the passenger's perspective the stop_position
nodes are not where they are waiting. Still those are the primitives that
have coordinates that can easily be compared to data from the operators.

Having a node for the 'platform' (the pole with the flag on it in
actuality) or at least the place where people gather to wait with all the
details exactly once, solves many problems and makes checking and creating
the route relations feasible.

Or maybe we need to define yet another public_transport=pole/waiting_area
mappable only as a node for this purpose and include that in the route
relations? When I asked a few  years ago, I was told to use
public_transport=platform for this purpose and this works well, as long as
it is mapped as a node.

I'll be doing a workshop on public transport in Avignon the first Sunday of
June.

Polyglot

2017-05-12 20:12 GMT+02:00 Colin Smale <colin.smale at xs4all.nl>:

> How about a step back for a second here... What is the stop_position
> intended for? Who is it intended to help or inform? A bit of context would
> help to rank the possibilities.
>
> I remain by my earlier standpoint that a stop_position is too much detail
> for a route as it is too variable to be useful. Trains on the same route
> will be longer or shorter, and will use different tracks and different
> platforms from time to time. What stays constant when considering the route
> is the station itself, so this would be the right entity to make part of
> the route.
>
> --colin
>
>
>
> On 2017-05-12 17:45, Bjoern Hassler wrote:
>
> Hi Michael,
>
> that's very helpful, thanks. I'll implement the ref as well as the
> ordering. I'll also add this to the English wiki pages where needed. I'll
> have a look at the DE page as well.
>
> Examples for nodes as requested. Stop_position at:
> - End of platform (middle of line) node 13328915
> - End of platform (end of line) node 20955753
> - Middle of platform node 1620401529
>
> (Disclaimer: I was just adding tags for 13328915, but I'll fix this
> shortly to be in the center of the platform. IMHO that is the convention
> that does make sense from a passengers perspective, but yes, it doesn't
> address Colin's comments about physical stop train positions from the
> drivers perspective.)
>
> Many thanks,
> Bjoern
>
>
> On 12 May 2017 at 15:48, Michael Reichert <nakaner at gmx.net> wrote:
>
>> Hi Bjoern,
>>
>> Am 2017-05-10 um 18:59 schrieb Bjoern Hassler:
>> > In an  osm:relation:route
>> > <https://wiki.openstreetmap.org/wiki/relation:route> (type=route,
>> > route=train/...), you have both platforms and stop positions. How is a
>> > particular platform associated with a stop that serves it?
>> >
>> > E.g. for public transport routing, you'd walk (highway=footway) to a
>> > platform (public_transport=platform), at which point you'd change to a
>> > train stopping at a stop (public_transport=stop_position). How would
>> the
>> > routing algorithm know that the platform is associated with the stop?
>> >
>> > Is there an existing mechanism or convention, e.g. a tag on the platform
>> > that indicates the stop, or both tagged with the same name or similar?
>>
>> Stop positions can have a tag ref=* or local_ref=* giving the track
>> number which is signed on the platform. The platform has ref=*, too. The
>> ref tag of the platform often contains multiple numbers because many
>> platforms have to edges, i.e. ref=2;3 or even worse: ref=2a;2b;2;3a;3b;3
>> (if the track can be occupied by two trains behind each other at the
>> same time – very common at busy stations).
>>
>> If you don't want to parse ref=*/local_ref=* and route relations are
>> properly mapped, you can check which route relations reference a
>> platform. If a route relation contains both platforms and stop
>> positions, the next member of a relation after a stop position node is
>> should be the platform.
>>
>> I think that both variants provide better results than simple snapping
>> on the next edge in your pedestrian routing graph (if platforms are in
>> your routing graph). There are cases in reality where a railway track
>> has platforms on both sides but you can or must leave the train only to
>> one direction.
>>
>> > PS I've noticed that sometimes the stop position is at the far end of a
>> > platform (i.e. the two stop positions are at opposite ends of the
>> station).
>> > Maybe that's so that an association can be made?
>>
>> From my point of view this is wrong mapping. (In Germany mainly done by
>> user rayquaza) To give a correct answer, you should give some examples
>> (node IDs).
>>
>> Best regards
>>
>> Michael
>>
>> --
>> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
>> ausgenommen)
>> I prefer GPG encryption of emails. (does not apply on mailing lists)
>>
>>
>>
>> _______________________________________________
>> Tagging mailing list
>> Tagging at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20170512/03643936/attachment-0001.html>