Talk:Proposed features/Refined Public Transport
- 1 support eliminate stop_positions
- 2 bus_station
- 3 highway=bus_stop/railway=tram_stop on nodes next to the highway
- 4 How to deal with multiple platforms for a single stop?
- 5 Explicitly cover road treatments of bus routes
- 6 Versioning
- 7 Seaway
- 8 How to tag request stops?
- 9 Bus stops position
- 10 What makes two stops identical?
- 11 Stop positions in 'Stop Areas and Groups'
- 12 Positions of highway=bus_stop and railway=tram_stop - an alternative idea
- 13 Confusing illustrations
- 14 Role for way stops
- 15 PTv2 compatibility, simplicity and duplication
- 16 Simple public transport
- 17 highway=bus_stop, really?
- 18 I support everything except for using the old tags for platforms
- 19 Losing information through making route segments optional
- 20 Adding support for service stops and service relations
- 21 Route relation members at stations?
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)
- 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)
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)
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)
- 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)
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' ).
- 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)
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'.
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)
- 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.
- 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
public_transport=stop_positioncan be deducted from the waiting area and can thus be abandoned.
- For passengers, it's the waiting areas that are important.
This gives us two possibilities for a simple public transport scheme (see diagrams):
- Either we go for
public_transport=platforms and begin to add
tram=yestags to it. For compatibility,
railway=tram_stopcan still be mapped, but should not be added to route relations (except for
public_transport=platformnodes, where it simply can be added to it).
- Or we stick with
railway=tram_stop, map both at waiting areas and allow both to be added to platform ways/areas, which would be tagged
highway=bus_stop + highway=platformor
railway=tram_stop + railway=platformobviously isn't possible); see diagram. We could even restrict the meaning of
public_transport=platformto 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 –
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)
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."
- 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)
Role for way stops
- 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.
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
- 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)
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.
- 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)
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.
- 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)
- 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.
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)