ATLAS-OSM app feedback and ideas

[Guilemmm]

Hello,

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:

1. 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.

2. 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.

Any other feedback or ideas are very welcome.

[freaktechnik (Martin Giger)]

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.

[Piagno]

@freaktechnik

I guess they’re only in ATLAS when they are planned to be used with reasonable amounts of planning time?

They should always be there. Because they are predefined and used for unplanned train replacement busses as well.

@freaktechnik

but having the stops does seem to make some sense

Is there a different way to add them, than normal bus stops? Because they often have zero physical evidence in the real world.

The last time I searched, I couldn’t find a real way, without bloating the map with unused bus stops.

[freaktechnik (Martin Giger)]

@Piagno

They should always be there. Because they are predefined and used for unplanned train replacement busses as well.

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.

@Piagno

Because they often have zero physical evidence in the real world.

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.

[Piagno]

Sure, but I think it isn’t right to add them all in the same way as normal bus stops.

[Piagno]

@freaktechnik

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.

I wasn’t taking about the route, but about the stop. Sorry for the misunderstanding.

[d_berger]

Great effort, still a bit “beauty work” to do. Following is not a concern for me, but how people might (and probably will) contribute:

@freaktechnik

replacement bus service. I guess they’re only in ATLAS when they are planned to be used with reasonable amounts of planning time?

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.

@Piagno

Is there a different way to add them, than normal bus stops?

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.

[Piagno]

@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.

[d_berger]

@Piagno

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.

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 …

[Piagno]

thanks, good idea as well

[Guilemmm]

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.

[OSMfan1]

I coincidentally discovered a problem with the sync:

For “Uitikon Waldegg, Bahnhof”, it displays a second stop, with a distance of 289.5 m - that supposedly carries the same name in atlas:

However, looking it up in atlas, this is actually the stop “Waldegg, Lindenweg”. An OSM stop seems to be lacking, most probably due to the fact that it is a “Bedarfshaltestelle” (not constantly in use according to an official description), possibly there is nothing on the ground to see that there can be a stop.

[Guilemmm]

Hello,

Thanks for reporting this. These observations are very useful for auditing the matching.

The record with the 289.5 m match is “ch:1:sloid:75014::80” ( atlas ). Atlas officially lists it under “Uitikon Waldegg, Bahnhof”, UIC 8575014.

A good trick, is using “view on Atlas” in the popup to inspect the Atlas records.

The one you linked: “Waldegg, Lindenweg” ( atlas ) is a separate Atlas record, UIC 8511416, located nearby. Its boarding platform was valid only from 19 May to 5 October 2025,

so it does not appear in the ATLAS-OSM app’s map. It is filtered before matching: 1.1 Atlas Stops | OSM & ATLAS Documentation

The 289.5 m match happens because there are two current Atlas platforms and only one eligible OSM node with UIC 8575014. Our exact matching rule links both platforms to that node. Should change the name as this is not really an “exact” matching. Probably “UIC match” would be a better name.

(Atlas additionally retains a third historical platform for UIC 8575014, but it expired on 10 July 2024 so not showed on the ATLAS-OSM app.)

In conclusion, it is true that this doesn’t seem like physical stop, but I haven’t found anything in the Atlas data that points to it. So there’s not much we can do.
Please let me know if I’ve overlooked something.

[OSMfan1]

Oh, I totally forgot to look at the validity of the boarding area (Haltekante) of “Uitikon, Lindenweg” that I mentioned! As you point out, its validity timespan lies in the past. However, the stop itself is still valid - I’m not sure if this is intentional.

Also, you’re of course right that there actually is a boarding area very close to the one of “Uitikon, Lindenweg”, but belonging to “Uitikon Waldegg, Bahnhof” - IMHO that doesn’t make sense.

I asked atlas about the two points - let’s see (they probably need to check with the responsible operators).

[9_tab]

Is there a way to include Flixbus? We recently started adding a suitable description, but the routes need work.