In my local area, all bus stops and also train stations have a scanable ID (QR-code) that links to an online departures board – Examples of where links point at:
Is that common elsewhere? Wouldn’t mapping that make it easy for OSM derived maps to become more useful, when a tap on a highway=bus_stop would open that external link?
Please share ideas!
I think this is good idea. We have tags website/url but perhaps something more specific would be better.
Example from Warsaw
Link to online departure board for tram stop: https://tw.waw.pl/sip/#/przystanek/708305
Link to schedule for the same tram stop: Timetables – Warszawski Transport Publiczny
Related taggings:
https://taginfo.openstreetmap.org/keys/opening_hours%3Aurl
https://taginfo.openstreetmap.org/keys/url%3Atimetable#overview
https://taginfo.openstreetmap.org/keys/service_times%3Aurl
https://taginfo.openstreetmap.org/keys/qr_code%3Aurl
https://taginfo.openstreetmap.org/keys/website%3Adepartures
https://taginfo.openstreetmap.org/keys/service_times%3Awebsite
Extra info: As user of an app based on OSM data, I’d appreciate ease of implementation, so not to burden implementors. So the stop node has to have the full URL, no fancy redirects to relations that avoid redundancy in e.g. the hostname of the service. Just OTG truth!
From what I observe, the URLs are quite stable here, they survive changes in schedule.
I have no preferences in naming of the key, might as well be website:departures or departures_board:url – you name it – This topic also meant to help find a name to standardise on.
website:*= is not a good format. departures_board= is not an attribute for the departures, only the board itself.
As this is related to the opening_hours= of the route= , service_times= and service_times:url= should be used. Matches opening_hours:url= .
service_times:url sounds a bit more like a link to a timetable for the bus stop (i.e. a list of all scheduled departure times). I think most examples here are more like lists of departures in the next relatively short period, typically in real time (so showing delays relative to the schedule). I imagine some bus stops have both (definitely not all, as some operators show schedules on a per route but not per stop basis).
Do we need two tags for these two concepts?
In other words, would we have to choose one of the two links given by @starsep for the same bus stop, or would there potentially be a separate tag for each?
I thought about interval:url= . But some timetables don’t have a “time”, only the expected headway. Some transit stops may have both headways and the scheduled time. So there may even be 3 possibilities.
depatures*url= may still have the same ambiguity, as departures_board= has =timetable , the poorly translated =delay , and =realtime . There were 2 failed attempts Proposal:Deprecate departures board=realtime - OpenStreetMap Wiki and Proposal:Refine departures board tagging - OpenStreetMap Wiki for a proposal to improve them already.
Are there any examples where website can’t be used because that is used for something else? If not, that is surely what data consumers would expect…
Edit: Just for info, another example. On that list “X mins” is allegedly real-time tracking; a fixed time format is “not real time tracking but when it is supposed to leave”.
Brussels-Midi has a general information page about the station in website (Node: Bruxelles-Midi - Brussel-Zuid (17401552) | OpenStreetMap). (Unfortunately https://www.belgiantrain.be/nl/travel-info/current/search-by-station doesn’t seem to have direct links per station.)
What about next_departures:url=* and timetable:url=*
I’d say, this topic already gathered some examples 
The title says departures_url, I posted links to online departure boards in the most strict sense of the word - no timetables, no general accounts about the PT stop, but those websites about the kitchen sink showed up here nevertheless.
That said: website:departures sounds reasonable to me. I’d prefer that over departures_url. Respectively website:timetable in case the scan-code on the stop links to such. I do not expect that to be really common, timetables refer to routes, a single stop can service ten routes. The links by @Nielkrokodil with website:departures also are right on the matter.
As user of an OSM based app, it should be easy on the developers, so I get it sooner rather than later. As a mapper, I’d say, this might make a good StreetComplete Quest rather than scraping a database.
In my local area, all bus stops and also train stations have a scanable ID (QR-code) that links to an online departures board – Examples of where links point at:
Is that common elsewhere?
in Rome we have something similar, a 5-digit code that identifies the stop and can be used to query an online api to get real time arrival/departure predictions. We tag this code as “ref” but we don’t add urls for api or webinterfaces. I am not sure how stable these urls are (some apps are not available any more), but the codes are stable.
I once installed the “Öffi” android app. Looks to me, like it queries some API and shows results in-app. It works from landline but does not work on mobile here - I guess the API endpoint blocks mobile IP-ranges. That is their right.
I’d think, as long as OSM data only contains links to services announced to the public it should be safe to map them?
Hi. I was planning to do an update to the import of public transport data in Montevideo, Uruguay, and noticed that bus stops have a QR code with a URL of a which takes you to the info of the next buses arriving on it.
Cómo ir - Intendencia de Montevideo (the parameter is the ref of the bus stop)
is there an agreement on how to tag it?
I think that this thread is as in-depth a discussion as there has been anywhere…
As I mentioned above, I’ve just used “website” (for example here, leading to here). IMHO the other options suggested above:
Conceivably there might be a bus stop that has its own website that is somehow different to the URL that you go to to get bus times, but I can’t think of a real world example.