Thanks to the Swiss OpenStreetMap Association for hosting it, the project is now available here: atlas.osm.ch
The goal is to identify discrepancies between OSM public transport data and ATLAS, the official Swiss public transport dataset.
It is still an early version, and I’d really appreciate your help with two things:
Reviewing the matching
If you find a specific stop where the matching is wrong, and you can think of an algorithmic improvement that could fix it, please let me know.
General app feedback
What seems useful? What is confusing? Do you have any ideas for improvements?
Some of the next improvements I’m currently considering are:
a) Present routes and route problems better
For example, illustrate matched stops when comparing routes on the Routes page.
b) Include more ways
Currently, only ways that have a UIC number are included.
c) Use stop relations
We are not using stop relations yet, but they may be useful.
d) Improve the Operators page
There are several types of operators: OSM stop operators, ATLAS stop operators, GTFS route agencies, and OSM route operators. The Operators page is still at an early stage, so feedback on how to improve it would be helpful.
e) Add time-series graphs
Show the evolution of detected problems and other quality metrics over time.
f) Compute OSM query diffs
Run the pipeline only on changed nodes or relations. These diffs could also be shown in the web app.
Impressive matching work. From a quick look around places I’m familiar with, a common issue are stops that were added recently when all the replacement bus services were standardized. They often don’t even seem have any routes associated, if there is no currently expected activity on that replacement bus service. I guess they’re only in ATLAS when they are planned to be used with reasonable amounts of planning time? Since the actual service routes can be extremely situational I guess we wouldn’t want to have those in OSM, but having the stops does seem to make some sense. The routes usually have “EVn” where n is their route number in their ID and it appears they’re on a separate operator.
Well, the actual routes for the busses will vary, which is what I was trying to refer to here. And many of the stops I checked that I don’t know of currently having a planned replacement bus active didn’t have a route referenced.
Or if anything just temporary evidence, yes. Though some stations now have permanent plans shown in their info panels that show where the stops are, while others will only show a map during the disruption on a display. But bus stops that are unmarked aren’t that uncommon, some night bus stops are also unmarked for example, as they are stops where you can only alight and no regular day time bus serves the stop.
Great effort, still a bit “beauty work” to do. Following is not a concern for me, but how people might (and probably will) contribute:
Well… VBZ has included all the replacement stops from their internal DIVA instance. This includes all tram stops, as well as all bus stops, when they get diverted during road construction works once in over 40 years. While such changes usually get announced at least two weeks in advance, technically they could just put up their orange stop diversion signs over night (happens after water pipe burst). I’d suggest hiding them by default – operating ref numbers (in SLOID included) are 80+ and 90+ im Kanton Zürich.
No, and I suggest: generally don’t. If the are marked – by pole, that’s a requirement and a implicit default for a PT stop – then do add them, and just add an internal note (“nur Nachtbus XOR Ersatzverkehr”). In a perfect world it’s very simple: a PT stop that isn’t part of a PT route relation is not a regular stop. But it isn’t our goal to add each and ever route variant of a PT line, and it isn’t our goal to dump the whole GTFS dataset into OSM. We track the physical stops (“platform”) and the non-physical stop positions (mostly for QA purposes). Technically we don’t even have to do that, because the location data of each kerb is included in the GTFS dataset. Every application that I know of, uses OSM only as base map, while the stops and routes are constructed as own overlay and don’t rely on this part of OSM data. So don’t overthink it and keep it simple.
@d_berger with “different way to add them” I didn’t talk about a PT stop, which has a pole. Those are clear, like you described.
But I was talking about those, potentially overcrowding the map, PT stops which have a predefined location, only used sporadically and don’t have a physical presence (like a pole). Because for the train replacement bus services it would be useful to have the stop locations available in some way. Especially for unexpected interruptions, i’m not sure if there are GTFS published (for determining exact stop location). I agree they are not the same as a normal PT stop, so that’s why I asked, if there is an alternative way to add those.
I guess those stops are a bit different between the operators. For the trains they are quite clearly predefined. Those 90 stops from the VBZ used once in 40 years are clearly not the kind of usage I am talking about.
Not to my knowledge. And not without having them indistinguishable on the map. That’s why I suggested adding at least a note, because some mappers tend to remove objects, when they can’t figure out their purpose …
Another possibility I use on nightbus services with exit_only stops: I don’t add hw=bus_stop. There is no purpose for the PTv1-tag rendered on a general map, because there is nothing OTG. We generally don’t map the absence of objects. For modeling the stop itself pt=stop_position (which is an abstraction) is sufficent. Not sure we need a second abstraction (pt=platform) in such cases, and I consider it very bad practice to add a non-existing, virtual ‘platform’ just to “no”-spam it, because – surprise – there is nothing there …
Thanks, I’ll think about a way to improve this, for example by not counting them as “missing in OSM” problems if there is no GTFS route evidence, or if their GTFS route evidence only points to replacement-service routes, for example EV*.
They could instead be shown in a separate filter/category, so they remain inspectable without encouraging people to add non-physical stops to OSM.