Hi all, I have started to add naptan data to osm.org map nodes but without even checking what the benefit would be first. I have added some of Bromley, all of Widmore and a few in Plaistow for starters. I have cross checked data from the naptan database, bustimes.org, tfl live departures website and existing osm data.
Would this actually be something worth continuing or am i just wasting hours of my time?
I have come across a few errors which i have resolved by cross checking everything.
Here’s an example of one of my updated nodes. It was a “bertha james day centre” stop which has changed its name to “wendover road” as the day centre no longer exists. The ibus announcements and naptan database have both already been updated but the tfl journey planner still shows it as bertha james day centre? Does this mean that data is used from multiple sources?
There is another Postcode database (the “PAF”) which has some very strange thing in it, but few of the are transport nodes. This is “owned” by the Royal Mail and is treated - fairly or otherwise - as the primary source for many business purposes.
The work you are doing is interesting, since we have recently been doing some work around OpenStreetMap (we’ll probably be sharing details soon).
NaPTAN is designed to be the canonical dataset of bus stops (and other kinds of station) across Great Britain, so I can certainly see some use in referencing the AtcoCode for each bus stop. However, I do wonder about the utility of including other data from NaPTAN. Data in NaPTAN can potentially change at any time, so OpenStreetMap could easily become outdated. If you took the AtcoCode from OSM, you could then cross-reference with NaPTAN to get the most up-to-date information.
What materialised view do you use? Sorry if this is a silly question. Before now i have only ever made minor edits to osm but i’ve just discovered on how much ive been missing out on by not using JOSM.
Hi James, Oh, so its a genuine error i’ve discovered then. Glad I pointed it out so that it can be resolved. There are a few more stops on the tfl journey planner that are either old and no longer exist as physical stops or are named slightly differently.
I will have a look and send you the details if i may.
Hi Leon. OK, so for now i will probably stick to just adding the NaPTAN details such as naptan:NaptanCode or SMS code/Stop Number as tfl call it and “naptan:AtcoCode” is correct by referencing against the NaPTAN database.
I’ll also please osm by upgrading the tags to bus=yes which looks like it needs doing for every bus stop in the world…I’ll just be concentrating on Bromley for the minute, lol
Sorry guys i should have replied to you all in the same message. I’ve read the telling off/tip window now.
That sounds like a very pointless exercise to me, unless it’s on a highway tagged bus=no (which would be a lunatic place to site a bus stop). An absence of tags to the contrary already implies that buses can use the highway containing the bus stop, and therefore the part of the highway where the bus stops too.
You might then be tempted instead to add motor_vehicle=no to lanes which contain bus stops, but that would also be incorrect. In almost all cases, except in bus lanes, vehicles are allowed to drive over bus stops markings, provided they do not park there. So it is only the bus lane, not individual bus stops, which would require tagging motor_vehicle=no (and in most cases, that too is implied by other tagging and doesn’t need to be explicitly stated.
Also, remember that the bus_stop node (in London at least) is typically mapped alongside the highway, on the pavement (sidewalk in OSM terms). Bus=yes would not be appropriate there.
I know but osm reports it as a “warning” for every bus stop. I dont think the tag has anything to do with whether the bus can use the highway. Its just to inform that its a stop for buses even though its already called a bus stop. I’ve found out how to update nodes in mass so i’m not bothered. All the areas i’m interested in will be done.
The correct fix for that is to find out why it is warning about something which it probably should not be warning about. It shouldn’t be fixed by bodging the data in a way that’s unnecessary and not intended.
OSM also very strongly discourages doing bulk edits in the manner you suggest, and in particular bodging the data to “correct” an error in an OSM-related tool is considered improper.
So, what’s the particular circumstance in which you get that warning? If we can better understand why the warning is occurring (and it’s not a warning I’ve ever seen when editing OSM) editors can take it up with the right person and try to get it fixed properly.
It is shown as a warning when editing in iD browser edition. I initially thought nothing of it and was just updating tags as “suggested” by the editor but you are right, it does need questioning as to why it does it. I will take some screenshots of it and flag it with osm as to why its doing it.
Right, so every bus stop in Bromley from the naptan database is now updated. Bickley is my next target. Ive found a much easier way of updatinf the data without flicking between multiple tabs.
What i’ve found so far:
Most stops had the incorrect value of “naptan:Bearing N” which i know has been an issue and probably still is for most of London.
Most of the naptan:Indicator data was either completely wrong or just showed a letter instead of the correct naptan format of either “Stop Letter” or “->Letter”. I know bus times.org use this data on their site so it is nice to have this corrected even if its just for them.
There are some bus stop positions that are incorrect, some of which are quite far out. I plan to send a list of actual bus stop positions verified in person over the next few weeks.
Most, if not all old “inactive” stops are still shown on the tfl journey planner and in some places the map actually gets quite messy. For example, the area around stop 4900004411SE
Some of the “naptan:CommonName” data was not correct or showed old names. I know this can quite easily become out of date again as with all the data but its better than being years out of date.
Yes, and its the direction from which the buses approach the stop not the direction of travel for “naptan:Bearing”.
Apologies my message above states that bustimes.org use the naptan indicator field when in fact they use “local_ref” but the same applied. Lots of them were wrong.
Have a look at the stop positions for stops A and B in Bromley South . I could send correct ish positions from bing but i will do it once and do it properly and get the actual latitude and longitude. Even if tfl are not overly concerned, it’ll make me happy and im sure people using the tfl app will be happier.
Most of the things you mention in that post are quite different things from adding the bus-yes tag, which is what I was specifically referring to when I suggested it should not be done.
I don’t have time at the moment to study the more detailed problems you mention in this later post, but certainly I can see at least some of them to be more plausible. I have myself “moved” several bus stops on OSM (my editor name is harg) where others have flagged an error, in some cases confirming it with TFL open data but in many cases had to visit the stop because opendata was wrong too.
Specifically though, it’s tagging a bus stop as bus=yes which I object to being added, because apart from being stupidly nonsensical, any such tag should be applied to the highway that the stop is alongside, not to the stop itself.
@harry My “What i’ve found so far:” post was not referring to bus=yes tags at all. That was the previous post.
Just so that its clear incase it has come across in the wrong way.
1: I 100% agree with your opinion on the bus=yes issue. OSM shouldn’t be warning about it when editing in iD. I will not be adding the tag to any future edits (and will revert any added back) as its use is not appropriate.
2: I have not asked you to study any problems i have found. It was a general post on the forum continuing on from the original topic. Please feel free to look into them if you wish, but do bear in mind that i have not asked you to do anything.
OK, So here’s where i’ve got to. Data added, amended & verified for the following naptan areas:
Bromley - N0060488
Bromley Common - E0034076
Bromley Park - N0075219
Bickley - E0034072
Hayes - E0034108
Southborough - E0034147
Grove Park - E0034663 (This area would be so much easier to work with if it were split into smaller sections. ie Grove Park & Burnt Ash)
Widmore - E0034161
Plaistow - E0034136
Downham - E0034661
I started making a list of issues, which as it grew turned into a .csv spreadsheet of its own. 105 items so far. About 75 of them just need their street adding to the naptan database. The others are all name changes and bus stop position updates.
My aim is to work through the whole London Borough of Bromley. Just bus stops first. Then i will go back over the whole lot, checking the routes which will probably then take me slightly out of the borough. For example routes like 208 which start/end in Lewisham so I will probably do all the stops along all the routes that pass through Bromley.
Are there any areas in Bromley that are particularly bad for missing or incorrect data or stop positions or shall i just keep ploughing on through it?
There is a London wide issue where the tfl maps are showing all stops, even inactive/deleted ones so its very messy looking in built up areas. I know this has been mentioned by others and i am assuming its already being looked into. For example:
Is the supplied info of any use to tfl in making the appropriate corrections? I don’t mind doing it if it will help keep the systems correct and accurate, but it is time consuming and I would hate to waste my time if it could be better spent doing something else.
If there is anything specifically that i could do differently to help please let me know, i am happy to help.