[Talk-GB] NaPTAN Data

Tue Feb 16 13:46:10 UTC 2021

Around late last year (November, December), I invested quite a bit of time into mapping bus routes, and I gained a lot of knowledge from that. I'd like to explain that here:

I want to say that I think importing NaPTAN stops will be relatively difficult.

Firstly, you have to consider road offset. Often the positions of bus stops are slightly offset from the road. For example, the bus stop on the left side might be really close and the bus stop on the right side is significantly. If you browse the map on https://bustimes.org you will see this. 

Then, there is the issue with ground verification. When I was mapping routes in rural areas, I noticed something quite odd. Many of the bus stops listed on a bustimes route "don't exist" in real life. What I mean by this is there is no indication whatsoever that the bus stop exists: no pole showing a bus stop, no shelter, no sidewalk, no bench, nothing! Some bus stops had some of those features (like a sidewalk or a bench appearing near the bus stop) but many times there was literally no indication of a bus stop existing. [1]

Should this be considered as a bus stop? Well, if you can stand on the grass by the side of the road and wave your hand when the bus comes nearby, if the bus driver lets you in then yes, that should be considered a bus stop, even if there is no on-the-ground indication. However, are these bus stops used by anyone? Do drivers know they exist? Even if they are used, how on earth are you meant to verify them in real life???

Information like this is only available if you are a local to that area, probably. It's probably not information you are going to be able to find in the middle of lockdown either. I haven't ridden any of these rural routes, so I don't know if you can get off at these "ghost bus stops". 

While bus stops in the middle of nowhere have no indication, bus stops in small villages usually have some indication. For example, there might be a shelter. However, usually the shelter is only on one side of the road (the side from which most people are likely to "catch" the bus), whereas the other side of the road usually has no shelter or indication of a bus stop, because that's the side people get off most of the time. These kinds of bus stops should be considered to exist, because even though there is no indication, there is a shelter on the other side and due to the fact that it is a village the bus driver will probably stop if you press the stop button.

Again, the problem with the two types of stop above is that verification questions, like those on streetcomplete, would lead to those kind of stops being deleted.

The other problem is the opposite. Sometimes bus routes are slashed, and bus stops are no longer used. However, indicators such as poles and timetables might still be shown. This might lead Streetcomplete users to add unused bus stops, and suggest non-existant routes. Ideally, such bus stops should be tagged as "disused:highway=bus_stop" and "disused:public_transport:platform".

On a side note, there really needs to be a push to get mapplications (such as OSMand and Qwant maps for example) to recognise disused features. Currently in Google Maps, if you search for a disused feature such as a closed shop or an unused bus stop, Google Maps will show it to you, however it will say that the feature is "permanently closed".

As for duplicate bus stops, if I were to add a bus stop manually it would definately be a few metres apart from the "NaPTAN position" of the bus stop. Therefore, every single stop would have to be checked to see if there are duplicates.

> > The "naptan:Indicator" tag is effectively the same as the "local_ref" tag. Therefore, the "NaPTAN indictor" should be imported into both of those tags.
>
> Even for values like o/s, adj and opp? :) Happy to start adding those.
>
Yes. local_ref is rendered by some public_transport slippy maps. It is useful to discern the "adj" side against the "opp" side. And yes, "o/s" or "o/s 522" are also examples of local_ref.

For some reason the wiki suggests using "ref" instead, which is more confusing and isn't recognised as the code for individual stops by many public transport renderers, so I would probably stick to local_ref.

If there is a strong desire to move to "ref", you could use "ref:local=*" instead.

Thanks,
IpswichMapper

[1]: Example: A stop called "Limeburners" outside of a shop. No indication that this stop exists, I would assume you would stand outside the car park or on the grass to catch this bus?
Bustimes Link:
https://bustimes.org/stops/390040317

Google StreetView Link:
https://www.google.com/maps/@52.1032062,1.0260873,3a,75y,256.04h,68.47t/data=!3m6!1e1!3m4!1skeRDfwjYydE2WyHUN67osQ!2e0!7i13312!8i6656
-- 

16 Feb 2021, 13:08 by jaynicholasturner at gmail.com:

> Rob 
> I'm replying to Ed Loach and IpswichMapper specifically here.
> Ed Loach:
>
> > I am one of those that removes the tag after a survey, but if I encounter a bus stop with a tag on and can align it better based on the aerial imagery we didn't have in 2009 I leave the tag value set to "no". Verified really requires a visit for things like determining whether there is a timetable case/raised kerb/shelter/bench/waste_basket and all those other attributes that are gathered when verifying the naptan location/stop name/bus stop type/status.
>
>
> I've seen some confusion as to the actual purpose of `naptan:verified` - I thought I was simply `"verify this bus stop exists" but some people have said that I'd have to verify all the naptan data match reality? As long as name/ref/local_ref match and a stop exists, I'm gonna set it to yes :)
>
> > I would suggest naptan:RevisionNumber would be easier to use to be able to simply compare the values in OSM to Naptan to spot any that have changed easier.
>
>
> Ooh, good suggestion. I'll start adding that on any that I touch. I have been working on > Kent> , doing it one by one by each LocalityName. I've been using all resources at my disposal, using the Land Registry layer to align imagery (provided by Rob Nickerson), looking for markings on the road or bus shelters near the new NaPTAN GPS coordinates. 
> I would highly encourage others to work on their areas and update the data. The downloads can be found here: > https://naptan.app.dft.gov.uk/datarequest/help
> IpwichMapper:
>
> > The "naptan:Indicator" tag is effectively the same as the "local_ref" tag. Therefore, the "NaPTAN indictor" should be imported into both of those tags. 
> Even for values like o/s, adj and opp? :) Happy to start adding those.
>
> > The last worry I have is about bus stops that were added after the import. What about them? Importing data again would lead to duplicates. 
>
> Not a perfect solution but MapRoulette challenges to clean up duplicates could be created.
>
> > The "Traveline National Dataset" is released under the Open Government License. This means that > bus routes>  can also be imported into OSM (by linked all the stops listed in a timetable together in a route relation). Yes, there won't be any ways, this will have to be added manually. However, even with just bus stops in the relation, apps like OSMand can display bus routes & create public transport navigation using just relations with bus stop nodes. In fact, Google also probably only has access to bus stop nodes, however, it creates a driving route between two bus stops automatically so that users can see the physical route a bus takes (in fact something like this could potentially be done with a JOSM routing plugin, making it much easier to add ways to the relation). 
>
> This is huge! How do we get started? (I want to finish updating NaPTAN data first, but then I wanna get bus routes for my local area added asap.)
>
> That's actually kind of why I started updating NaPTAN data in Kent. I went to upgrade my bus routes near me and spotted that some bus stops were wrong/outdated/missing.
>
> Anyhoo, I think that's all I have to add right now
> J
>
> On Tue, 16 Feb 2021 at 12:47, <> ipswichmapper at tutanota.com> > wrote:
>
>> This would be great. Bus stop and public transport data is tedious to map, and it is also woefully out of date. 
>>
>> There isn't much need to know bus routes anymore to map them, you can easily do it using a website like >> https://bustimes.org>>  which simply pulls data from NaPTAN.
>>
>> If we were to do this import again, it should be done RIGHT:
>>
>> The "naptan:Indicator" tag is effectively the same as the "local_ref" tag. Therefore, the "NaPTAN indictor" should be imported into both of those tags.
>> The "Traveline National Dataset" is released under the Open Government License. This means that >> bus routes>>  can also be imported into OSM (by linked all the stops listed in a timetable together in a route relation). Yes, there won't be any ways, this will have to be added manually. However, even with just bus stops in the relation, apps like OSMand can display bus routes & create public transport navigation using just relations with bus stop nodes. In fact, Google also probably only has access to bus stop nodes, however, it creates a driving route between two bus stops automatically so that users can see the physical route a bus takes (in fact something like this could potentially be done with a JOSM routing plugin, making it much easier to add ways to the relation).
>> As mentioned already, this time "highway=bus_stop" and "public_transport=platform" must be added to each stop.
>> The last worry I have is about bus stops that were added after the import. What about them? Importing data again would lead to duplicates.
>> Thanks,
>> IpswichMapper
>> --
>>
>> 15 Feb 2021, 20:34 by >> jaynicholasturner at gmail.com>> :
>>
>>> I have a few questions regarding the 2009 NAPTAN import. 
>>>
>>> On the >>> wiki  <https://wiki.openstreetmap.org/wiki/NaPTAN/Import>>>> it states: >>> "The Department required that the official identifier for each feature ("atcocode" in the case of a bus stop) is included in the imported data to allow the movement of these features to be tracked over time and for updates to potentially be added in the future. We do have this as a tag on imported bus stops."
>>> Sadly, much of the UK hasn't been touched since the NaPTANdata was imported. (>>> 82202 <https://overpass-turbo.eu/s/13Gq>>>>  / >>> 230474 <https://taginfo.openstreetmap.org/keys/naptan:AtcoCode?filter=nodes>>>> ) 35%
>>> I don't really know how to analyse the data of the other 65% but I'll place a bet it's not in a great state. Additionally, 95% of all `naptan:verified` tags are `no`.
>>> I want to know if it's possible to reimport/mass update NaPTAN data from the latest set of information>>> . Additionally, I propose a few extra tags;
>>>  - `source:date=*` with the `ModificationDateTime` field within the NaPTAN datasets so we have a good idea of when the data was last touched.
>>>  - `public_transport=*` because... well yeah. We have that now. We didn't in 2009.
>>>  - `unsigned=yes` for bus stops with BusStopType=CUS because it's defined as >>> "Unmarked stop (or only marked on the road). Point footprint.". >>> Previously, these stops weren't tagged with highway=bus_stop and I think we should add those en-mass too. Leaving those tags off has led to confusion with mappers unfamiliar with NaPTAN and caused the nodes to be blindly deleted or merged into other objects.
>>>
>>> A lot has changed since 2009, we now have tools to help us find and spot data issues on the ground such as StreetComplete>>> . There's a discussion on GitHub about doing something with these tags to help verify it on the ground. That can be found here: >>> https://github.com/streetcomplete/StreetComplete/issues/2566
>>>
>>> TL;DR: I think we need to mass update NaPTAN data regularly and use StreetComplete or MapRoulette to verify the import and reduce the count of `naptan:verified=no`.
>>> FYI, I think the correct tagging for verified is `naptan:verified=yes` - I know some people delete the tag.
>>> Thank you for reading my incoherent ramble,
>>> JayTurnr
>>>
>>>
>>>
>>>
>>
>>

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