Proposal talk:Simpler public transport route relations

I like this idea

I maintain some local bus routes and currently I have to map some as technically invalid PTv2 relations because the routes between the widely spaced stops aren't fixed, and the driver has been known to take different routes depending on traffic levels. If ways become optional and everything else is backwards compatible that makes the relations valid under this scheme.

-- EdLoach (talk) 10:41, 6 March 2020 (UTC)

Hey, I'm glad you like it :D

Unfortunately, I personally am not sure it solves the issue you're mentioning, yet. As I understand it, even the platforms by themselves indicate a canonical route to the router - the absence of via points does not mean "there is no fixed route". To address situations like this (SomeoneElse and tripoint in #osm also pointed these out), I added route:variable=yes under "Edge cases". Note that Stereo does not, as of our talk yesterday, consider creating a new tag for it to be a good solution, so it is subject to change. -- Contrapunctus (talk) 07:58, 7 March 2020 (UTC)

My "area" is: 4072 unique ways (in sum 596 km) mapped into 211 bus relations have led to 26364 members just to represent the path the buses take. Ample markup of "turn:lanes" and "sidewalk" have likely contributed to this inflation. I wholeheartedly welcome this "route by nodes only" proposal; it would really reduce this data monster with hopefully just a few "via" nodes. Jengelh (talk) 22:40, 15 March 2020 (UTC)

"(public_transport=platform with role "platform")"

Note that it may also be highway=bus_stop/railway=tram_stop/... node - what is both simpler, easier to tag and PTv2 compatible Mateusz Konieczny (talk) 11:01, 6 March 2020 (UTC)

I might actually be happy with any node with role platform. If that node has a ref and a name, we can use those; the rest we don't care about. There are cases of stops being used for both trams and buses, like Flagey in Brussels: same platform, etc. -- Stereo (talk) 13:16, 6 March 2020 (UTC)

Thanks for pointing those out. I've added references to PTv1 tags, to try and keep this proposal from becoming collateral damage in the PTv1/PTv2 holy war ;) -- Contrapunctus (talk) 13:35, 6 March 2020 (UTC)

optionality of public_transport=stop_position

In nearly all cases (that I am familiar with, primarily in Poland but also with some limited experience in other countries) tagging explicit public_transport=stop_position is waste of time as it adds no new information. In all cases known to me it can be easily automatically computed by finding point on a road, nearest to highway=bus_stop or point on tram tracks nearest to railway=tram_stop (and so on) Mateusz Konieczny (talk) 11:04, 6 March 2020 (UTC)

Stop positions can be automatically derived when ways are present. Consider a bus stop in the middle of two roads, both going the same way (like this). In this situation, a stop position can be used to show which road a bus takes. In this example, a via point would serve just as well, too.

While I've tried to make it clearer after reading your response yesterday - are you of the opinion that it is not clear in the proposal that stop positions and via points only need to be added in certain exceptional situations, i.e. where the router gets the route wrong? -- Contrapunctus (talk) 07:22, 7 March 2020 (UTC)

OK, in this case you can add way or via point to clarify which route it goes. In this case, with next stop at https://www.openstreetmap.org/node/5455135856#map=19/28.56510/77.24825 it would not be 100% clear whatever bus goes on main route or minor one. Thanks for providing this example! Still, tagging explicit public_transport=stop_position is generally unnecessary and waste of time Mateusz Konieczny (talk) 11:32, 7 March 2020 (UTC)

I agree on stop_position being a bit of a pain most of the time. I only ever saw one clever map by simon04 use them to draw half a ball marker on the right side of the polyline. In PTv3, you would only ever need to add them for disambiguation, like in that nice example Contrapunctus has. -- Stereo (talk) 12:15, 8 March 2020 (UTC)

When platforms aren't enough, vias may not be enough either

This route cannot be described by platforms alone, and vias aren't going to help either. It is a circular route, with spurs and repetitions. It traverses some ways twice in the same direction. It traverses some ways twice in opposite directions. This bus stop is on one of the ways traversed twice in the same direction, but the bus stops there on only one of those passes.

The route used to be sorted until I added a new spur to the Integrated Care Centre, then iD managed to scramble it in places. I re-sorted part of it until I had to give up with a headache. Last time I sorted it I used JOSM, but JOSM was so confused it insisted there was a problem even though there wasn't (or I was incapable of spotting it). See if you can figure out how the bus actually traverses the full route even knowing all the platforms, all the vias, and all the ways.

I've been experimenting with a superroute to handle it in a way that it's possible to then figure out what's going on (I made the individual relations route=experiment:bus to stop them showing on things like the transport layer until I'm happy with it) even if editors scramble the constituent routes (which were designed to minimize problems sorting the constituent routes anyway). Not quite finished yet, but good enough that you can see how the whole route actually works (turn off all the layers but the first, then turn on the second and turn off the first, etc). Note that uMap and Overpass-turbo don't always place nicely together so you'll likely see some error messages waiting for constituent routes to appear and may have to zoom in and out a couple of times to get stubborn constituent routes to appear. Now figure out how your "plaforms and vias" idea would adequately handle that route.

--Brian de Ford (talk) 16:05, 6 March 2020 (UTC)

You would have to put your stops in the right order. The router would then see A, B, C, B, D, E, and draw a route that takes the shortest path between each pair, even if that takes you past another stop of that route. I have no idea how people in Cardigan even make sense of that crazy bus route, but I know it can be described as a list of platforms with maybe some vias. -- Stereo (talk) 18:37, 6 March 2020 (UTC)

The stops, as shown by the map pins on the uMap, are in the right order. It's not enough. Vias might be sufficient, if you were very careful about placement and if routers guaranteed to take shortest paths between vias, and if you were lucky. And then people could look at the route computed by the router and still have no idea how the bus traverses it (just as they have no idea when they look at the whole route mapped conventionally). If I could guarantee the whole route stayed sorted, and a tool came along that could do a step-by-step walk-through, then either PTV2 or PTV3 would be enough to make sense of it. But the route doesn't stay sorted and there are no walk-through tools, so the only solution I've come up with that makes sense of a crazy route (actually, some of the craziness is forced by the one-way system and makes more sense once you understand the one-way system) is the superroute/uMap combination. I'm open to better solutions, but this proposal doesn't seem to be up to the task. --Brian de Ford (talk) 18:59, 6 March 2020 (UTC)

You probably want the quickest route when driving a bus, not the shortest, really. The route is a lot easier to keep sorted for humans when it's only stops, and if it's the one-way system that's causing all this, why not let a router figure it out? There's an example in the FAQ and a lot of one-way streets in Luxembourg city centre if you want to play with the idea a bit. -- Stereo (talk) 12:06, 8 March 2020 (UTC)

Include the itinerary as subrelations

I have been giving mapping of PT a lot of thought over the years. For me the way to simplify it, would be to use subrelations, that would be easier to maintain. We would only have to fix the subroutes once to fix the actual routes. Personally I am not a fan of having to recalculate the itineraries over and over again, when we want to render them, but I would like that we simplify how we map PT. For example not duplicating information between platforms and stop_position and telling mappers they need to add both to the route relations.

I would also like that we can map railways (at the very least trams) the same as we do with buses. (or rather the way I like to map buses, only platform nodes have the details, and only those represent the stops in the route relations.

And then, since it has become clear after 8 years of asking that our carto renderer will never actually render public_transport=platform/bus=yes, if it doesn't have highway=bus_stop, I'm starting to wonder if it's even useful anymore to add these tags at all to the bus stop nodes.--Polyglot (talk) 20:41, 6 March 2020 (UTC)

Pardon me for addressing only two issues, for the moment -

1. Re: "telling mappers they need to add both [stop positions and platforms] to the route relations." - I tried to make this clearer in the proposal yesterday. Can you take a look again and let me know if it is clear that stop positions only need to be added in some rare, exceptional situations?
2. Re: PTv1/v2 holy war - another thing I tried to make clearer yesterday. Can you look again and let me know if you think the proposal is neutral with regard to PTv1/v2? The proposal is primarily about removing route-ways, letting the router derive them, and giving it hints when required - taking sides in PTv1/v2 will distract everyone from that. -- Contrapunctus (talk) 07:44, 7 March 2020 (UTC)

Optional platforms/stations

We may be removing route:variable=yes, primarily because we feel it is hard to define, and easily handled with variants - especially with this schema, where creating and maintaining variants is a vastly easier task thanks to route ways being taken out of the picture.

That said, I made personal notes in February this year about an idea which may reduce the need for variants in some situations, and may provide some valuable information to users. It may be a worthy candidate for inclusion in this proposal - let me know your thoughts.

---

In my personal experience with buses in Delhi, a stop may be skipped by buses for reasons of expediency. Examples -

• 392 may skip Rajnigandha Chowk, taking the underpass instead of the links.
• Routes 740, 85, and 534 are known to skip Vijaylakshmi Apartments, opting to travel via AVB School instead (and dropping off passengers there instead).

Currently, tagging these is achieved by creating additional route variants. This has a few shortcomings -

1. If using ways and stops in the relation, there is a significant amount of duplication and extra maintenance overhead.
2. If using only stops and via points (PTv3), the burden of maintenance is not so significant, but there is still inelegant duplication.
3. Most importantly, map applications should inform passengers that buses may or may not stop at such stops, preventing them from excessive waiting. Multi-modal routers could even prefer to guide passengers to non-optional stops rather than optional ones.

Therefore, I propose the "optional:" role prefix to denote such platforms.

These will be most effective with PTv3 - routers will be able to generate alternative routes from optional stops. But even with ways and platforms, these will help save time for editors, maintainers, and end-users. -- Contrapunctus (talk) 16:06, 12 March 2020 (UTC)

Giving up the ways in PT-Relations

Yes, we can do that. But then we should give them up completely and not try to replace them by router results.

Mapping errors in the ways will lead to good looking maps with wrong routes. The resulting PT-Maps cannot be trusted without checking each and every route on the map. And we will have to do that every time a new map is generated.

Example for the bad things done by automatic routing:

https://tracker.geops.ch/?z=15&s=1&x=774255.9911&y=6609848.8940&l=transport

Everything looks good until all of a sudden a tram starts a very high speed run through Cologne because someone used the wrong platform for just one station of the route. A year ago we could see on the same page all the IC and ICE trains between Cologne to Düsseldorf leave their route along the river Rhine ... probably because just one railway switch was erroneously mapped. (Weide)

That's a really cool map! I don't see the rocket tram there at the moment however.

Mappers would have the calculated routes displayed in their editors as they update them to avoid mistakes from blind mapping.

We also have something very useful we can use to detect such mistakes: QA tools can use available GTFS feeds and notice that a line is different in the gtfs, and/or moving at an unrealistic speed.

-- Stereo (talk) 10:01, 16 March 2020 (UTC)

The "rocket tram" is number 5 I believe (click around a few times to find one vehicle of that kind), when it moves between "Dom/Hauptbahnhof"<->"Rathaus" and "Rathaus"<->"Heumarkt". —Jengelh (talk) 10:51, 16 March 2020 (UTC)

Agreed w.r.t. GTFS, but GTFS is not always available and available with suitable license. I'm currently working on GTFS integration into PTNA and see also errors in GTFS data, ... --ToniE (talk) 12:19, 16 March 2020 (UTC)

In most cases the problems with automatically calculated routes will be caused by mappers not editing PT who do not know that they are changing PT-routes. The cannot know it, as they are editing ways which are no longer part of the relation. The editors won't notice it too, as we cannot expect them to calculate all potentially involved PT-routes just because someone edits a way. (Weide)

I have the same idea

Look here: https://forum.openstreetmap.org/viewtopic.php?pid=778475#p778475

I make a GPX out of a relation. The GPX I make a routing request.

-- (Miche101 08:34, 16 March 2020 (UTC)

Now i can work with "via" Role :-)

https://greymiche.lima-city.de/...e/index.html?relation=10864504

https://www.openstreetmap.org/relation/10864504

https://graphhopper.com/maps/?point=48.220...&layer=OpenStreetMap

--Miche101 (talk) 20:19, 19 March 2020 (UTC)

I also like this idea

First of all, I'm 'pro' for this proposal: it'll make routes more simple. What I see is the similarity to GTFS: define the locations of the 'platform' (as node) and as an optional part define shapes with what you call here 'via' points.

And now for the but or more pricse the questions from my QA and mapper perspective:

• during creation or maintenance of the relation, how can we show the resulting route to the mapper so that she/he can immediately/easily check for correctness or lack of 'via' points?
• can we create some guidelines on when, where, how and how many 'via' points or/and 'stop_positions' to incude into the relation?
  • 'via' point as normal node of a way (e.g. in a curve) can easily be deleted if the mapper ignores the warning of JOSM or iD
  • 'via' point as the intersection point of a T-like junction: a mapper might create a dual-carriage way for the vertical part of the "T".
    • The 'via' point needs to be doubled if, for instance, the bus comes from the south and turns to the east (and vice versa):
      • one for the direction A -> B
      • one for the direction B -> A
  • how can we ensure/check for right positions of 'via' points at intersections (see above)?
• how can we ensure that ways in a large stop area are used correctly?
  • they usually have access=no|private and should have bus|psv=yes but often this bus|psv=yes is missing - how can we detect this missing tag?
• how can we ensure that ways with oneway=yes are used by the routing-SW if oneway:psv=no or oneway:bus=no is missing, although the bus is allowed to use the opposite direction?
• does the routing-SW need a 'psv' profile to cover psv=yes, oneway:psv=no, ...
• how do we detect changed routing due to highway=constuction?

--ToniE (talk) 11:50, 16 March 2020 (UTC)

I like the idea, but...

Simplifying the mapping of public transport routes is one of the things that I consider most necessary in OpenStreetMap. I've been trying to insert all the bus routes in the Metropolitan Region of Rio de Janeiro into the OSM, but you can imagine how difficult this task is. On the other hand, my main need is to have the bus route itself, and not exactly theirs stops.

I would like to know if with PTv3 I would be able to make a request - via Overpass API, for example - to download bus routes, and if there is any example of how this would be done.

--Guilherme B Alves (talk) 16:25, 16 March 2020 (UTC)

What about PT route names?

I really liked the idea as it would simplify public transport tagging and it would steer out of the complexity and the controversies of PTv2.

There's a topic that I feel is really important and haven't had a solution in the past decade or so, and that is route relation naming. The current consensus for PTv2 and tools like PTNA is to add the route name to the name tag of the route, and lots of people have talked about the pros and cons of it. I'd like to know if there's an idea in mind to finally solve this problem that's been around for many years. Perhaps a new tag, related to public transport, that includes the route name?

FWIW the current naming scheme some people adopt is similar to the following example: Bus 1234: Point A <=> Point B via Point C

--Aoalmeida (talk) 23:06, 17 March 2020 (UTC)

Similar to the "Refined PT" proposal

Why make another one that makes 90% of existing routes incompatible with the schema, when you have the Proposed features/Refined Public Transport which does almost exactly what you need, while being compatible with what we already have and all the corner cases? Yes it doesn't allow for "via" nodes — but having OSRM as a requirement for building a route is a bit too much, I'd prefer all the required data to be in OSM itself. --Zverik (talk) 14:40, 22 March 2020 (UTC)

Unless I missed something, RPT doesn't meet their most important need. Their problem is that, for long distance routes, adding ways, splitting ways where necessary (and even splitting roundabouts if you're a perfectionist) is a lot of work.

However, the fact that this doesn't guarantee that the canonical route is what will be rendered on the map makes it a non-starter for me. For a long-distance route, I'd prefer only having names of the limited number of towns where the bus stops to having a map that is wrong. Because the moment the bus starts following a different route to the one shown on the map is the moment I start to worry I'm on the wrong bus. And whether I'm on the right or wrong bus, that's the moment I decide the map is worthless and I won't use it again for anything at all.

It also (last time I looked) had no sensible provision for hail-and-ride routes because it couldn't guarantee the canonical route would be rendered, no matter how many vias you add, because changes to the surrounding road network or changes to speed limits could change the way it's rendered.

I have every sympathy for those trying to map long routes. I just don't think this is a good solution. I think I may have come up with better solution that all of us can live with (although it doesn't do everything the proposers want, it does a lot of it), but suspect the proposers are too committed to even consider it. So there's probably no point me spending a lot of time going into detail. --Brian de Ford (talk) 15:21, 22 March 2020 (UTC)

You make a good point, Brian. To me, ways inside route relations are redundant (I'm interested in stops), but I see how making them with OSRM instead of adding each way manually might seem the best option. Been there too :) Regarding the hail-and-ride, I'm currently considering how they can be mapped with minimal change to the schema.

What I don't like about the proposed schema, is that 1) they are naming it PTv3, contributing to the current confusion, 2) keep stop positions and don't clarify their role (right now it seems we again need to map both platforms and stop positions), 3) forbid adding route ways at all, making most of the existing relations not conforming to the schema. The wording is very, very vague, so the proposal introduces more confusion than it solves. I'm pretty sure that if the proposal was thoughly written and thought-out, it would be even more complex than the "Refined PT" proposal. --Zverik (talk) 15:31, 22 March 2020 (UTC)

If I understand it correctly (probably not) and have correctly divined their intentions (probably not) stop positions are essential vias so that the router can find an unambiguous route. My town's "bus station" has three parallel, closely-spaced service roads. Each physical bus stop could serve a bus on either of two service roads (in practise that doesn't happen, but a router couldn't know that). So to ensure the route is correctly mapped, I'd need a via on the correct service road near that bus stop. If I need that anyway, I might as well call it a stop position because that's what it is. Or maybe they want stop positions for some completely different reason.

My other big objection is that they are now talking of making this a mandatory replacement for the existing schemas. If they get their way (not that there's a chance of retagging all the existing routes, but editors might drop support for adding new routes using any of the old schemas) then we'll all be forced to use it even if it makes it harder for those mapping shorter routes, and even if it results in non-canonical routes everywhere. --Brian de Ford (talk) 15:46, 22 March 2020 (UTC)

Thinking like a router

While the idea is original and the resulting route relations look light and pretty, there is one serious flaw at the core. And that is — when mapping, a person should always keep in mind that a router is unpredictable, especially when the engine and its version and its profile are not fixed in the tagging schema. Mappers would need to think not like mappers, but like routers.

GraphHopper would build a route different from OSRM. Subway or tram routing are even harder to implement and make available publicly. When making a route in New York, for example, with its grid-like road plan, you cannot always be sure which turn a router would take, so you would need to add every intersection to the route as a via point. And due to these node not having any names, supporting such a route might become much harder than an old PTv2 relation.

There is a good point about sustainability: ways in route relations are often broken. I agree. But the proposed schema does not make unbreakable routes — it just shifts the point of break from a fixed list of ways to basically all the ways and relations around a route. Change a turn restriction, update a speed limit — and you don't know how many bus routes you have broken with the edit.

I like how the proposal shows that there might be unexpected and interesting solutions to common problems. Using via points is a great idea. But for the proposal to work as an actual PTv3, you need to consider all the toure types, all the edge cases for public transport. List all extra tags, show how this applies to ferries, subways, trains and so on. If there is an external dependence (like OSRM), there need to be a public instance for every route type available to editors and renderers. Until then, this is a mere thought experiment — great, but not practical. --Zverik (talk) 19:54, 22 March 2020 (UTC)

Another problem if relying on a router built into a renderer is there will likely be delays (worse than the ones for standard carto being updated) because of the router, making the edit/verify cycle slower. Which is partly why one of the proposers suggested that editors incorporate routers. But then you have the problem that the router in the editor may use different algorithms/weightings than the one in the renderer (and different renderers may use different routers).

The problem with iD scrambling the order of ways (it's not as bad as it was a couple of years ago) affects maintainers but not consumers. The transport layer shows the same route no matter how the ways are ordered. This would be a problem if we had a "walk the route" tool to allow consumers to see how complex routes are actually traversed, but we don't. If the order of vias gets scrambled, you'll get a crazy mess. I don't recall seeing iD scramble the order of bus stops in a route, but people come up with new editors that may scramble vias. --Brian de Ford (talk) 20:33, 22 March 2020 (UTC)