[Talk-GB] NaPTAN Data

Tue Feb 16 13:53:48 UTC 2021

Opps, I've been deleting bus stop nodes if NaPTAN says del. Should I go
back and restore them, adding the lifecycle prefix?

On Tue, 16 Feb 2021 at 13:46, <ipswichmapper at tutanota.com> wrote:

> 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:
>
>
>    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/d328653d/attachment-0001.htm>