Talk:Tag:public transport=stop position

PoI

Is this a PoI that people may want to search for ? (Should it be indexed ?) -- 23:55, February 5, 2010 User:Nic

No. --Teddych 09:54, 24 February 2012 (UTC)

Routing

If this node appears in a way, will there be a tendency that traffic will be blocked ? (Should we route around it ?) -- 23:55, February 5, 2010 User:Nic

Traffic can be blocked for several seconds. Depending of the timetable this happens only a view times a day up to several times an hour. The time-loss is usually not significant. Traffic lights or crossings usually are blocking the traff more. You do not have to route around it. --Teddych 09:54, 24 February 2012 (UTC)

Footway between stop_postition and platform ?

Does a highway=footway is needed between a public_transport=stop_position and a public_transport=platform ? Or does that virual way is handled by the relation in routing programs ?

That question also applies to other highway tags, like trains carrying people and their cycle, or ferries with people and their car. Thanks for the help. Alexandre 08:20, 24 February 2012 (UTC)

I do NOT add a way between stop position and platform. Usually the platform is not accessed directly by the street, it is accesst by the sidewalk. And if the platform is only a pole beside the street (without sidewalk/platform) a seperate way does not make sence too. --Teddych 09:46, 24 February 2012 (UTC)

Render

Seems when I tag bus stop as that (and only - without older bus_stop), main OSM map not reneder nothing… --Jezevec 15:28, 30 December 2012 (UTC)

Yes you need the older highway=bus_stop tag. This tag does not replace that one. They represent different things, and renderers (such as the osm 'standard' one) will tend to uses the highway=bus_stop node position as a more useful positioning of an icon -- Harry Wood (talk) 10:51, 4 January 2017 (UTC)

Location of stop position node

For the bus stops where a specific area has been reserved along a road (but not physically separated from it) like in the sample picture, do we have to represent some special way to put a stop_position node on it? or is it OK to put the stop position on the main road? Teuxe (talk) 15:22, 11 August 2013 (UTC)

It is important not to consider the stop position alone, but as part of the route relation: it specifies where the bus actually stops on that (one-direction) route. Usually, on a line, a stop area may present two stop positions at some distance to each other, each being relative to a route direction (like for the shelter, each on its appropriate road side). Teuxe (talk) 15:22, 11 August 2013 (UTC)

So the answer to the question in the simple case, is "yes". This tag goes on a node mid-way as part of the main road.

Actually the photo is maybe confusing in this respect. It might be clearer to show a bus stop which happens to stop within the road a bit more anyway. Additionally this page could do with a diagram or an editor screenshot illustrating a typical data arrangement

-- Harry Wood (talk) 11:04, 4 January 2017 (UTC)

Node position on length of vehicle?

Where should the stop position node be placed? For a bus .. near the front where the entry door is? What about a train. These can have considerable length ... should the stop position node be at the center of the train .. or at the front of the train? Warin61 (talk) 08:46, 12 February 2018 (UTC)

Vehicle length does not matter, there's a stop position for the vehicle and it's the front position, independantly of where people enter the vehicle (all along the platfom,n possibly on several doors); trains typically have variable lengths depending on hours/services; buses too. People start waiting in line from the front position. As the stoip position is on the highway/railway and not the side platform, it is an indiation not only for the bus but also the maximum extent to which the vehicle will occupy the position when stopped, if other vehicles must pass them.

It should be positioned at the front; if the side platform is represented as a node only (instead of a way or closed area), it will also be near the front position, typically at the position of the signal (you may also mark separately the benchs or other equipements on the platform, generally in the middle of the platform and not the front. — Verdy_p ^(talk) 09:09, 12 February 2018 (UTC)

While people start waiting for a bus at the front position when stopped, they wait for a ferry at the middle position when stopped, and for a train they scatter over the expected length of the train. So the queuing position is variable depending on the expected avalible loading positions. If the stop position is that used by the 'driver' of the vehicle many ferries have that about the middle of the vehicle. If the stop position is the 'front' of the vehicle then ok, but note that in some ferries the ferry can be used in both directions effectively changing which end is the front... in that case the front is that end currently the 'front'. :) Warin61 (talk) 20:44, 12 February 2018 (UTC)

You make the confusion between the stop position and the platform. What you describe applies to the platform only ! Platforms are not restricted to be single nodes (like stop positions used for routing the actual line), they can be a linear unclosed way, or an area. The stop positions and platforms are related via the "stop_area" relation if needed. The places where people wait a train or a ferry in not on the route itself but nearby the stop position which is on the route (at a posistion which is generally unsuitable for waiting as it is most often used by other kind of trafic unrelated to the transport route itself. There can be a single stop position, but of course there can be several accesses to the bus or train or ferry from the platform desserved by the same stop of the route, and we most often cannot tag these multiple access positions as it varies all the time depending on vehicles but the platform encompasses all these access positions; connecting the platform to the vehicle stopped at a stop positon cannot be mapped as it is an equipement part of the mobile vehicle; in some metros there are additional equipments such as doors on the platform that will line up with doors on the vehicle: these doors on the platform can be mapped, not the doors on vehicles. — Verdy_p ^(talk) 12:00, 13 February 2018 (UTC)

The stop position can be estimated from the platform. Looking at Relation: RE22/RB22 Köln => Trier (1717088) the stop positions used are in the middle of the platforms and that is probably not the stop position for the front of the train, but the middle of the train. The Relation: RE22/RB22 Köln => Trier (1717088) was used as an example to create Relation: Sydney 2 Central Coast & Newcastle Line (8014084) with stop positions at the front of the train. NOTE: 'I', 'you' etc can be taken as personal attacks, best avoided. Aim the comments at the objects rather than personalizing them. I have a fairly thick skin, so don't easily take offense, but others might. Warin61 (talk) 20:49, 16 February 2018 (UTC)

No, estimation does not work properly once you have a stop_position to one end of the platform. For trains, I usually, try to use the averaged middle of the train. Do not worry about the train drivers, railway-tagging already has the halt signs included, which can be a lot for stops used in both directions and trains between one to 16 or more cars. --Skyper (talk) 14:25, 2 March 2021 (UTC)

stop_postion for trains should be avoided if public_transport=platform is available

• Trains may have a length of several 100 meters. Using a node as stop position reflects reality very badly. Some users suggest to provide an artificial position based on the extend of next platform (either middle or front). However, if a renderer likes to use such a position, it can easily compute this on its own rules.
• Stop position of a train is dynamic. It may be different on time of the day, on day of the week or season. Mapping dynamic data is out-of-scope.
• Stop position is not verifiable. There are no observable marks on track. In general, we map only things with evidence on the real world.
• It is of no use for renderers or routers.

Passengers trying to board a train at stop_position are miss-leaded. They need to be routed to the platform. From there on they have to find there way to doors of the train by themself. Train-drivers trying to stop their train at this position are miss-leaded too. The must stop the trains according to their operational rules.

To indicate that a train stops here, stop_postion does not provide better information than the platform. Only if no platform has been mapped, a node for stop_postion might be a substitute to give that information found otherwise on the plattform. Accompanying a platform it is just duplication of the same information. Because public_transport=stop_position is an optional element in the public transport route, avoiding it will not break the route-relation. Halbtax (talk) 09:31, 21 July 2019 (UTC)

Agreed. After looking into this issue, it seems that the proposal for public_transport=stop_position was meant to provide a tag for mappers who wanted to import public transit stop position data from external databases, e.g. when the bus operator provided a list of nodes which happened to be in the middle of the highway, even though the usual way to map bus stops at the time (and still now) was highway=bus_stop at the side of the road, where the sign is. It turns out that current routing software doesn't need these nodes. If there is a highway=bus_stop or railway=platform the router has enough information to find the closest point on the highway=* or railway=* to the bus stop or platform. There is also a proposal from last summer to discourage use of this tag, which has a clearer explanation of the problems Proposed_features/Refined_Public_Transport --Jeisenbe (talk) 23:45, 29 July 2019 (UTC)

I'm not sure it's always possible to calculate stop positions automatically, especially for island stations or for stops which are very close to a junction (even just some driveway or other tiny highway=* could cause issues). --Tordanik 14:17, 3 August 2019 (UTC)

If the route relation includes the ways that the vehicle travels on, this should avoid any problems with service roads, driveways etc, I think?

But does anyone need to calculate precise stop positions for transit vehicles from OSM data? What would be the purpose of this? My understanding is that you can make a rough trip planner for passengers from OSM data, when you can't get something like GTFS or real-time transit vehicle data, but who would need to know exactly where the bus or train stops on the highway or tracks? I don't think transit operators should use OSM data for this directly. The important thing is where the passengers should wait for the train or bus, no? --Jeisenbe (talk) 15:02, 3 August 2019 (UTC)

It is useful for QA. Found some island stations with one platform for tracks on both sides of the island. Only with the stop_position I was able to spot that the route was running on the wrong side. I found some stops with platforms with entrances on both ends but the train stops far to one end. --Skyper (talk) 13:42, 2 March 2021 (UTC)

In the GTFS data of the Deutsche Bahn (German Railway) the stop_position is the reference with id and not the platform. --Skyper (talk) 13:42, 2 March 2021 (UTC)

There are some project for "wheelchair"-routing and people with other limitations. A blind person might want to enter at the front, while a person in a wheelchair at the second or third door. --Skyper (talk) 13:42, 2 March 2021 (UTC)

Direction

I feel like direction=* or stop_position:direction=* would be useful in cases where the two directions of a route are on the same highway but the stop positions differ. Comments? Martianfreeloader (talk) 18:55, 25 January 2022 (UTC)

Well yes, there are already ~6k direction=* instances together. https://taginfo.openstreetmap.org/tags/public_transport=stop_position#combinations --- Kovposch (talk) 20:41, 25 January 2022 (UTC)

Ok, I've added documentation. Martianfreeloader (talk) 21:29, 25 January 2022 (UTC)

Please, not again, direction=forward and direction=backward are a broken concept on nodes. Either use cardinal directions or degrees. Personally, I prefer destination=*. Now a days, the stop is usually represented by highway=bus_stop and public_transport=platform next to the road and public_transport=stop_position is only an addition. The connection between platform and stop position is represented in the route relation and by one or more identical values of ref=*, local_ref=* and ref:IFOFT=*. --Skyper (talk) 13:34, 28 January 2022 (UTC)

As I read the wiki page for destination=*, it seems to clearly state that on nodes which are part of exactly one way, it is OK to use direction=forward and direction=backward (section Forward and backward). @Skyper, are you sure this has been agreed to be deprecated practice and isn't just your personal opinion? If so, would you care to remind us why it is a "broken concept"? Martianfreeloader (talk) 19:17, 30 January 2022 (UTC)

See Key:direction#Forward_and_backward. First of all, you need to take a look at the parent way to get the information. You can only use it on middle nodes of a single way without adding restrictions on modifications of parent objects but for the last and first stop of any route, the ways need to start/end at the node. --Skyper (talk) 13:23, 31 January 2022 (UTC)

"You can only use it on middle nodes" - also at the end/start ones Mateusz Konieczny (talk) 14:07, 31 January 2022 (UTC)

Not a guaranteed assumption on two-way roads. If the previous and next section have opposing direction, it will be ill-defined. --- Kovposch (talk) 20:58, 31 January 2022 (UTC)

Right, I missed this case Mateusz Konieczny (talk) 21:28, 31 January 2022 (UTC)

I can agree direction=* is not the best, because I prefer sides=* to handle stops on both edges of a one-way road with the same direction. I'm only point out direction=* is being used. --- Kovposch (talk) 03:28, 31 January 2022 (UTC)

OK, facts seem to be (1) direction=forward and direction=backward are documented as being accepted usage on nodes that are part of exactly one way. (2) They are in active use. (3) Kovposch and Skyper think this practice is somewhere between not the best and a broken concept. I find Skyper's explanation on their last comment convincing. Should we wait for another couple of days whether any other opinions will come in and if not change the documentation of public_transport=stop_position and direction=* accordingly? Martianfreeloader (talk) 13:31, 31 January 2022 (UTC)