[Talk-GB] NaPTAN Data

Jay Turner jaynicholasturner at gmail.com
Tue Feb 16 13:08:45 UTC 2021


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:
>
>
>    1. 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.
>    2. 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).
>    3. As mentioned already, this time "highway=bus_stop" and
>    "public_transport=platform" must be added to each stop.
>    4. 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 NaPTAN data 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/f0c71025/attachment-0001.htm>


More information about the Talk-GB mailing list