Rethink the network tag for De Lijn stops and routes

Communities België / Belgique / Belgien (Belgium)
1

The purpose of this thread is to establish a consensus about the network tag for public transport routes and stops run by De Lijn.

Operator

The operator tag is not being discussed here. To clarify, operator=De Lijn applies everywhere. Even if some routes are run by private operators, passengers will see no difference and the tickets are the same.

Legacy practice

In the past, De Lijn was split into 5 operating units, one per province, each operating a group of routes.

A stop belongs to one network, which can be easily identified by its first digit (1 = DLAn, 2 = DLOV, 3 = DLVB, 4 = DLLi, 5 = DLWV).

A route belongs to one network. Same rule.

Stops and routes do not always match. For instance, Tienen Station is a stop in Vlaams Brabant, with network=DLVB. The stop is served by buses from Tienen to Leuven (network=DLVB on the route) and by buses from Tienen to Sint-Truiden (network=DLLi on the route).

Current situation

Since 2019, the organisation is made of 15 vervoerregio’s (VVR). Each route belongs to one VVR.

This is currently not visible in OSM data itself, except on the list of routes on the wiki.

Other Belgian networks

The other networks are easier to maintain:

  • STIB/MIVB is unitary (one network, one operator).
  • TEC is split into 6 operating units (one per province + Charleroi on its own) and the network tag can be reliably obtained from the operator’s open data. If a stop is served by routes from different networks, the network tag will concatenate all the networks (Fleurus Centre bus stop has network=TECB;TECC;TECN).

Proposal for route relations

Each route relation should be matched with the VVR that operates it. GTFS data looks like this:

Instead of network=DLAn, use network=VVR Kempen on the bus route relations.

This can be reliably established by parsing the identifier in De Lijn’s open data for 13 out of 15 regios: VVR Kempen routes match ‘%_1KE%’, VVR Kortrijk routes match ‘%_2KO%’… There is a data problem for VVR Dender and VVR Vlaamse Ardennen, which are grouped as one; attributing a route to the correct network requires manual work here.

Proposal for bus stops

De Lijn’s open data does not provide an easy way to match a stop with the corresponding vervoerregio. GTFS data will only provide this:

Option 1: Run a geoquery from the stop location and determine the VVR where it belongs. Apply a rule for stops outside Flanders (Tilburg goes with VVR Kempen, Brussels goes with VVR Vlaamse Rand, Maastricht goes with VVR Limburg…). It might work, however we have no confirmation that VVR run their stops this way.

Option 2: Use the same rule as TEC and concatenate all the network tags from the routes seen on this stop. Tienen Station will have network=VVR Limburg;VVR Vlaamse Rand

Option 3: Keep the current system as 5 units (DLAn, DLLi, DLOV, DLVB, DLWV) because the current numbering system groups them like that. It has the advantage of not disrupting the history of OSM objects.

Option 4: network=De Lijn everywhere. Probably the easiest solution.

2

If the organization based on the 5 provinces is replaced by an organization based on the 15 “Vervoerregio”, then, yes, we must reflect this in OSM and no longer use the 5 networks based on the provinces, which no longer mean anything.

However, we must distinguish between the problem of route relations and the problem of bus_stops.

For “route relations”, the proposed solution seems good to me as proposed.

For bus stops, I would be much more radical. Let’s completely remove all network tags (as well as the associated network:wikidata and network:wikipedia tags) from all bus stops (including STIB and TEC).

Why?

  • The network tag is described as “optional” in the wiki.
  • It is always possible to find the bus_stop network via the “route relation” to which it is attached.
  • In neighboring countries (Germany, France, Netherlands), bus_stops do not have a network tag and this does not seem to be a problem. In France, Osmose even indicates a warning on TEC bus_stops located in France and which have a network tag (L’opérateur devrait être porté par les lignes de transport et non par les arrêts).
  • Maintaining this tag is also complicated in cases where multiple networks share a bus stop. When a route is modified/deleted, all the bus stops concerned must also be modified (perhaps…) and this cannot be done automatically.
  • Maintaining the bus network in OSM is also a big job. Anything that can make it easier is welcome.
  • And finally, I would also suggest removing on bus stops the “operator” tags (as well as the associated tags “operator:wikidata” and “operator:wikipedia”) and the “route_ref:DeLijn” “route_ref:TECL”, “route_ref:TECX”… tags with the same arguments as for the network tag. All this information is redundant and complicates maintenance.
3

I prefer option 4, just network=De Lijn everywhere:

These vervoerregio’s are not surveyable. They look more like an internal detail of De Lijn’s operations than something that we should map.

2 Likes
4

I also like the proposal. I added the various wikidata entries for those VVM.

wwwouaiebe has a point about removing operator from the stops. I see many QA advantages with the current system, which had been created by Polyglot: this tag concatenates all the operators having a route relation on a stop. But under the wiki definition, operator should be the authority in charge of maintaining/repairing the stop (this is ambiguous: municipalities will repair the kerb while operators will repair their own stop post, while STIB/MIVB is in charge of bus platform areas within the Brussels-Region, contrary to the situation in Flanders and Wallonia). We might give some more thought about this, as a future improvement. Possibly with a new thread, for clarity.

5

OK, and thanks for the comments.

Did some testing to deploy the new values for network on route relations, it works fine. Will continue.

And for stops, option 4, network=De_Lijn or… option 5: network= then.

6

For me, the important question is whether the relevant information about the “vervoersregio’s” is publicly available somewhere. If this is the case, I believe the best approach would be option 1, where the correct VVR is determined for each stop. The fact that this is not common in France is irrelevant: there are plenty of tagging differences between Belgium and the neighbouring countries, such as addresses.

If this information is not publicly available, I would go for option 2. First of all, this is already done for TEC and thus already an established practice in Belgium. Second, this adds useful information on top of a plain network=De Lijn, which is completely redundant as it can be deduced by either the operator or route relations anyway.

I find the argument of simplication of the data inappropriate. All OSM objects can be simplified by removing data, and usually the people who raise this argument are not the ones maintaining the objects in question, so they are only complaining about someone else’s potential issues.

All of this relates to the network=* on the stops only, as I understand the situation for routes is clear.

I also think it’s important to update the wiki after any changes have been implemented.

1 Like
7

Very good point.

Assigning a route to a vervoerregio is public information, De Lijn publishes network maps per vervoerregio here: Netplannen (delijn.be).

The list of municipalities per vervoerregio is public too. But assigning a stop to a vervoerregio is not trivial. Some stops are geographically inside the territory of “VVR A” but are only served by a bus route from “VVR B”, which is the one taking the decisions about that stop. This would encourage using the same system as TEC (option 2). But it must be constantly kept in sync with the route relations, and this is more maintenance work.