- Data comes from upstream operator
- Mending of broken data already present in OSM.
In public transport we have lines that serve stops.
Those lines have an identifier, they also have one or more variations of itineraries the buses or trams follow from start to terminus.
In its simplest form we can map these route relation as a sequence of stops, followed by a sequence of ways. Doing it this way gives a nice overview of the stops and allows the relation editor to show that the route is continuous (made obvious by a long vertical line). If the line is not continuous, I call the route relation broken.
Broken (discontinuous) or invalid routes
There are many reasons why route relations tend to break: users editing the map, without realising there is this "higher level" is the most common reason for the route to become discontinuous.
Another reason why a route may become "invalid" or at least not representing the reality anymore are changes made by the operators.
This also happens all the time.
So doing quality control implies checking for continuity, but also checking whether the route variations we describe still contain the same sequences of stops as what comes from the operator.
This brings us to the starting point for this plugin: It should be able to detect and mend routes with as little input from the user as possible But it should also make it easy to start from a sequence of stops and be able to add ways to this relation.
Optionally it should be able to add stop_positions to the route relations, or even create stop_positions, if they are not present yet.
It could also create stop_area relations to make linking of stops as independent nodes next to the way to the way the bus will travel over while heading for the next stop.
Some may prefer these stop_areas to include all the stops and stop_positions referring to the stops of the same name. This makes them useless for the purpose of relating stops/platforms to the stop_positions though. So it should be user configurable.
Whether stop_positions also get name tags and other details, is another user configurable setting. I like to keep things as simple as possible, so stop_positions in Belgium only get:
public_transport=stop_position bus=yes and/or tram=yes
In other areas this is done differently. So the plugin should adapt.
In Belgium you will only find stops on nodes (public_transport=platform), in other countries I've seen them mapped as ways. In Germany these seem to be L-shaped connecting to the street where the bus travels.
Anyway, the basic premise we seem to be able to agree on is a route relation for each variation, containing all the stops in the correct order, then all the ways in the correct order.
If a stop is served twice in the same variation, it is present in the relation twice. If a way is used twice it also is in the relation twice.
To relate a stop on an isolated node on either side of the road to the way the bus travels along, there are few 'strategies'
- proximity of way of stop_position
- stop_area relation that contains a stop_position and the platform/stop
- these L-shaped platform ways, but you won't find those everywhere
- peek at other route relations
- if all else fails, ask the user