Public transport routes

Hi,

I need to map a bus route which has 6 “options”, I might think the English also be variant of this route.

Is anything wrong with mapping the main route as one relation, and mapping the variant as separate route instead of duplicating the first one and adding the variant to it ?

This way we get :
Bus route from A to B
Variant 1
Variant 2
Variant 3
Variant 4

There is nothing wrong with that. On the contrary, mapping each variant as a single relation is the recommended way.

You can create one route relation (“type=route” + “route=bus”) for the trip from A to B. Then another route relation for the trip from B to A.
And you may add other route relations, for instance from A to B via C. Those tags (“from”, “to”, “via” are part of each relation). The “name” tag can be slightly different, or you can use the “description” tag to explain what this relation is for.

And on top of that you create a relation with “type=route_master” + “route_master=bus”. That relation contains every individual route relation.

I have an example in Brussels you can use: bus route 41 has a different itinerary on Saturdays and Sundays. https://www.openstreetmap.org/relation/86595

Sorry I wasn’t clear,
I meant only map the variant without the main route (only via C in your exemple, or https://www.openstreetmap.org/relation/11601128#map=13/50.4161/4.4536)), this makes things easier to manage as some route (the 109a in Charleroi for exemple have 15 different routes in each direction).

It will certainly render well on the Transport or ÖPNV layers. If you need nothing more than that, that’s fine.

One major drawback is that your relations are no longer routable.
Let us consider this: someone creates an app with bus timetables and must assign a timetable to a bus journey from A to B via C. That journey will use a bit of the main relation, then the short variant, then again a part of the main relation. It might be tricky and error-prone for complicated routes. That’s why full route relations are preferable, despite it requires more work and data duplication.

Public transport timetabling software such as Hastus is now able to deal with short segments. Typically, the junction will take place at a stop (stop position node in OSM), not at a street corner.

I would love to hear whether someone has found a reliable way to deal with incomplete route relations in OSM.

Yes, it will show up on the Transport map as on openptmap. ÖPNV doesn’t seem to be updating since one week ?

We may not need the relations to be routable within OSM, yet for third party users, one way we solve this issue is to have the relation split into different ones,
Relation 1 : A-B
Relation 2 : B-C
Relation 3 : C-D
Relation 4 : Between B and C via X
Relation 5 : Between C and D via Y
Then people willing to use those to make timetables would then need to tell the software :
First service : Combine relations 1-2-3
Second one (via X) : Combine relations 1-4-3
Third one (via X and Y) : Combine 1-4-5

It is a clever hack indeed. But apparently not the recommended way.

I understand you want to avoid the trouble of creating several route relations that are almost identical.
This is a forum, maybe someone else has experience to share about how to deal with such a case.

OSM is just the database. All maps, including those on osm.org are ‘third party users’.

These third party apps can only work if people map the routes according to the agreed scheme, so one complete route relation for each service. If everyone invents their your own way of tagging, all those apps would break.

In Belgium this can sometimes seem like a bit overkill, because their can be many variants of one bus line, but it’s important to map consistently. An easy way to map bus lines this way is to copy the original relation and change it to match the variant service.

You do this with relations and one master relation. For each routing of the line you make one relation and you group them all in a master relation. For example https://www.openstreetmap.org/relation/9086777

The idea Arflha has has been proposed before as an evolution to the current way of mapping routes. You can even go a step further and map each route between two stops as a relation and then make a grouping relation where you add these relations together.
But that has only be discussed, nothing really came out of it.

To answer @A67-A67, this depend on which 3rd party apps you’re talking about, ÖPNV map work perfectly this way.

I didn’t except this exemple yet thanks as it is so far the best exemple of why I’m against this way of mapping bus routes given the “each different routing/service gets its own relation” rule :
It is oudated since July 2019, as the line was splitted in two (109a, 109b).
It’s incomprehensible to understand unless you like headaches, and still, it’s wrong… and if we want to follow this rule you need 29 relations in each direction, where there are only 15 as of now ! And that’s not the worst bus route in the region…

But then I ask myselft, why do we need each different service to be routable, we’re no public transport agency, OSM is intended to *creates and distributes free geographic data for the world.**, we’re not responsible for making bus schedules. *OSM Wiki Main page (CC BY-SA 2.0)
Still, if a public transport agency want to use OSM bus routes to make the bus schedule, then it might consider using the solution I suggest in my last post, but in my opinion this rule is irrelevant of the project, as long as each line is mapped correctly I don’t see the need for each service to have its own relation and be routable.

One last things, in the proposal for Public Transport V2 it was never explained why each service needed to be routable… This rule was implemented even though in the proposal it was not based on any justification, nor even when it did not take into account the different realities, sometimes too complex to be easily used with this method, nor even when it did not met a real but assumed need for scheduling, even when it’s not the best way of doing so.

This will in no way be solved by doing it differently. If you make variants of one main relation, it still would have been outdated and wrong, probably after a year which is why you need to keep updating PT relations.

One of the problem with variants is that there may not even be a “main” route. Suppose there are two routings in one bus line, one does A-B-C-D-E, one does A-B-F-D-E. Which is the main route and which is the variant?
If you want to visualize this, how do you do this with for example one route A-B-C-D-E and the other B-F-D? How do you add the A-B and D-E sections in the visualization? That needs serious processing of the routes.
It is much simpler when you map each relation separate.
A bus company will also have that. They don’t make their routes like “this is the main route and these are just the deviations of the main route”. You need a full route to show your schedule.

This can be solved by having a far more easier way of mapping it, managing 20 relations each with only one unique role, none overlapping another, is far easier, as we could simply modify, delete or move the specific relation instead of having to modify 48 relations each having 70% of its content duplicated.

Have a look at the timetables or maps, most of the time it is specified, otherwise either the one with less services is the variant, or there are two alternative routes each getting 50/50% (see bus 63 in Fontaine-l’Évêque), but still, we don’t need to tell OSM, this relation is a variant, this one’s not, unless you want them to appear in a different way on the map.

I don’t get what you call “visualization”, mapping each variant as a single relation works fine with ÖPNV or openptmap.

We’re no bus company, there never was any explanation on why bus routes need to be routable, except if you want to do bus schedules, which is not the aim of the project. If you want the routes to be routable for a bus company to use those, then you have these relation :
AB
C
F
DE
Each being unique, and then the 3rd party app may use the solution I propose in my third message so as to make bus schedules*, but we don’t need each bus service to get a routable relation, and the way we do it actually makes it difficult to keep the lines up to date.

*With your exemple
8:00 AB-C-DE
8:10 AB-F-DE
8:20 AB-C
8:30 AB-F-DE
8:40 AB-C-DE
8:50 AB-F-DE
(…)

.

How is 19 routes that are a subset of a complete route better to manage than 20 complete routes? Then for all 19 you have to look up what the subset is, in stead of just mapping 20 routes.

I see lots of routes where you just see the different times next to each other with no indication what the “normal” route is. There is not even always a route that is taken the most.

There are more visualizations than just a map. For instance the Overpass Public Transport scripts.

You still need to keep that list current. And you need to keep the sections current. I don’t see that taking less effort than having the comple route. It certainly will not solve the problem that you need to keep updating bus routes because they will change.
And maybe you don’t want routable bus routes, others may want that. I don’t think it the routable that is so important, I think the fact that it is a line is important.
There is also no need for routable hiking or cycling routes. Oh wait, there is. So why not for bus routes? Just because it is a company that runs the bus?

If you ever want to use the information, you will need much more processing if you split the relations.

29 complete routes not 20, nor 15 for bus line 109a

Because each of those relations have a unique role without a relation overlapping another as it is now and you only need to change the one that needs to. It makes things easier and quicker to manage with less chance of making mistakes than if you have to do it 10-30 times.

Let’s take an example, let’s say bus line 109a gets it terminus moved from Charleroi-Sud to Charleroi Beaux-Arts :

  • The way I propose :
    Remove Charleroi Sud stop from relation 01###### and add Charleroi Beaux-Arts
    Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 02###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts
Done

  • The way we do it as of now
    Remove Charleroi Sud stop from relation 01###### and add Charleroi Beaux-Arts
    Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 02###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 03###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 04###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 05###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 06###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 07###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 08###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 09###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 10###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 11###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 12###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 13###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 14###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 15###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 16###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 17###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 18###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 19###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 20###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 21###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 22###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 23###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 24###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 25###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 26###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 27###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 28###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 29###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

Remove Charleroi Sud stop from relation 30###### and add Charleroi Beaux-Arts
Remove the ways to Charleroi Sud and add those to Charleroi Beaux-Arts

(… There should be 29 relations in each direction for the route to be correct while there are 15 as of now).
Done
And this is only a simple exemple, not taking in account timetable changes nor line splitting*.

  • Which we need to do for bus line 109a.

I already answered this question in my previous message, “We don’t need to tell OSM, this relation is a variant, this one’s not, unless you want them to appear in a different way on the map.”

And it works fine with the way we map bus routes :


Why do you want routable bus routes then ? Tell me why, I don’t get it. Are you in charge of making bus schedules ? They aren’t even up to date.

Hiking routes nor cycling routes don’t have timetables and different routes depending on the time it is, this is another subject with no common point with bus routes.