Proposal talk:Refined Public Transport

support eliminate stop_positions

They are problematic to order the members of the route, and if they do not have a name even worse.

Not mapping them also implies that you will not have to make a stop_area relation for each single stop.

"It seems there would be too many stop_area relations." In my opinion it is the opposite, when simplifying the bus stops to a single node in cases where there is only one post, these relations would be eliminated, at least where I live. --AgusQui (talk) 04:16, 10 July 2018 (UTC)

Thanks for the support, I wholeheartedly agree with you. Stop positions introduce more trouble than benefit. In this proposal, they are not described in terms of mapping, but mentioned for data users: I tried to make it compatible to PTv2, and users need to know what to do with already mapped stop positions. I probably need to point this out in the main text. --Zverik (talk) 05:08, 10 July 2018 (UTC)

Stop positions can be useful, for easier parsing of route relations (e.g. we use them to calculate distances between stops along a route; if we hadn’t them we should need to find the nearest point from the platform, but this does not work well if the way is in a straight line and the nearest point is far away, or if the platform is a way/area). They can also signal other mappers why a way was split somewhere (start/end of a route relation). I would rather keep them, though they should be optional: those who don’t need them shouldn’t be forced to use them. Bxl-forever (talk) 10:30, 5 March 2019 (UTC)

Agreed with eliminating stop_position in the route relation. Mapping stop_position in v2 is the most tedious with limited usefulness, which is un-necessary when a point stop functions well with most use cases to determine route. It also indirectly breaks simple interchange determination because stops are no longer mapped on a single stop node and thus necessitates the similarly un-necessary stop_area_group, instead of all possible routes relations being locate-able on the single stop node. In addition, it also breaks the one-feature-one-element rule by requiring duplicate station information for routes, causing additional issues with translations, Wiki-information, etc. If required, stop positions can also be roughly estimated via shortest distance from way route, and thus shouldn't be mandatory and the primary stop node as in PTv2. At most, people may map stop_positions but this should just be more details associated with the route. --JaLooNz (talk) 15:14, 10 June 2019 (UTC)

bus_station

Why is it recommended to pass amenity=bus_station to a node? In cases where the area is well defined I do not see why not. --AgusQui (talk) 04:16, 10 July 2018 (UTC)

I agree that amenities tend to be area when well-mapped. The proposal does not have anything against it: object types are recommended, not mandated. Solely for the purpose of being easier to map and use. For bus station, frankly, I have no idea which tag to use for an area if not "amenity". --Zverik (talk) 05:08, 10 July 2018 (UTC)

Then the proposal should encourage mapping it as a area, with fallback possible to a node if the area is not well defined. Contributors should be encouraged to map in better detail the data --Gileri (talk) 08:41, 29 July 2018 (UTC)

highway=bus_stop/railway=tram_stop on nodes next to the highway

There are many things I like in your proposal.

1 single object to represent the stops, that's definitely the OSM way.

Personally, I would make it more strictly defined. It makes it a lot easier to write documentation if there is not too much room for interpretation.

At the same time, I understand you want to leave room to enable the transition.

Exactly, I want this proposal to be compatible with PTv2, to avoid any retagging. --Zverik (talk) 10:47, 11 July 2018 (UTC)

Regarding the stop_position nodes. In most places I would not add them. At the end of the lines/itineraries, I do add them, because I want to split the highway/railway at that point, so they don't do any harm there.

Stop positions are discouraged in PTv3. I've altered some wording to make it clearer. --Zverik (talk) 10:47, 11 July 2018 (UTC)

The reason why I'm adding public_transport=platform to the highway=bus_stop/railway=tram_stop nodes, is that they get a platform role automatically that way in JOSM. We can ask the developers to change that behavior though, and once we do, it doesn't really matter anymore to me whether those nodes representing the stops have the public_transport=platform tag and a mode of transport. Apparently it's too hard to render them anyway when they lack highway=bus_stop, so we can just as well drop them.

This proposal also makes roles optional for route relations, except for "entry_only" and "exit_only". A type of object can be determined by its tags, so why make mappers do extra work just for a validator. And we already have rendering rules for all the old PT tags. --Zverik (talk) 10:47, 11 July 2018 (UTC)

It does make me wonder about trolley_buses though. If we only put highway=bus_stop, bus=yes becomes unnecessary, but would we still put trolley_bus=yes then?

My position (reflected in the proposal) is that we don't need these (mode_of_transport)=yes tags. If needed, they can be determined from referencing route relations (which can be hard, of course: stop object → stop area → all platforms → all route relations). These flags are prone to errors and can become out of date in an instant (e.g. a bus+trolleybus stop, which suddenly has no trolleybus service because of construction works somewhere). --Zverik (talk) 10:47, 11 July 2018 (UTC)

In Belgium I'm starting to drop public_transport=platform from highway=platform/railway=platform WAYS, because people started to say why have public_transport on both a way and a node. The node is crucial, so that one gets priority for receiving public_transport=platform.

Why is the node crucial? Well that's the object that represents the stop, it's the only object that has tags for its details and it's the only object that goes into the route relations in the ideal version of PT v3.

In PTv3, all stop/station-specific tags indeed go onto the single object. But as for routes — that's what the PTv3 does not agree with you on: not stop objects, but platforms go into route relations. The reason is simple: how else do you detect which platform should you wait on for a specific route? --Zverik (talk) 10:47, 11 July 2018 (UTC)

When I say stops, I mean NODES tagged with highway=bus_stop/railway=tram_stop and possibly public_transport=platform + a mode of transport. There are not always actual platforms present. But if they are present, we can tag them highway=platform/railway=platform. I don't see a reason to add those platform ways/areas to the route relations though. as the NODES with all their details are already in the route relations to represent the stops.

I understand your intention: to get all the data for a stop and its coordinates without needing to collect an area or worse, a multipolygon. I would like that too. But to me, that would rob a route from important information. Imagine this: a railway station, four tracks and three platforms serving different routes. Would you like your navigation app to direct you to a correct platform? How does it know which one? --Zverik (talk) 15:05, 11 July 2018 (UTC)

I would put a node next to each of those platforms. More than one if the platform is subdivided into areas, which is then usually indicated by letters. (I would consider that if there are actually trains that use 'half' the platform, i.e. where it matters for the passenger). Now, there is nothing keeping anybody from using one of the nodes of the platform ways for that purpose. The node is like a "stand in". Easy to work with. Indeed like you say, all the information in one single object, readily available.

This 'simplification' does not impede adding platforms to stops, where they exist. Nor is it a problem to add waste_baskets, benches and shelters. Either as objects in their own right or as additional tags on the stop node. Or both, that's where redundancy doesn't hurt. It can even enable validation of the data.

Duplicating details like name, ref, operator, network across stop_position nodes and platform ways/areas is a maintenance nightmare, however. Especially if it means all of a sudden more than 1 object needs to be added to the route relations to represent a single stop in it.

How to deal with multiple platforms for a single stop?

I know cases when a subway train has platforms on both sides (and doors do open on both sides). I wonder how to deal with that, so that routers can adequately guide passengers to the required destination or choose the best path inside the station. (And yes, PTv2 does not seem to have a way to deal with that either.) Suggestion: only one platform goes to the route relation but all of them go to the stop area relation. Any idea how it could fit this PTv3 scheme? Bxl-forever (talk) 14:24, 20 July 2018 (UTC)

To me, a natural way would be to add both platforms to a route (with empty roles), and also add them both to a stop_area relation together with the station object. This way they belong to a single station. And PTv3 is all about natural ways, so why not :) --Zverik (talk) 14:38, 20 July 2018 (UTC)

Explicitly cover road treatments of bus routes

Even if it is the same as PTv2, list the case of a bus route that retraces on the same road A - B - C- B - A . Ways would be listed in order of travel and having no roles, possibly multiple times. MikeN (talk) 15:37, 20 July 2018 (UTC)

But this is the same as it has always been? What are the other options? I tried to keep the proposal as short as possible, to reduce the number of discussion points. --Zverik (talk) 15:43, 20 July 2018 (UTC)

Since this is a v3-only proposal my comment would not apply since that part will be the same as v2. (I'm still living in v1 days and was trying to visualize the migration). MikeN (talk) 17:07, 20 July 2018 (UTC)

Versioning

I must say I agree with pretty much everything set out here. I unsubscribed from the PT mailing list back in 2011 once it was clear that the stop_position idea was going to be insisted upon. However, I would love it if you removed v3 from the description: OSM tagging has little or no correspondence with versions of APIs or programming languages. One of the more absurd instences of PTv2 was the need for a version tag. I would hope that this ceases to be necessary under your propsals. I would prefer this was called something like "Proposal to rationalise PT tagging in the light of experience", and the v3 remains merely a convenient shorthand. SK53 (talk) 17:32, 20 July 2018 (UTC)

I understand your pain, and I watched with horror as JOSM developers — not the proposal author! — pushed their "public_transport:version" tag. Alas, editor authors have absolute power in OSM, but virtually no responsibility or understanding. Of course, I do not want to have another version pushed into tags. PTv3 is just a handy shortcut, so people know the context. Still, your suggestion is really good, and since "v3" is not mentioned anywhere in the proposal, I will think about renaming it. --Zverik (talk) 19:12, 20 July 2018 (UTC)

Seaway

Why not seaway=pier? Erkin Alp Güney (talk) 19:04, 20 July 2018 (UTC)

There are zero objects in OSM with that tag (and NINE in total with seaway=*). Why would I want to switch man_made=pier with 300k uses to it? --Zverik (talk) 19:14, 20 July 2018 (UTC)

How to tag request stops?

Is there an idea how to tag "request stops" (in German "Bedarfshaltestelle" or "Wunschhaltestelle")? It's a stop where bus/tram/train stops only on the passenger request (by raising a hand or pushing a button). Other stops on such network are mandatory. --diverpl (talk) 20:18, 20 July 2018 (UTC)

Pretty much all stops on British bus routes are request stops; and even to a certain extent this seems to be true at tram stops, in that the tram does not stop & open its door if there are no passengers visible at the stop. I would have thought a simple request=yes or mandatory=no would meet the need. SK53 (talk) 12:10, 21 July 2018 (UTC)

This is an interesting question, that calls for a separate proposal. We've had a few improvements to mapping routes recently, including "reverse" and "hail_and_ride" roles. I think we can come up with a way to tag such optional stops — but not as a part of this proposal. I'd like to keep this one as contained as possible. --Zverik (talk) 12:21, 21 July 2018 (UTC)

Add the role "request_only" to this stop in the route (similar to entry_only and exit_only) -- Corsa5 (talk) 12:47, 1 February 2024 (UTC)

Bus stops position

I found this a little confusing:

• on the one hand 'Bus stops should be beside a road' according to the first pic in 'Stops and Stations',
• on the other hand there are some examples further where bus stops *are* on roads (for example, 'Single bus stop and two platforms' in 'Platforms' ).

Is there no contradiction here? --Yegorm (talk) 18:53, 21 July 2018 (UTC)

I do not understand either, in the second case there should be 2 highway = bus_stop on each side. --AgusQui (talk) 00:27, 22 July 2018 (UTC)

I agree this is all quite confusing, and I'm looking for a better way to explain it or maybe change the rule. For now the stop or station node can be placed on road or tracks only when there is a platform object mapped. It is okay in any case to put the stop or station node beside a road or tracks. The reason for that is to know at all times where a passenger should wait — but not to make platforms mandatory. --Zverik (talk) 11:37, 23 July 2018 (UTC)

This ambiguity is a problem that was present in "PTv1", solved in PTv2, and this proposal reintroduce it. I think it would be better to be opiniated and enforce stop node position. --Gileri (talk) 08:42, 29 July 2018 (UTC)

I am strongly against tagging highway=bus_stop on road, in any case Mateusz Konieczny (talk) 10:27, 23 July 2020 (UTC)

What makes two stops identical?

I can't think of an example for "When stops are identical, you can use just one stop object". Could you please elaborate on that? What common attributes should two bus stops have to be considered identical? --Yegorm (talk) 19:51, 21 July 2018 (UTC)

Mostly I meant equal names, operators and identifiers in all the databases, e.g. GTFS and UIC. I have added this comment to the proposal, thanks. --Zverik (talk) 11:34, 23 July 2018 (UTC)

Stop positions in 'Stop Areas and Groups'

It's a minor one. In the current version we have stop positions listed as part of 'the minimum number of objects that comprise a stop'. Since stop positions are deprecated now, I guess they should probably not be present in the list. At least marked as optional/deprecated.--Yegorm (talk) 19:58, 21 July 2018 (UTC)

Thanks Yegorm. I wanted to show that stop positions should be in stop areas if they are present, since they are parts of a stop. But of course they are not part of the new schema. I've added a clarification there. --Zverik (talk) 11:22, 23 July 2018 (UTC)

Positions of highway=bus_stop and railway=tram_stop - an alternative idea

Hi Ilya! Thank you for your efforts for trying to make public transport tagging simpler. However I find it a bit confusing (especially with regard to new users) and inconsistent that you suggest that 'bus stops should be beside a road', but on the highway=* way in case there are platforms, and that 'tram stops on rails are discouraged, unless there are platforms'.

Proposed positions of highway=bus_stop and highway=tram_stop

I have an alternative, simpler idea: to map both highway=bus_stop and railway=tram_stop at the position where the vehicle actually stops, which is on railway=tram way for trams, but not necessarily on highway=* way for bus stops, only on very narrow (one lane) roads. And only highway=bus_stop's or railway=tram_stop's should be added to route relations.

While mapping in Switzerland and Belgium I found quite a lot of highway=bus_stop's that were placed neither on a highway=* way nor on a platform or sidewalk, but at the actual stop of the vehicle, e.g. in a bus bay. Some of these bus stops even were (wrongly) tagged highway=bus_stop + public_transport=stop_position. --SelfishSeahorse (talk) 22:21, 22 July 2018 (UTC)

Thank you for thinking up a better guidelines for placing a stop node, and especially for drawing a series of maps to illustrate your point! I am tempted to say that I don't actually care for position of stop nodes. But I do, and the reason is routing. Imagine an app that routes you, a pedestrian, to a tram stop. You would want it to bring you to a waiting place, not to the middle of rails (which is dangerous). When you have both a stop and a platform, it would work well, navigating you to the platform (provided you have a stop_area relation). But most stops lack platforms. In that case, I'd like stop nodes to be placed closer to waiting areas, "platforms". When a stop node is where a platform is, a stop position can be automatically determinde by projecting the node onto nearest tracks. And when a stop node is on tracks, you have no idea where to route a user. I'd be happy to find an easier way to explain where to put a stop node, that would also benefit data users, and I welcome your help in that. --Zverik (talk) 11:19, 23 July 2018 (UTC)

You are right, putting only highway=bus_stop's and railway=tram_stop's in the route relation indeed isn't ideal. But I've just had two other, even simpler ideas: please see the next subsection. --SelfishSeahorse (talk) 21:08, 23 July 2018 (UTC)

Back when I was adding highway=bus_stop/public_transport=platform nodes in Belgium, I had only Bing imagery to work with. What was clearly visible on it was the letter B U S for many of the stops (maybe 40%), so I put the nodes mostly on those Bs, when available. Now, with better imagery (and Mapillary), I would place them more or less where the pole is.

When I did add stop_position nodes on the highways, I'd do so next to where that B is.

We now also have a bus_bay tag, which I'm also using a lot and PT_Assistant provides nice support for the double splitting of the way that's involved when adding it.--Polyglot (talk) 11:58, 23 July 2018 (UTC)

I looked at your doodle, I fail to understand why the width of the way would make a difference for placing the node on or besides the road.--Polyglot (talk) 12:00, 23 July 2018 (UTC)

On one-lane roads, the highway=* way is exactly in the middle of the road. If there isn't a bus lay-by (bus bay), the bus stops more or less in the middle of the road. Therefore, highway=bus_stop would be placed on the highway=* way. I've replaced the sketch with a coloured diagram. I hope it's clearer now. However, as Ilya remarked, this suggestion is not ideal for routeing. --SelfishSeahorse (talk) 21:08, 23 July 2018 (UTC)

Two more alternative ideas for an even simpler public transport scheme

To summarise:

• public_transport=stop_position can be deducted from the waiting area and can thus be abandoned.
• For passengers, it's the waiting areas that are important.

Idea of a simple public transport scheme (first possibility)

Idea of a simple public transport scheme (second possibility)

This gives us two possibilities for a simple public transport scheme (see diagrams):

• Either we go for public_transport=platforms and begin to add bus=yes/tram=yes tags to it. For compatibility, highway=bus_stop and railway=tram_stop can still be mapped, but should not be added to route relations (except for public_transport=platform nodes, where it simply can be added to it).
• Or we stick with highway=bus_stop and railway=tram_stop, map both at waiting areas and allow both to be added to platform ways/areas, which would be tagged public_transport=platform (because highway=bus_stop + highway=platform or railway=tram_stop + railway=platform obviously isn't possible); see diagram. We could even restrict the meaning of public_transport=platform to real platforms.

The second possibility would allow more efficient mapping and were easier to understand, but it has the drawback that it isn't fully backward compatible – highway=bus_stop/railway=tram_stop on ways/areas isn't common (although iD adds highway=bus_stop to bus stop/platform ways and areas) –, whereas the first possibility were fully backward compatible, but more complicated. --SelfishSeahorse (talk) 21:08, 23 July 2018 (UTC)

Confusing illustrations

This figure is very confusing:

• 

It is not coherent with the text above ; quoting : "For example, a bus stop usually is a single highway=bus_stop node, which serves both as a stop object (i.e. it has all the attributes for a stop) and a platform (i.e. it denotes a physical object). For tram and railway routes, it is common to draw a separate platform, leaving a station node as a virtual object, or a stop position."

Even if situations like these, with one stop and many platforms, may occur, it would be much clearer to use railway=tram_stop as an illustration in the proposal to avoid confusion.

Same thought about this one :

• 

with the text saying the opposite ; quoting "For example, two bus stops with the same name on different sides of a road are two separate stops, and provided they have extra features (e.g. platforms), they should have two separate stop_area relations."

Singing-Poppy (talk) 18:54, 23 July 2018 (UTC)

I agree, I think it should be like this:

• 

A highway=bus_stop node to represent each stop separately (I do not understand why a single node should represent both stops as if it were a bus station), located where the signaling pole is or in the middle in case there is no . The highway=platform tag must be used to represent the real platform and should not be added to the route. The node bus_stop must be used in each stop that exists, if you want to group a group of stops as part of the same entity, for whatever reason, you must use a stop_area. --AgusQui (talk) 20:44, 29 July 2018 (UTC)

Can you please update the illustration or use the one from AgusQui to avoid confusion on this topic ? Singing-Poppy (talk) 16:50, 16 February 2020 (UTC)

Role for way stops

if you

• put platform (that is likely to be a way) inside a route relation
• omit the role (quoting : "Roles for stops are the same: stop or platform (do not matter and may be omitted)")

Then as a data consumer, you may have troubles to separate the way platforms from the ways that are route segments.

I think it would be better to specify a default role to use.

Singing-Poppy (talk) 18:56, 23 July 2018 (UTC)

PTv2 compatibility, simplicity and duplication

> This proposal tries to remain compatible to PTv2 as much as possible, but to make both editing and using routes simpler.

The proposal suggest to replace public_transport=platforms with highway=bus_stop (for bus stops). I don't think how that is compatible, or simple. Why not keep public_transport=platform and make public_transport=stop_positions optional ? The same effect would be achieved (mappers only have to map one node), the existing PTv2 data is compatible with this proposal, and it reduce the number of different tags used to map the same concept across different means of transport (what was mainly the goal of PTv2).

>If you wish, you can specify types of public transport that uses the stop or the station with bus=yes, tram=yes, subway=yes etc., although these tags are optional, often implied by the main tag

It is not useful nor simple, for producers and consumers alike. Either the proposal should keep public_transport tags and use bus=yes, tram=yes etc. (best way imo), or it can use dedicated tags for each mean of transport. But not both, it would introduce duplication and uncertainty for no reason. --Gileri (talk) 08:55, 29 July 2018 (UTC)

"The proposal suggest to replace public_transport=platforms with highway=bus_stop (for bus stops). I don't think how that is compatible, or simple. Why not keep public_transport=platform and make public_transport=stop_positions optional ? The same effect would be achieved (mappers only have to map one node), the existing PTv2 data is compatible with this proposal, and it reduce the number of different tags used to map the same concept across different means of transport (what was mainly the goal of PTv2)."

If PTv2 does not include using highway=bus_stop, and nevertheless it continued to be used even without public_transport=platform, why would it be different now? --AgusQui (talk) 21:07, 29 July 2018 (UTC)

Simple public transport

What most people are asking for is a simple public transport scheme. This one is not, in particular because stop_areas are used for different purposes above ground (only one stop) and underground (bundling all entrances).

I suggest the following alternative Simple public transport

I will make a proposal out of that in the next days. --Roland

Simple public transport scheme (grey nodes/tags are for compatibility with PTv1)

Hi! I was also planning to write a proposal to make public transport mapping more efficient. It seems that my ideas go in the same direction as yours. In my opinion, we only need to change PTv2 slightly:

• Public transport routes should include a platform for every stop. Because of unclear benefit of the stop positions (contrary to what was stated in the original proposal, they are irrelevant for routing) and because it should be possible to calculate them from the platforms, they don't need to (or maybe even shouldn't) be added to the route relations. (Actually this isn't a change, as this is already possible with PTv2.)
• The tags for the means of transport (bus=yes/tram=yes/train=yes/...) should be added to public_transport=platform and public_transport=station, so that the old tags (highway=bus_stop/amenity=bus_station/railway=tram_stop/railway=station) are no longer necessary for rendering.

Regards, --SelfishSeahorse (talk) 19:30, 30 July 2018 (UTC)

highway=bus_stop, really?

Thanks Ilya for assembling this proposal. I largely agree with the here proposed simplifications and approach. There is only one issue, I think we can be more progressive withː drop support for highway=bus_stop. Tagging an object on the side of the street with highway=* is confusing and feels very wrong. I suggest to introduce public_transport=stop. Of course, you can argue that fixing this misconception were not the focus on the proposal and I would be ok with it. Probably, it is more feasible to tackle this issue in a a separate proposal to change from highway=bus_stop to public_transport=stop.

Cheers, --Xamanu (talk) 18:40, 1 August 2018 (UTC)

pt=stop_position will be in the data for a long time to come, even if it does get 'deprecated/abolished' somehow. Wouldn't pt=stop be even more confusing? I see many people using pt=stop_position on nodes beside the way. Probably because they think bus STOP. So the confusion is definitely already present.

In places where stops don't have pt=platform/stop_position tags yet, (I'm mapping a bit here and there around the world to test PT_Assistant's functionality) I'm not adding them anymore. I do extract the highway=bus_stop nodes from the highways, and if needed duplicate them to both sides of the road. When not adding pt tags, I have the problem of whether to assign a role=platform or not. Either way, if the route relation is v2 (and when I decide to work on them, they always are), I always get a validator warning.

All that is not extremely important, I think. What I do consider important, is that we get to a system where each bus stop is represented exactly once, preferably by a node next to the highway.--Polyglot (talk) 13:23, 29 August 2018 (UTC)

I support everything except for using the old tags for platforms

This proposal is a fantastic idea! The most important part is that it would remove unnecessary and redundant stop positions. They are a mess the way they are now. Using just the bus stop or train station, with no stop position makes the most sense. Also, Google Transit manages to map bus routes without complicated stop positions, which indicates to me that they are not really needed. Stop positions can easily be derived from the location of the platform. The one thing I don't like is the switch back from using public_transport=platform. The whole OSM community is slowly moving towards using platforms instead of bus stops, and reversing this momentum would be very annoying for contributors. Platforms allow for many types of transport (bus, tram, light rail, etc.) to stop at a single stop just by adding <transport type>=yes to the platform. Converting back to the old system would make this much more difficult. Also, the platform system has much simpler tagging than the old system. You state that it would be easier for mappers to understand the old system, but this is only true because the old system is more widely used than the new system. After a large conversion to PTv3, this would no longer be an issue. I also support continuing to use the "platform" role in route relations. It just makes sense that each platform should have the role "platform". To sum it up, I support removing redundant stop_position features, but oppose switching back to the old method of tagging public transport stops.

Losing information through making route segments optional

I'm a bit worried that route segments (in the route relation) are getting optional. Is it really the kind of information we no longer need? To me it seems quite useful to see bus routes as lines going from start to end (but it's just me). I doubt this information can be easily inferred from the stop list.

Also, if we are perfectly sure, can we make them deprecated (as 'optional' seems a little vague ).--Yegorm (talk) 12:29, 29 August 2018 (UTC)

I think Ilya meant to make it "non-essential" to have the ways that form the itinerary. Making them 'deprecated' sounds like we would consider removing the ways. That would be a very strange evolution.

JOSM's PT_Assistant plugin now makes it quite convenient to add ways to route relations, which consist of only stops: https://www.youtube.com/watch?v=ArAVNscPCag (The first 6 minutes of that video are more or less OK, the rest of the hour I was recording not so much, the plugin has also evolved since then)

At the same time, it's also checking the route for ways where the bus would go against oneway or violate turn restrictions.--Polyglot (talk) 13:23, 29 August 2018 (UTC)

Polyglot, thank you for the video. I tried to reproduce your steps on a local bus route - what a great tool!--Yegorm (talk) 10:26, 1 September 2018 (UTC)

You're welcome. It's Biswesh who did all the hard work on implementing it. We're still refining the automatic downloading of objects. To make good suggestions the tool needs as much data as it can get its 'hands' on, but now it's downloading much of the same data over and over again. So let's call it work in progress, but I'm glad you appreciate it! I'm also hoping to be able to extend this to bicycle and foot route relations at some point. --Polyglot (talk) 15:55, 1 September 2018 (UTC)

Adding support for service stops and service relations

While I appreciate the general idea to make it simple and allow non-technical users to create bus routes easily, OSM is no longer just for hobbyists or to create simple apps for PT users. If we want to convince professional users, such as PT operators or public authorities to switch to OSM the data model should allow other cases as well. I believe we should aim for a scheme that does not exclude any of those categories of users.

I was more specifically thinking about:

• service stops: there is a stop post, it is clearly visible in public space and even has a name, but it is not to be linked to a route in particular because people are now allowed to board here (typically a stop used for timetable regulation or for drivers’ pauses). Either we create a separate category, e.g. highway=service_stop, or combine existing tags with access=no. (This would work for all modes of transport.)
• service/turnaround relations: it is very useful to map how the bus is going around the block, and this has many benefits for professionals dealing with PT operations (importing distances, localizing buses between two trips, seeing at a glance that a road closure will impact a bus route). We should think of a way to create such route relations, with appropriate tags so that apps that do not necessitate them, e.g. real-time info, can easily filter them out.
• multiple stop posts for one same stop: PT operators sometimes need to handle a complete inventory of all "accessories" on their network: stop posts, shelters, bins. I know of many cases where there are multiple stop posts on the same stop, sometimes for good reasons (in my country the law prohibits cars to park less than 15 meters from a post; we use several of them when it is necessary to create an extended bus zone at larger stops). I should think that holding multiple highway=bus_stop nodes in a stop area relation should be okay, but I’d like to hear thoughts about this, to avoid creating a scheme that would make such a situation impossible to map properly. Thanks. Bxl-forever (talk) 14:14, 6 September 2018 (UTC)

The complete GIS data that a PT operator would need cannot be completely added to openstreetmap, because not all of it is based on real-world, current information that individual mappers can check.

service stops - these would need a new tag, since a highway=bus_stop is a place where passengers get on or off. highway=service_stop is okay but not totally clear - its more an highway=out_of_service_bus_stop, no?

service/turnaround relations - this would be hard for volunteer mappers to add and maintain. Perhaps it's best for the PT operator to provide and maintain this data themselves.

multiple stop posts for one same stop - don't use highway=bus_stop nodes for this, but a tag that specifically describes the post or sign. There are a few uses of highway=street_sign and highway=traffic_sign but those seem wrong for a bus stop sign; perhaps man_made=bus_stop_sign on a node would be least ambiguous. --Jeisenbe (talk) 16:10, 29 July 2019 (UTC)

Route relation members at stations?

It is not clear to me what object at a (train/tram/bus) station this proposal requires be added to a route relation: the station or the platform? In my opinion both should be allowed: in case the vehicles always stop at the same platform, the platform should be preferred, but if this is not the case or if the station is underground or covered (and thus the platforms can't be mapped yet) it would make sense to add the station to a route relation. --SelfishSeahorse (talk) 08:17, 24 September 2018 (UTC)

Does a amenity=bus_station area replace the need for highway=bus_stop nodes?

I'm really liking this new proposal for public transport, the system is very convoluted. I still don't understand it entirely.

In my city we use highway=bus_stop for very simple stops on the side of the road. We are using bus stations for anything with clear station-like infrastructure or it has more then one platform.

Given this description, is it right to say that the area around the station tagged with amenity=bus_station would count as the stop? After all we have two (or more) platforms already mapped with highway=platform, surely a platform should imply a stop? I have attached a image showing how I've mapped some bus stations please give feedback.

I would love to see some visual examples/guides that use this schema on different real-world transport infrastructure types. Everything from Bus Stops (on the side of a road), bus Stations, train stations etc. I think the ones you've in the proposal are OK but I would really like a beginners page with showing recommend station schemas in full.

Unless you have information about the stops inside a station, it does not seem right to me that amenity=bus_station is considered a stop in the bus relation. I add to the platforms within the stations nodes highway=bus_stop to indicate in which part of the platform the bus stops, where the signal is, and where the passengers have to line up, it also serves for a router to indicate how to get there walking to the sector of the station where the bus leaves. Example: https://www.openstreetmap.org/way/224020991 --AgusQui (talk) 03:29, 14 November 2018 (UTC)

Thanks for the advice and the example! First, let me ask you if you would recommend having platforms as a way (like footpaths) as opposed to a closed ways (effectively a highway area)? Also that example had stop positions in use, should I avoid using those in my mapping projects? ClipArtJoel (talk) 05:21, 20 November 2018 (UTC)

If the aerial image allows it, area is preferable. The stop_position I add because it is what the PT wiki says what to do, but I personally think that they are useless.--AgusQui (talk) 13:44, 20 November 2018 (UTC)

Platforms are stops: only one OSM element

Hi Илья! You suggest to map a separate highway=bus_stop/railway=tram_stop node if there is a (physical) platform at a stop. In my opinion, this is redundant because the platform is the stop. It only complicates mapping unnecessarily – one would even have to add a stop area relation. It seems much easier to tag which vehicles operate a platform (e.g. transport_mode=bus/tram/bus;tram/...), in order that renderers can display an appropriate icon. Regards, Markus –SelfishSeahorse (talk) 21:41, 3 March 2019 (UTC)

Re: "one would even have to add a stop area relation" - I think this is unnecessary. If a highway=bus_stop is inside of a highway=platform area feature, that provides all the information that database users need to recognize that "this bus stop belongs to that platform", so a relation is not needed. --Jeisenbe (talk) 01:40, 8 September 2019 (UTC)

Re: "platforms are stops" - normally yes, but you can have a disused platform. It's still a physical platform, just like a disused station building is still a building, but it's not a bus stop or tram stop any more. --Jeisenbe (talk) 01:41, 8 September 2019 (UTC)

Looks great, let's vote!

I think this would be a huge improvement, and in fact it more accurately represents the way that most of the features are mapped: highway=bus_stop is still more common that all uses of public_transport=platform. Are you considering moving forward with this proposal to a vote? It's not really necessary, but I believe it's worth doing. --Jeisenbe (talk) 16:00, 29 July 2019 (UTC)

I agree.--PangoSE (talk) 22:46, 5 November 2019 (UTC)

stops should not be mandatory

For some routes, such as share taxis in rural areas, there are no stops at all. People can hail and ride everywhere along the route. So please don't make a route invalid because there are no stops. --Miklcct (talk) 05:29, 18 March 2020 (UTC)

Thank you for this reminder, I'll try to make it more clear in the proposal text. --Zverik (talk) 06:39, 18 March 2020 (UTC)

New scheme and: why hold on to highway=bus_stop?

I am currently also thinking about amending the p_t-scheme to be more simple on the surface, but relying also a little bit more on the way relations are used for the more complex aspects, which public transport undeniably has.

My idea would be: unify the tagging under "public_transport=platform" (then we no longer need differentiations in bus, tram, train-stops with different guids on how and where to map them) and use one tag that is universally true for all, and can be refined with being member to relations or extra tags if that does not apply. I will still work a bit more on my suggestion and maybe create a small video with my thoughts, but my minimal rework of the p_t:v2 proposal can be found here: https://drive.google.com/file/d/17CRv6K_SzoiEssfESXVJW0JSAx9-ClBq/view?usp=sharing

It would be great, if we could, about ten years after the mess with v1 and 2 was created, get properly a mandatory 2.5 version on the way, that uses the useful, unifying aspects of v2, builds on the relational (inheritance) idea and does away with double tagging and not really required tags like the stop position. Also, finally forcing the renderers and editor-programers to accept this scheme in its full potential, and not ignoring it, like it is now the case.

The platform tag might be a small misnomer in some cases, but so is almost every other tag in the OSM, so that should be the least of our concerns, especially as more and more stops get structures that can be called a platform. The days of random poles in a field are counted (at least in Europe).

Kind Regards RobinD.

Emergency99 (talk) 13:27, 11 July 2020 (UTC)

PS: Fore shared taxis, there also need to be the possibility to map the serving area, but that could then be an amendment-proposal. First, fixing the mess that already exsists should be the priority.

"then we no longer need differentiations in bus, tram, train-stops" - we still need this differences, such change would just make it harder to tag this Mateusz Konieczny (talk) 10:28, 23 July 2020 (UTC)

"finally forcing the renderers and editor-programers" - tag proposal are unable to do this Mateusz Konieczny (talk) 10:28, 23 July 2020 (UTC)

Stop areas

I do not think it is reasonable to require the splitting of a stop_area into multiple stop_areas (and ideally a stop_area_group) just because the stop is not at the exact same position in both directions. Or even if there is more than one line, stopping at different positions. IMHO, if the stop has the same name and is within walking distance of the other stop (i.e., they are the corresponding stop in the two directions of the same line or passengers are expected to walk from one line's stop to the other line's identically named stop), this is still logically the same stop and belongs into the same stop_area.

On the other hand, I consider stop_area_group reasonable to use only when parts of a large public transport node have different names. E.g., in Vienna, Austria, I would say that the stops "Hauptbahnhof", "Hauptbahnhof Ost", "Hauptbahnhof Süd", "Südtiroler Platz – Hauptbahnhof", and (arguably) "Kolschitzkygasse" form a group. If we already make the stop "Hauptbahnhof" a stop_area_group of several stop_areas, one for each stop_position, then we would need yet another layer (stop_area_group_group?!) for the whole node. I think that this would get messy really quickly.

And even in the most common case, where there is just one name, but 2+ stop positions (at least one in either direction), the proposal demands that we have at least 2 relations (and if we want to preserve the logical grouping for which the original stop_area was added, at least 3: one stop_area_group and 2+ stop_areas) instead of 1. I think this added complexity goes counter to the stated goal of the proposal, which is to simplify the tagging. --Kevin Kofler (talk) 01:23, 7 September 2020 (UTC)

PS: Oh, and keep in mind that subway (U-Bahn), tram (including the WLB tram-train within the city limits of Vienna), bus, S-Bahn, and even ÖBB train lines within the city limits of Vienna can all be used on the same integrated ticket system, so I do not see it necessary to split the different transport types either. --Kevin Kofler (talk) 01:32, 7 September 2020 (UTC)

I think that a stop_area should be used for grouping platforms which agencies consider them belonging to the same stop (but the actual stopping location may differ by the next carriageway or 10 metres apart), and stop_area_group should be used for grouping stop_areas where agencies consider them different, but passengers are expected to walk between them to make transfers in designated transfer routes. --Miklcct (talk) 09:45, 9 November 2020 (UTC)

I agree with this - if a station groups multiple platforms, then for buses we should group clearly-related stops. The UK Naptan schema works along these lines - stops are grouped into stop areas when they clearly form an interchange or are paired by direction; stop areas can also be grouped, to link whole interchanges together (like bus/tram/train) and this can be done recursively (with parent groups and child groups). Properly related stop areas and groups could massively simplify route-finding for public transport in OSM. --Tractiveeffort (talk) 10:05, 13 May 2021 (UTC)

Any comments on this from the proposal owner? What is the rationale behind that "A stop area must have just a single main object" rule? To be honest, I consider this rule as a showstopper (for the reasons explained above) and would have to urge everyone to oppose this proposal as long as this rule is present (which would be a pity because the remainder of the proposal is a step in the right direction). --Kevin Kofler (talk) 13:24, 21 July 2021 (UTC)

Comments and ideas

Comments

Main object

You base your rationale on whether the object is physical or not which is not the right approach for me, preferring to base it on infrastructure.

" (1) Until now, we pretended a stop is a physical object, which can be mapped as per "truth on the ground". (2) That's why we've got platforms and stop positions in PTv2 instead of some abstract bus stops. But this introduced many issues — exactly because a stop is a virtual object. It might not even have any physical manifestation — sometimes it's just a tiny timetable on a pole, or nothing at all. There would be no object to put public_transport tags on. But the stop is there — a virtual object does not depend on real objects. "

(1) No we did not, a highway=bus_stop or railway=tram_stop is the waiting area, the bus/tram/train usually stops in front or a few meters further.

(2) The idea of the stop_position started with a good principle when the waiting_area is too far from where the bus / tram / train actually stops. But we are talking about ten meters at most, which did not justify creating this object.

PTV2 is very confusing using "platform" for everything while the public_tansport=platform tag doesn't add anything new and interesting, it's a useless duplicate of highway=bus_stop or railway=tram_stop.

Section : Tagging Stops / Platforms

• section Tagging Stops "A stop or a station is a single object denoting an approximate location of where a vehicle stops to drop off and pick up passengers. It should be placed near a signpost or a platform, inside a station building, or between all the platforms for the stop."

That's a waiting area.

• section Platforms "A platform is a physical object — a signpost, a shelter or an actual platform — where passengers wait for their vehicle. Routing engines should bring users to a platform object for a stop or a station. Route relations have platforms for stops."

That's a waiting area.

What's the difference ?

The first one has no to little infrastructure (a shelter or/and a pole) and is mapped using a nod while the second has a dedicated infrastructure = a platform and is mapped using a line or polygon.

Now let's talk about the use :

Today, someone who wants to add stops to make a bus line will most of the time only add highway = bus_stop, it's simple and clear. Only advanced users add highway / railway = platform.

With your proposal, the same beginner user finds himself with two scenarios:

- the first one where there is no platform, it's like before, it adds two highway = bus_stop aside of the road.

- the second with a platform where it should put a single highway = bus_stop on the road.

And then to make the bus line, he must each time ask himself which scenario it is, whereas today stops are usually always on the same side of the road (right in Continental Europe).

In the end, it's more complicated than before. On the other hand you simplified the tag diagram which is a good thing.

Section : Stop Areas and Groups

Unfortunately it's like above, it's more complicated than before.

Ideas

If relations were the key ?

Bus / tram / trolleybus waiting areas whether they have a dedicated platform don't need a main element, while railway stations / subway stations actually do.

Then, what if we simply remove the railway=station virtual object and replace it with the stop_area relation ? The same as for any relation type=site.

What if we relied on infrastructure to make things more simplier ?

As SelfishSeahorse pointed out above, the platforms and stops (highway = bus_stop and railway = tram_stop) are the same and in practice I have noticed that users have already encoded routes which had lines or polygons tagged railway = platform + public_transport = platform as stops. Then why not merge both when we can ?

Case	A simple stop with no dedicated infrastructure.	A stop with a dedicated platform.
Illustration
What to use ?	Two nodes aside of the road or the rails.	Two lines aside of the road or the rails.	Two polygons aside of the road or the rails.
Exemples of tag scheme	public_transport=platform & bus=yes public_transport=platform & tram=yes public_transport=platform & bus=yes tram=yes	public_transport=platform & bus=yes public_transport=platform & tram=yes public_transport=platform & bus=yes tram=yes	area=yes public_transport=platform & bus=yes area=yes public_transport=platform & tram=yes area=yes public_transport=platform & bus=yes tram=yes

• This would replace the following tags : highway=bus_stop, railway=tram_stop, highway=platform, railway=platform.

• We would not need a dedicated platform tag since using a line or polygon would do the job instead.
• public_transport=stop could also be suitable instead of = platform and seems more natural to me.

For subways and trains, it would be no different, the points "railway = stop" and the polygons or lines "railway = platform" would be replaced by a single object as above.

Arflha (talk) 05:22, 26 August 2021 (UTC)

The name tag.

The name tag for all other OSM features is 'for the name only'. The PTv2 changes this ... by adding the ref tag to the name and the method of transport e.g. buss to the 'name' tag. Both of these can be obtained from the existing tags and do not need to be repeated in the name tag. Additionally the 'from', 'to' and 'via' tags look to be used. For constancy the name tag needs to remain 'for the name only'. There has been talk on the tagging list on this subject and a proposal to change the PTv2 use of the name tag. See https://wiki.openstreetmap.org/wiki/Proposal:Use_description_instead_of_name_for_route_relations Warin61 (talk) 05:19, 10 November 2023 (UTC)

Indication of locality on intercity and suburban routes

Support for specifying a locality is required. Those in addition to the from and to tags, add optional from_place and to_place tags. Then it will be possible to create routes Bus 1: [Moscow] Leningradsky Station -> [Moscow Region] Garden Partnership “Zvezda” Corsa5 (talk) 12:08, 1 February 2024 (UTC)

Not compatible with PTv2, should be PTv3?

Hi, The roles 'stop_entry_only' and stop_exit_only' are not recognized by PTv2 QA tools. Should the version be set to PTv3 to avoid any issues? Consider there may be other issues such as mappers replacing platforms with stops.

The use of PTv3 would enable the duplication of the relation so both PTv2 could coexist for the present with PTv3, thus keeping the present QA tools useful. Warin61 (talk) 01:14, 2 July 2024 (UTC)

Why? Aren't them incomplete for not supporting them?
—— Kovposch (talk) 04:48, 2 July 2024 (UTC)

This proposal adds the roles 'stop_entry_only' and stop_exit_only'. These roles were never part of PYTv2. Never. The QA tools are complete for PTv2 but not for the changes made by this proposal. Warin61 (talk) 07:33, 2 July 2024 (UTC)