OpenStreetMap
There’s lots of data stored in OSM about bus stops, but often maps and apps created with OSM data don’t make much use of it (with OsmAnd being the notable exception). For here’s a bus stop as shown by OSM Carto:
You can see that it’s a bus stop, and you’d be able to see the name if you could zoom in a bit more. However, in OSM there’s actually lots more information. For the map styles that I look after (both web-based raster maps and for Garmin devices) I tried to add a bit more detail. Here’s the result:
The bus stop icon has several extra elements that can be varied. The main part is the bus - still present but disused stops get a black “x” instead. Most bus stops have a pole. and that is shown to the right. The “r” indicates that there’s some sort of real-time display at the stop and the “s” that there’s a button that people can press to hear an announcement saying when the next buses are due. A “t” is shown if there’s just a timetable. The stop name itself is composed of several components - the name field itself, and also if set ref and naptan:Indicator, often “opp” or “adj” in the UK.
A feature of bus stops in my local area is that most also have a QR code of the form http://deps.at/?32900012, which redirects to a website for that stop that shows the same information as on real-time displays. The parameter is the naptan:NaptanCode. Unfortunately this doesn’t work for all stops, so I’ve manually added the website locally only where it actually works. The website is shown on the stop when you zoom in.
The full variety of symbols can be seen in the legend here. Zoom in to see larger icons.
Several tags are used to decide whether a bus stop pole is likely to be there or not, and I’ve used "physically_present=yes is used on disused bus stops to indicate that a pole exists but they’re not in use. Some in my local area are signed as not in use, but the majority are not - the only indication is uaully the lack of a timetable.
Newer buses locally do have displayed and spoken announcements of stop names on board, but sometimes the name on the stop, the name displayed on the bus and the name announced on the bus are all different - see for example here and here. I’ve used bus_display_name and bus_speech_output_name where these differ. I made those last two names up; I couldn’t see anything at taginfo and a mailing list post didn’t generate any other suggestions. If either of the other names isn’t contained within the main one, I’ve appended them to the end, like this:
Of course, if someone can suggest a better tag for these names I’m all ears (but not alt_name or some semicolon=separated monstrosity as neither of those would explain which name is which).
Maps for Garmin are similar, except that relevant information is appended to the name directly. Also note that a number of Garmin devices such as older Garmin Nuvi satnavs (and presumably newer Garmin drive ones) support speech output directly.
Discussion
Comment from Raretrack on 19 March 2024 at 09:23
Very useful, thanks. I’ll try and test some QR codes at my local bus stops, and add website tags if they work.
I know of some bus stops where the bus_display_name and bus_speech_output_name differs between the two bus companies that serve them. That adds another layer of complexity!
Comment from MxxCon on 19 March 2024 at 15:10
Wouldn’t it be better for the bus route operator to fix such inconsistencies on their end? That would improve ease of navigation for everyone.
QR code URL in the name is a pretty bad user experience. Font size is small, and to make use of that URL one would have to type it in switching between browser tabs since you can’t select the text from the map. I think such info is better left for details view if they tap on this stop where it can be made into a working hyperlink or at least a selectable text to copy.
Having different icons for stop “modifiers” is clever, but I think those tiny letters are too obtuse to understand without a legend. Even more so if the user doesn’t speak English. “s” for speech/sound doesn’t make the same association in other languages. Also sounds are relevant for the visually impaired people, who probably wouldn’t see the icons anyway. Similarly for “t” and “r”. You are working with very few pixels, but perhaps some iconography instead of letters would be more universal.
Comment from InsertUser on 20 March 2024 at 02:07
Not my diary, but telling operators what to do isn’t OSM’s job? We map things as they are, not as they’re meant to be.
As the linked map only covers the British Isles, is this really an issue?
Comment from MxxCon on 20 March 2024 at 02:15
You don’t exist outside of OSM? You don’t try to make things better in the outside world beyond OSM? Even if you don’t use OSM, don’t you think having 3 different names for the same stop on the same route is confusing?
Do you have to surrender your Garmin device when you cross the border of the British Isles? The linked map IS the OSM map.
Comment from SK53 on 20 March 2024 at 15:24
The linked map IS NOT the OSM map. It is a map largely created by SomeoneElse for both the things which he is interested in and to aid on-the-ground mapping. As his interests (hiking, real ale, …) tend to be shared by other OSM contributors in the UK and Ireland it is also helpful to other mappers in those two countries. The style was forked from the Carto style about 10 years ago, prior to changes in the colouring of highways.
It has many rendering rules which relate to specific local legal peculiarities (mainly PRoWs - Public Rights of Way - which exist only in England and Wales) & personal quirks, such as whether a pub has real ale, might allow someone in with muddy boots & there’s a warm fire. As a local map it also has more zoom than the maps hosted on the OSM webpage, which in turn allows more detail to be shown.
As a general tool for OSMers, SomeoneElse’s map style is mainly useful as an extensive example of how to use LUA for post-processing OSM data, and for numerous features, as in this case, which are not displayed on any of the main styles.
With respect to transport providers names for stops: closing the loop on this kind of system is extremely difficult. and slow-winded. Anyone who has worked in large corporations knows that the only timely approach for this type of data issue is to handle such differences. (In perhaps 50-75 engagements over a 15 year period as a consultant I only once was able to close the loop in fixing duff data.)
Comment from SomeoneElse on 20 March 2024 at 19:01
To address a couple of these questions:
It’d be great, but in some cases the work that needs doing is physical changes to infrastucture (removing or marking bus stop poles no longer in use), and replacing missing ones). None of the organisations involved have a bottomless pit of cash or staff to make these sorts of changes with, so it’s understandable that there are discrepancies between (a) the five(!) different sources of bus stop names that I know of and (b) the three different sources of “is this stop actually used or not”. I was a bit surprised about exactly how wrong some of the data is; it may be worth doing another diary entry about that at some stage.
“tap on the map to query it” is very much a pull requests welcome sort of thing. If someone wants it badly enough to suggest a leaflet plugin to integrate to do it, I’d definitely be interested. Until then, other sites (not least osm.org itself) can do this already. The small font size thing is only a problem if you can’t zoom in; I find that the overzoomed zoom 25 of zoom 24 tiles at the maps.atownsend.org site is plenty big enough to read, and (unlike osm.org) it’s running a version of Leaflet that tries to zoom rather than fetch on a “two fingered zoom” which makes it pretty easy to read on first load.
There is a legend that you can zoom in and out on. It’s actually merged into the data in the middle of Australia.
“letters vs symbols” is an interesting one. Pubs and fast food use symbols for most things, including coloured flashes on the underline for wheelchair access and outside seating/beer gardens. The maps use names into one of four tags (English, Welsh, Scots Gaelic and the default “name” tag), so it might have been nice to stay away from letters for that reason (and also not hardcode a currency symbol), but here I used stylised letters because I couldn’t think of a way of encoding e.g. “there is a realtime display here” in a symbol in so few pixels. If anyone can think of a better way of encoding the information without using letters then I’m all ears!
It’s often worth mentioning that people suffer from many sorts of visual impairment - “not being above to read a display or timetable at a bus stop” includes many more “forgot my glasses” than “completely blind”. Also, that’s why I mentioned Garmin Satnavs at the end - if you have control of what names appear in the map you have control of what’s spoken by the device when it tells you something it is navigating to.
Comment from SomeoneElse on 20 March 2024 at 19:21
… and more:
There are a few (actually, only 5) examples of
departures_board=realtime on phone. I’m not convinced that this is a great tag value but “there is a QR code that you can scan” does seem like useful information to me. I did start adding note tags locally but that’s very incomplete - I soon found out I needed to worry about which stops actually existed and which not first. It’d need integration with one of the mobile editors such as Vespucci or StreetComplete etc. ideally.That’s another good point. I deliberately didn’t use a “:” in
bus_display_nameorbus_speech_output_nameto avoid them looking like different languages but different names used by different bus companies is a different case again.