[Talk-GB] Update bus stop names

[jc...@mail.com]

On 18 January 2020 at 1340, Cj Malone wrote:
> Although now I have another issue, which data source should be preferred.

Whichever is the most up-to-date in your area. NaPTAN data has a 
ModificationDateTime field which shows when it was last updated. The SV data 
doesn't have such info so you'd need local knowledge about that. IoW bus stops 
seem to be branded which I think is rather unusual, so does the bus operator 
pay for updating them? That might be a clue to which is more recent.

Neil's example in Bristol shows that the paper timetable board has a newer name 
than both the metal sign and NaPTAN.

Conversely, in my area when many names/local_refs were changed three years ago, 
metal signs were changed first but the bus operators still used the old bus 
stop names until last year, and NaPTAN is a confusing mixture of old and new.

All local authorities are different!

Jez C

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Update bus stop names

[Neil Matthews]

For an example of possible name mismatch, see the edit history for node:
https://www.openstreetmap.org/node/485404488 which is shown at
https://flic.kr/p/2igLCco

For an example of stops being amalgamated see:
https://www.openstreetmap.org/node/435846038 when
https://www.openstreetmap.org/node/485404491/history and
https://www.openstreetmap.org/node/436185070/history were deleted. See
the changeset for discussion:
https://www.openstreetmap.org/changeset/74179599

I am not the only person editting stops locally -- but none of us have
added not:name -- just tried to map what is there.

Cheers,
Neil

On 18/01/2020 18:40, Cj Malone wrote:
> Hey Neil,
>
> I don't know which nodes you are talking about, but of the ones I'm
> looking at (where "name" != name from new NaPTAN data using
> "naptan:AtcoCode"). The vast majority haven't been updated in 10 years,
> since the NaPTAN import, or one edit where "naptan:verified" was
> changed to yes.
>
> I am not doing automatic, or blind edits. It would have been helpful if
> when you changed names from NaPTAN import to surveyed you used
> "not:name", but that doesn't matter. When I make the edits I can look
> at the history of the node, and if a mapper has changed the name semi
> recently I will not change it but rather add a "fixme" describing the
> issue.
>
> Thanks,
> Cj
>
> On Sat, 2020-01-18 at 15:01 +, Neil Matthews wrote:
>> No, please don't update mismatched bus stop names "blindly".
>>
>> I've surveyed a lot locally and have updated them to the newest
>> values
>> from paper timetables -- which have newer names than on metal
>> signage.
>> They also match the names that the local council have used when
>> updating
>> OSM. A lot of names were surveyed that didn't need to be changed -- I
>> don't know how you would ensure that you didn't change them to some
>> incorrect official value. Obviously, you shouldn't be changing names
>> that weren't in the preious Naptan data -- you should at least assume
>> that they are now newer and likely to come from surveyed data.
>>
>> The best approach is either to add official_name (naptan_name?) and
>> leave "name" alone, or provide a mechanism where local mappers can
>> survey mismatches between your dataset and what is currently in OSM.
>> At
>> the very, very least you should move "name" to "old_name".
>>
>> Best regards,
>> Neil
>>
>> P.S. At least locally there are locations where several bus stops
>> have
>> been amalgamated into a single one. Also some are now
>> disused:bus_stop
>> if no services are currently stopping there.
>>
>>
>>
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Update bus stop names

[Cj Malone]

Hey Neil,

I don't know which nodes you are talking about, but of the ones I'm
looking at (where "name" != name from new NaPTAN data using
"naptan:AtcoCode"). The vast majority haven't been updated in 10 years,
since the NaPTAN import, or one edit where "naptan:verified" was
changed to yes.

I am not doing automatic, or blind edits. It would have been helpful if
when you changed names from NaPTAN import to surveyed you used
"not:name", but that doesn't matter. When I make the edits I can look
at the history of the node, and if a mapper has changed the name semi
recently I will not change it but rather add a "fixme" describing the
issue.

Thanks,
Cj

On Sat, 2020-01-18 at 15:01 +, Neil Matthews wrote:
> No, please don't update mismatched bus stop names "blindly".
>
> I've surveyed a lot locally and have updated them to the newest
> values
> from paper timetables -- which have newer names than on metal
> signage.
> They also match the names that the local council have used when
> updating
> OSM. A lot of names were surveyed that didn't need to be changed -- I
> don't know how you would ensure that you didn't change them to some
> incorrect official value. Obviously, you shouldn't be changing names
> that weren't in the preious Naptan data -- you should at least assume
> that they are now newer and likely to come from surveyed data.
>
> The best approach is either to add official_name (naptan_name?) and
> leave "name" alone, or provide a mechanism where local mappers can
> survey mismatches between your dataset and what is currently in OSM.
> At
> the very, very least you should move "name" to "old_name".
>
> Best regards,
> Neil
>
> P.S. At least locally there are locations where several bus stops
> have
> been amalgamated into a single one. Also some are now
> disused:bus_stop
> if no services are currently stopping there.
>
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Update bus stop names

[Neil Matthews]

No, please don't update mismatched bus stop names "blindly".

I've surveyed a lot locally and have updated them to the newest values
from paper timetables -- which have newer names than on metal signage.
They also match the names that the local council have used when updating
OSM. A lot of names were surveyed that didn't need to be changed -- I
don't know how you would ensure that you didn't change them to some
incorrect official value. Obviously, you shouldn't be changing names
that weren't in the preious Naptan data -- you should at least assume
that they are now newer and likely to come from surveyed data.

The best approach is either to add official_name (naptan_name?) and
leave "name" alone, or provide a mechanism where local mappers can
survey mismatches between your dataset and what is currently in OSM. At
the very, very least you should move "name" to "old_name".

Best regards,
Neil

P.S. At least locally there are locations where several bus stops have
been amalgamated into a single one. Also some are now disused:bus_stop
if no services are currently stopping there.



___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Update bus stop names

[Stuart Reynolds]

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 
mailto:cjmal...@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 23062, 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 
mailto:stu...@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 

Re: [Talk-GB] Update bus stop names

[Cj Malone]

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 23062, 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 
 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
>mailto:talk-gb@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, 

Re: [Talk-GB] Update bus stop names

[Tony OSM]

Hi Guys

I imported NaPTAN data for my local area (Chorley) some months ago. Took 
the data for Lancashire and filtered on Town:Chorley. Some of the stops 
were excluded because the data had not been correctly input by reason of 
no entry, misspelt, wrong town entered.


Using the JOSM:Conflate tool enabled me to identify existing stops and 
merge/manipulate the data - hard work with some mistakes which I am now 
correcting by field survey - I know the area well so I tend to be able 
to spot errors. Conflate allows the setting of distance to match nodes - 
I started at 10 meters to get the close matches then 50 metres, several 
iteration through the data.


I would encourage you to add the fields naptan:ATCOCode & 
naptan:NaptanCode as they are useful references when using timetable 
software - all my local bus stops include NaptanCode for text alerts for 
buses.


Bus stop types - most are MKD which I think translates as marked on the 
ground, but CUS are the Custom and practice stops which Stuart refers. 
As they are not physical should they be in OSM ? Answering my own 
question - I think so because it is additional data and very useful for 
map users, but I would now put in the BusStopType field. Similar for HAR 
hail and ride.


Have a look at putting nodes in - helps to complete the map.

I found Latitude and Longitude locations to be accurate within 10 yards 
or so, more accurate than the previously entered bus stops - I surveyed 
/ used Mapillary to confirm.


Be critical about the data and your process - it helps accuracy but 
don't be afraid.


Good mapping

Regards

Tony Shield (TonyS999)

On 18/01/2020 12:16, Stuart Reynolds 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 

Re: [Talk-GB] Update bus stop names

[Stuart Reynolds]

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 
mailto:talk-gb@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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-GB] Update bus stop names

[Cj Malone via Talk-GB]

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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb