[Talk-GB] Update bus stop names

Sat Jan 18 13:59:23 UTC 2020

If you take a look at the map for the area, you’ll see that Redwood Close is a close to the east, on the bend in Mountbatten Drive. The bus stop, as can be seen should you happen to look at a site where there is some street imagery (can’t imagine which one) is actually where NaPTAN has it - directly opposite Silver Birch Drive. From a data perspective, I am quite happy that Silver Birch Drive is correct, and that Redwood Close isn’t as good as it is further away (and difficult to qualify with one of the standard qualifiers). What I can’t tell from the imagery however is what is written on the bus stop flag, and you would need to survey it. In an ideal world, NaPTAN fields should reflect what is on the flag - and it looks like a newish flag, so it should be correct.

The Bus Open Data (BOD) timetable provisions of the Bus Services Act 2017 came into effect from January, although there is a year-long “implementation” period. At present, that is only requiring timetable data from operators. However, having accessible information on board buses (signboards and audible announcements) is another aspect of BOD and the spoken / displayed official name is a key part of that. Debates are going on in the industry at present as to the recommended approach for capturing this data in NaPTAN. My recommendations all along have been if the name that is spoken isn’t right, then NaPTAN needs to be corrected. On the IOW, there is only one operator so it is less of a problem than where there is a multi-operator environment, but we need to make data sets and names align which was the whole point of standardisation from way back in 2003/4 (wish) when this was first introduced.

Regards,
Stuart Reynolds
for traveline south east and anglia

On 18 Jan 2020, at 13:40, Cj Malone <CjMalone at mail.com<mailto:CjMalone at mail.com>> wrote:

Thanks, I didn't really understand the NaPTAN site, but your link to download the data really helped.

Although now I have another issue, which data source should be preferred. Take https://www.openstreetmap.org/node/550691387 for example, no name in OSM. It's napcode appears to be 230000062, Southern Vectis has that as "Redwood Close" whereas the nap data calls it "Silverbirch Drive".

I'm going to do a survey now, and hopefully it will be clear which dataset should be preferred. ie does SV have outdated nap data, or do they pull the official nap data, make edits, but not publish that back.

Or maybe this issue could arise that the name on the bus speaker/other digital reference could be different to the name on the sign on the road. Then, what one would be name vs alt_name, but hopefully that isn't the case.

I currently only intend to add name and nap reference codes to OSM, in my opinion the other data like naptan:CommonName should stay in the nap dataset, and not be copied to OSM. OSM mappers collecting, or even just storing that data will just make more conflicts in the datasets.

Cj

On 18 January 2020 12:16:35 GMT, Stuart Reynolds <stuart at travelinesoutheast.org.uk<mailto:stuart at travelinesoutheast.org.uk>> wrote:
Hi Cj,

What you have got there is Southern Vectis’s link to a subset of the current NaPTAN data. Please note, though, that Southern Vectis are not responsible for this data - that is maintained by Isle of Wight Council.

NaPTAN data is always available by local authority, or for the entire country, from the official source. You don’t need to have a login, and instructions can be found at http://naptan.app.dft.gov.uk/DataRequest/help on how to download individual areas. Essentially, you will need the Atcoprefix to form the URL and you can get this most easily by following the “last submissions” link contained within that page.

But all this comes with a health warning!

NaPTAN data from the official source will generally be more up to date than what has been imported into OSM some years ago. But I know, from when I proposed a mechanical edits few years ago, that many mappers have surveyed their local stops and would be unhappy with it being updated without a further survey by what they regard as an inferior source, particularly if is not well maintained.

Be aware of “Custom and practice” stops in NaPTAN which are unmarked. Buses stop there, but there isn’t something that you can see on the ground that you can map, necessarily. Hail and Ride stops are even worse, because they are virtual stops intended to give something that a scheduling system can hang a time on rather than an accurate representation of where a bus stops. You can identify all of these by BusStopType in the data.

Common errors in the official NaPTAN data set may be missing stops, or the inclusion of stops that are no longer in use. Some areas remove stops when they are no longer served, even though the infrastructure is still in place on the ground (wrong, in my opinion, but there you go). You may also find stops that are not precisely where you expect them to be, and they may also not have the name that is on the stop flag on the ground.

That last one is a point worth dwelling on. NaPTAN is intended to be granular in its data. That means that the street that a stop is on should go into the “streetname” field, and a short name should go into the “commonname” field. Our advice to database administrators is that where there isn’t a prominent landmark (bus station, pub, etc) then this is most suited to a nearby side road. That way stops along a long road can have different names, which is essential in a journey planner or timetable. On the ground, though, many authorities will put composite names on the flags, and often the other way round if they consider the main road to be more important. And they then differ on occasion from what the operator wants to call the stop (although operators tend to focus on just the timetabled points). Oh, and some areas misuse the fields. In Sheffield (for good historic reasons, so I don’t want to pick on them unduly) you will find that the commonname is simply the stop letter e.g. CS1 which should properly be in the Indicator field, and the common name (which should be “Century Square”) is only found by looking at the stop area name.

All this just goes to highlight that you will need to reflect carefully on what the fields that you are updating in OSM should be before making the changes - although I agree that in many places the data in OSM is way out of date and desperately needs updating.

Regards,
Stuart Reynolds
for traveline south east and anglia

On 18 Jan 2020, at 11:18, Cj Malone via Talk-GB <talk-gb at openstreetmap.org<mailto:talk-gb at openstreetmap.org>> wrote:

Hello,

I've recently found an open data set with more accurate bus stop names
than OSM. Based on my limited survey of differences in OSM data and
this data, theirs has been more accurate. Not really surprising, since
it's there network, and most of the OSM data hasn't been updated since
the naptan import nearly a decade ago.

I intent to start updating OSM based on this data. The legal mailing
list has OK'ed this as it's OGLv3.

I won't be importing any nodes, but I do intend for it to be "machine
assisted". I will create a report similar to
https://gregrs.dev.openstreetmap.org/fhrs/ where I will then go through
on a node by node basis and decide if the node should be updated. Any
tag I edit I will add source:name=Southern Vectis, and leave the
naptan:CommonName untouched.

While I do this I could also upgrade from highway=bus_stop to
public_transport=platform, bus=yes. Keeping the legacy tags as the wiki
recommends.

I will be using this data set https://www.islandbuses.info/open-data
the same data set is available for more regions, but at the moment I don't intent to use them, a local mapper would be better suited. https://www.discoverpassenger.com/2019/06/25/open-data-portals-go-
ahead-group/

Any comments?

Thanks
Cj

_______________________________________________
Talk-GB mailing list
Talk-GB at openstreetmap.org<mailto:Talk-GB at openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-gb

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-gb/attachments/20200118/4f1f3ce4/attachment-0001.htm>