[Talk-GB] NaPTAN Data

[ipswichmapper at tutanota.com]

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/f9f045a2/attachment.htm>