OpenStreetMap
As with everything in OSM, quality varies massively by location. Around my area, and lots of the UK, the state of bus stops has been neglected. Around a decade ago there was the NaPTAN import, with a few nit picks I believe it was a good thing. OSM needed bus stops, NaPTAN had bus stops, the answer is obvious, import.
However we have let that data go stale and get out dated. A surprising amount of the bus stops, haven’t been touched in the 10 years+- since the import. They still have naptan:verified=no. They have old names. Take a look at @NaPTAN/history, pick a changeset, pick a node. Was it last edited about 10 years ago by NaPTAN? That’s an issue. Maybe somebody realigned it based on satellite imagery, that’s still an issue.
The NaPTAN import was a static thing. A one time event. But the NaPTAN data isn’t, they record and publish when a bus stop is changed, it’s name changed, it gets deleted, moved. Why can’t we keep on top of this data? I know OSM is very against automatic edits, for one reason or another. So I’ll just flat out ignore that, even though I disagree.
So we should be manually keeping in sync with NaPTAN, one way to do this is to download the NaPTAN data for a region and sort it by newest modified date. Compare it to the OSM data, does it have a new name? Has it location changed? Has it plain been removed due to route changes? Do we need re survey the bus stop? To download NaPTAN see that page.
Please, everyone who reads this, do an overpass query in your local area, the bus stops need your help.
Not verified:
node["highway"~"bus_stop"]["naptan:verified"="no"];
No NaPTAN ref:
nwr["highway"~"bus_stop"][!"naptan:AtcoCode"];
nwr["public_transport"="platform"]["bus"="yes"][!"naptan:AtcoCode"];
For the ones that aren’t verified, verify it. Change it to naptan:verified=yes and probably add public_transport=platform and bus=yes. There are a bunch of other tags that can help, but not required e.g. shelter=yes/no, bench=yes/no, bin=yes/no, tactile_paving=yes/no.
If there isn’t a naptan:AtcoCode tag, you can try and add it, it might be written on the bus stop board. It can be as little as 6 numbers but it seems to more often be 12 numbers, maybe with some letters at the end. If you can’t find the code there is no harm in adding survey:date=YYYY-MM-DD to point out that the node was physically verified.
Discussion
Comment from EdLoach on 24 January 2020 at 09:36
On the flip side, I’ve been maintaining local bus routes, and if a stop hasn’t been verified I’m happy to update it based on the current naptan information safely assuming the old information is out of date and not ground verified. If it has then I’m more likely to add a note to say a resurvey is needed to check current name (with a few exceptions such as stops verified about 10 years ago that were named after say a pub that has now been gone a number of years and replaced by say a supermarket and the naptan name now reflects the store name rather than the ex-pub name).
Comment from CjMalone on 25 January 2020 at 00:07
I didn’t consider that, but I think that’s a good call and I’ll probably start doing the same.
Would you take it a step further, if the NaPTAN dataset flags a bus stop as del, would you delete it from OSM?
Comment from EdLoach on 25 January 2020 at 06:52
Usually if not verified, yes, though I have found some flagged as “del” which were part of an active bus route. In that case I add the naptan:status=del (or whatever it is called naptan field) in as a reminder. In the first instance I tried to point out to the relevant bus company that the stop on their timetable was where a road had been diverted and the old stop location was now on a shared use cycle path nowhere near where a bus could go, but they just told me where the new stop was without seeming to grasp I was telling them their timetable was still listing the old one (by atcocode).
Comment from EdLoach on 25 January 2020 at 07:09
Found it