Re: [Talk-GB] Importing NaPTAN Data

[Stuart Reynolds]

Hi Spike,

There are two aspects to your question. The first is around mechanical edits 
(i.e. importing NaPTAN), and I’ll defer to the group for that because while I 
would like to use NaPTAN (matained, mostly) to update OSM (not maintained, 
mostly) across the UK, there is resistance to that - and it is because of that 
“mostly” issue, because in some areas bus stops have been more accurately 
surveyed.

However, one of my many hats (as a consultant) is as the DfT’s “Public 
Transport Data Standards” expert (Transport is a devolved power, but the 
Scottish Parliament usually keeps Scotland broadly aligned with England). If 
you want to know specific things about NaPTAN fields, then I can tell you what 
they are for and why we need them - either email me direct, or reply here if 
you think that it would be more widely interesting. That is particularly true 
of stop points which are “Custom & Practice” or “Hail & Ride” which are not 
marked on the ground at all (so are perhaps irrelevant from a mapping 
perspective), but are nevertheless valid stopping points (and very important 
from a PT perspective)

As a general note to both you and the wider community, the (English) Bus 
Services Act 2017 provides powers to compel Local Authorities to maintain 
NaPTAN data, and there are steps being discussed to assist in bulk 
“improvements” to the stop data ahead of the timetable provision which is 
intended to commence Jan 2020, mandatory by Jan 2021 (these dates all in the 
public domain, by the way). There is a similar Bill going through Holyrood at 
present, but I don’t know precisely what powers it will contain or what dates 
it will mandate.

Regards,
Stuart Reynolds
for traveline south east and anglia

On 1 Jul 2019, at 16:02, Silent Spike 
mailto:silentspike...@gmail.com>> wrote:

Hey folks,

I'm interested in importing NaPTAN bus stop data 
(https://wiki.openstreetmap.org/wiki/NaPTAN/Import) specifically for my area of 
the UK (Aberdeen).

As far as I can tell, some progress was made previously on importing NaPTAN 
data for specific areas of the UK. However, the process for requesting an 
import on the wiki seems to have broken down somewhere along the line and I 
believe the python script mentioned on the wiki is outdated.

I went ahead and wrote a 5 minute python 3 script to convert the NaPTAN csv bus 
stops file into OSM XML which I can import using JOSM. I'm splitting the data 
into files by local area - here's an example of an area I'm familiar with 
(https://i.imgur.com/xE7TF2c.png) where you can see the import data (blue) line 
up well with the existing data (black).

My plan for conflation was basically to do it by hand since I'm familiar with 
the area and can take my time to do each local area individually. However, I 
could probably also set up some data matching by checking the stop names and 
offsets of existing data.

As for tagging, I'm unsure what the current status is regarding the `naptan:` 
namespace. Looking at those tags, they all seem pretty useless to me (except 
`naptan:AtcoCode` as an identifier). Currently I'm just using roadside bus 
stops marked with a shelter or pole and following the PTv2 scheme to tag them 
as `highway=bus_stop`, `public_transport_platform` and `bus=yes`.

If anyone has any suggestions or input please let me know! Obviously I won't be 
importing anything without some community approval first.
___
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] Importing NaPTAN Data

[Tony Shield]

Hi Spike

I'm interested in importing my local area - Chorley, Lancashire.

I've filtered the Naptan file to get Chorley csv file. I've then 
imported into JOSM conflation plug-in. I'm starting to understand how 
the conflation tool functions and I think the results are good. I've 
done several dry runs to get the technique correct. I'm planning to 
manually review each bus stop - not too bad when there are 3-400.


I too am trying to realise what Naptan codes and fields need to be 
populated for each bus stop, and agree with following the PTv2 scheme.


I haven't performed the import as I haven't been through the import 
authorisation process, and as Naptan is an established data import I 
think that it will not be too difficult as long as the process is correct.


Happy to work with you if you wish.

Regards

TonyS999


On 01/07/2019 16:02, Silent Spike wrote:

Hey folks,

I'm interested in importing NaPTAN bus stop data 
(https://wiki.openstreetmap.org/wiki/NaPTAN/Import) specifically for 
my area of the UK (Aberdeen).


As far as I can tell, some progress was made previously on importing 
NaPTAN data for specific areas of the UK. However, the process for 
requesting an import on the wiki seems to have broken down somewhere 
along the line and I believe the python script mentioned on the wiki 
is outdated.


I went ahead and wrote a 5 minute python 3 script to convert the 
NaPTAN csv bus stops file into OSM XML which I can import using JOSM. 
I'm splitting the data into files by local area - here's an example of 
an area I'm familiar with (https://i.imgur.com/xE7TF2c.png) where you 
can see the import data (blue) line up well with the existing data 
(black).


My plan for conflation was basically to do it by hand since I'm 
familiar with the area and can take my time to do each local area 
individually. However, I could probably also set up some data matching 
by checking the stop names and offsets of existing data.


As for tagging, I'm unsure what the current status is regarding the 
`naptan:` namespace. Looking at those tags, they all seem pretty 
useless to me (except `naptan:AtcoCode` as an identifier). Currently 
I'm just using roadside bus stops marked with a shelter or pole and 
following the PTv2 scheme to tag them as `highway=bus_stop`, 
`public_transport_platform` and `bus=yes`.


If anyone has any suggestions or input please let me know! Obviously I 
won't be importing anything without some community approval first.


___
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] Importing NaPTAN Data

[Silent Spike]

Thanks for sharing your insight and expertise Stuart.

I can see why there might be resistance to importing data. Personally, I
take the view that it saves a lot of time even if it's not perfect
(progress being incremental and all). The majority of bus stops near me in
OSM were added by myself and that's taken a long time. If the data had been
imported already then it would be much quicker to see where stops are and
then simply verify/update the data that's there. With that in mind, that's
basically all I'm proposing - a set of human reviewed mechanical edits
specifically for the Aberdeen area as I'm familiar with it. Looking at the
data already I can see that most of it matches up with bus stops I've
mapped and some are a couple of meters off the true position.

To more accurately define the scope of what I'd like to do:

   1. Import data specifically for the Aberdeen admin area (ATCO code 639)
   2. Import stops of type BCT ("On-street Bus / Coach / Trolley Stop.")
   3. Import BCT stops of type MKD ("Marked (pole, shelter etc)")
   4. Manually conflate and review the data before upload
   5. Split the edits up according to the "LocalityName" data field
   (basically districts from what I can tell)

If I'm able to make it through that process then a methodology will have
been established which perhaps others can use for their areas too. Then
perhaps I can investigate other types of stop (hail and ride, custom,
flexible) and transport.

As for `naptan:` tagging (
https://wiki.openstreetmap.org/wiki/NaPTAN/Tag_mappings), I guess I'm just
not sure why much of that data has to be present in OSM. Surely just the
identifier is enough as it provides a link to the NaPTAN data itself.


On Mon, Jul 1, 2019 at 4:21 PM Stuart Reynolds <
stu...@travelinesoutheast.org.uk> wrote:

> Hi Spike,
>
> There are two aspects to your question. The first is around mechanical
> edits (i.e. importing NaPTAN), and I’ll defer to the group for that because
> while I would like to use NaPTAN (matained, mostly) to update OSM (not
> maintained, mostly) across the UK, there is resistance to that - and it is
> because of that “mostly” issue, because in some areas bus stops have been
> more accurately surveyed.
>
> However, one of my many hats (as a consultant) is as the DfT’s “Public
> Transport Data Standards” expert (Transport is a devolved power, but the
> Scottish Parliament usually keeps Scotland broadly aligned with England).
> If you want to know specific things about NaPTAN fields, then I can tell
> you what they are for and why we need them - either email me direct, or
> reply here if you think that it would be more widely interesting. That is
> particularly true of stop points which are “Custom & Practice” or “Hail &
> Ride” which are not marked on the ground at all (so are perhaps irrelevant
> from a mapping perspective), but are nevertheless valid stopping points
> (and very important from a PT perspective)
>
> As a general note to both you and the wider community, the (English) Bus
> Services Act 2017 provides powers to compel Local Authorities to maintain
> NaPTAN data, and there are steps being discussed to assist in bulk
> “improvements” to the stop data ahead of the timetable provision which is
> intended to commence Jan 2020, mandatory by Jan 2021 (these dates all in
> the public domain, by the way). There is a similar Bill going through
> Holyrood at present, but I don’t know precisely what powers it will contain
> or what dates it will mandate.
>
> Regards,
> Stuart Reynolds
> for traveline south east and anglia
>
> On 1 Jul 2019, at 16:02, Silent Spike  wrote:
>
> Hey folks,
>
> I'm interested in importing NaPTAN bus stop data (
> https://wiki.openstreetmap.org/wiki/NaPTAN/Import) specifically for my
> area of the UK (Aberdeen).
>
> As far as I can tell, some progress was made previously on importing
> NaPTAN data for specific areas of the UK. However, the process for
> requesting an import on the wiki seems to have broken down somewhere along
> the line and I believe the python script mentioned on the wiki is outdated.
>
> I went ahead and wrote a 5 minute python 3 script to convert the NaPTAN
> csv bus stops file into OSM XML which I can import using JOSM. I'm
> splitting the data into files by local area - here's an example of an area
> I'm familiar with (https://i.imgur.com/xE7TF2c.png) where you can see the
> import data (blue) line up well with the existing data (black).
>
> My plan for conflation was basically to do it by hand since I'm familiar
> with the area and can take my time to do each local area individually.
> However, I could probably also set up some data matching by checking the
> stop names and offsets of existing data.
>
> As for tagging, I'm unsure what the current status is regarding the
> `naptan:` namespace. Looking at those tags, they all seem pretty useless to
> me (except `naptan:AtcoCode` as an identifier). Currently I'm just using
> roadside bus stops marked with a shelter or pole and 

Re: [Talk-GB] Importing NaPTAN Data

[Silent Spike]

Hey Tony,

Glad to hear I'm not the only person interested in using this data!

Wasn't aware of the conflation plugin, will have to give it a look now.
Always interested in collaboration, sounds like you've come to the same
conclusion as myself regarding getting import authorisation.

Cheers

On Mon, Jul 1, 2019 at 5:15 PM Tony Shield  wrote:

> Hi Spike
>
> I'm interested in importing my local area - Chorley, Lancashire.
>
> I've filtered the Naptan file to get Chorley csv file. I've then imported
> into JOSM conflation plug-in. I'm starting to understand how the conflation
> tool functions and I think the results are good. I've done several dry runs
> to get the technique correct. I'm planning to manually review each bus stop
> - not too bad when there are 3-400.
>
> I too am trying to realise what Naptan codes and fields need to be
> populated for each bus stop, and agree with following the PTv2 scheme.
>
> I haven't performed the import as I haven't been through the import
> authorisation process, and as Naptan is an established data import I think
> that it will not be too difficult as long as the process is correct.
>
> Happy to work with you if you wish.
>
> Regards
>
> TonyS999
>
>
> On 01/07/2019 16:02, Silent Spike wrote:
>
> Hey folks,
>
> I'm interested in importing NaPTAN bus stop data (
> https://wiki.openstreetmap.org/wiki/NaPTAN/Import) specifically for my
> area of the UK (Aberdeen).
>
> As far as I can tell, some progress was made previously on importing
> NaPTAN data for specific areas of the UK. However, the process for
> requesting an import on the wiki seems to have broken down somewhere along
> the line and I believe the python script mentioned on the wiki is outdated.
>
> I went ahead and wrote a 5 minute python 3 script to convert the NaPTAN
> csv bus stops file into OSM XML which I can import using JOSM. I'm
> splitting the data into files by local area - here's an example of an area
> I'm familiar with (https://i.imgur.com/xE7TF2c.png) where you can see the
> import data (blue) line up well with the existing data (black).
>
> My plan for conflation was basically to do it by hand since I'm familiar
> with the area and can take my time to do each local area individually.
> However, I could probably also set up some data matching by checking the
> stop names and offsets of existing data.
>
> As for tagging, I'm unsure what the current status is regarding the
> `naptan:` namespace. Looking at those tags, they all seem pretty useless to
> me (except `naptan:AtcoCode` as an identifier). Currently I'm just using
> roadside bus stops marked with a shelter or pole and following the PTv2
> scheme to tag them as `highway=bus_stop`, `public_transport_platform` and
> `bus=yes`.
>
> If anyone has any suggestions or input please let me know! Obviously I
> won't be importing anything without some community approval first.
>
> ___
> Talk-GB mailing 
> listTalk-GB@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-gb
>
> ___
> 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] Importing NaPTAN Data

[David Woolley]

On 01/07/2019 16:02, Silent Spike wrote:
As far as I can tell, some progress was made previously on importing 
NaPTAN data for specific areas of the UK. However, the process for 
requesting an import on the wiki seems to have broken down somewhere 
along the line and I believe the python script mentioned on the wiki is 
outdated.




In may experience, a lot of the original NaPTAN imports have decayed:

- people have double mapped stops and the the NaPTAN one has been deleted;

- stop have moved and got double mapped and deleted as a result;

- stops have been temporarily out of service, e.g whilst redeveloping a 
bus station, and been deleted and then lost the NaPTAN associations when 
remapped.


Also, all bus stops need continual maintenance because names get changed 
 as landmarks come and go.


Given that few people like maintenance work, if you can't map all the 
stops from first principles, it is very unlikely that imported ones will 
get maintained.  Retaining the NaPTAN tagging is important in allowing 
any later remerge of the updated NaPTAN data.


Another problem with NaPTAN stops, which applies to non-OSM users as 
well is that they have virtual stops in Hail and Ride areas.  Routers 
seem to only like people boarding at those place, so, in my case, can 
take me about 7 minutes out of my way against the direction of travel, 
so tell me I have missed a bus that could be easily caught.


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

Re: [Talk-GB] Importing NaPTAN Data

[Silent Spike]

On Tue, Jul 2, 2019 at 10:00 AM David Woolley 
wrote:

> In may experience, a lot of the original NaPTAN imports have decayed:
>
> - people have double mapped stops and the the NaPTAN one has been deleted;
>
> - stop have moved and got double mapped and deleted as a result;
>
> - stops have been temporarily out of service, e.g whilst redeveloping a
> bus station, and been deleted and then lost the NaPTAN associations when
> remapped.
>

I'm not sure why double mapping is occurring, but it seems to me that (even
with these mapping mistakes) having the stops present in OSM is better than
not using the data at all. If conflation can be done once, it can be
repeated in future if data needs to be imported as an update.

 On Tue, Jul 2, 2019 at 10:00 AM David Woolley 
wrote:

> Also, all bus stops need continual maintenance because names get changed
>   as landmarks come and go.
>
> Given that few people like maintenance work, if you can't map all the
> stops from first principles, it is very unlikely that imported ones will
> get maintained.  Retaining the NaPTAN tagging is important in allowing
> any later remerge of the updated NaPTAN data.
>

I gather that you're suggesting future data imports will be needed to keep
stop data up-to-date and so the NaPTAN tagging is needed to make that
process easier? In which case I agree, although I still don't see what use
the tags other than the NaPTAN ATCO code provide. It appears to be a stable
identifier, which means by including it in OSM the NaPTAN data is directly
associated with the tagged OSM element (reducing the need to maintain
tagging in OSM).

 On Tue, Jul 2, 2019 at 10:00 AM David Woolley 
wrote:

> Another problem with NaPTAN stops, which applies to non-OSM users as
> well is that they have virtual stops in Hail and Ride areas.  Routers
> seem to only like people boarding at those place, so, in my case, can
> take me about 7 minutes out of my way against the direction of travel,
> so tell me I have missed a bus that could be easily caught


At present I don't intend to include hail and ride data in my import
process. Would need to investigate further how best to handle it and I'm
personally only interested in clearly marked bus stops.
 ___

> 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] Importing NaPTAN Data

[Ed Loach]

David wrote:

> Given that few people like maintenance work, if you can't map all
> the
> stops from first principles, it is very unlikely that imported ones will
> get maintained.  Retaining the NaPTAN tagging is important in
> allowing
> any later remerge of the updated NaPTAN data.

I've been regularly updating local bus route relations (all now upgraded to PT 
schema v2) in Tendring [1], Colchester [1] and Maldon [2] areas of Essex. This 
involves more maintenance than just the bus stops (which for Essex were 
imported some years ago). I've written a program to help me with this, 
comparing the opendata with the OSM data so I can work out what needs updating.

Occasionally I encounter a bus stop used by a bus route which wasn't imported 
previously. In these cases I add the stop from NaPTAN (based on their latitude 
and longitude) and add the tags:
highway=bus_stop
public_transport=platform
source=naptan
naptan:verified=no
name=(NaPTAN name)
naptan:AtcoCode=(whatever)
naptan:NaptanCode=(whatever)

If the bus stop type is not MKD I add

naptan:BusStopType=(bus stop type)

and if the status is not "act" I add

naptan:Status=(status)

This last one is very rare as I think it is only once that I've found a deleted 
bus stop still part of a bus route (the road had been diverted and new stops 
installed - the old stop was on what is now a cycle path).
 
> Another problem with NaPTAN stops, which applies to non-OSM
> users as
> well is that they have virtual stops in Hail and Ride areas.  Routers
> seem to only like people boarding at those place, so, in my case, can
> take me about 7 minutes out of my way against the direction of
> travel,
> so tell me I have missed a bus that could be easily caught.

I'll agree with this. I've been adding them at the NaPTAN location as described 
above if they aren't already in, but these are occasionally up cul-de-sacs 
(usually at the start or end of the route). 

Ed

[1] https://wiki.openstreetmap.org/wiki/Tendring(Essex)/Bus_Routes
[2] https://wiki.openstreetmap.org/wiki/Maldon(Essex_District)/Bus_Routes



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [Talk-GB] Importing NaPTAN Data

[Silent Spike]

On Tue, Jul 2, 2019 at 11:07 AM Ed Loach  wrote:

> highway=bus_stop
> public_transport=platform
> source=naptan
> naptan:verified=no
> name=(NaPTAN name)
> naptan:AtcoCode=(whatever)
> naptan:NaptanCode=(whatever)
>
> If the bus stop type is not MKD I add
>
> naptan:BusStopType=(bus stop type)
>
> and if the status is not "act" I add
>
> naptan:Status=(status)
>

These tags all seem reasonable to import to me. Would be curious to learn
more about your route maintenance process. I have a list of local bus route
relations I've been meaning to update, but it's hard to do so without all
of the stops mapped (hence my desire to import the available data).


> ___
> 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] Importing NaPTAN Data

[Brian Prangle]

It's also useful to add

shelter=yes if there is one
route_ref= x;y  indicating bus route nos that stop there (if indicated on
the stop)
CUS stops are also useful to add but omitting the highway=bus-stop tag (
you can always add the public tranpsort stop_poisition as a node on the
highway). They often become marked with pole over time
There's also a relatively new tag to indicate if the bus stop allows the
bus to pull in to a small layby off the main highway (but I've forgotten
what it is)

Your local bus authority might also be able to help (in the West Mids TfWM
have been very helpful)

Personally I've given up on bus route relations: they're a time sink in
editing them in the first place and they're even more of a time sink to
maintain. I think they're better off in a separate layer in dedicated
journey planners maintained by public transport authorities.

Regards

Brian

Regards

Brian

On Thu, 4 Jul 2019 at 14:54, Silent Spike  wrote:

> On Tue, Jul 2, 2019 at 11:07 AM Ed Loach  wrote:
>
>> highway=bus_stop
>> public_transport=platform
>> source=naptan
>> naptan:verified=no
>> name=(NaPTAN name)
>> naptan:AtcoCode=(whatever)
>> naptan:NaptanCode=(whatever)
>>
>> If the bus stop type is not MKD I add
>>
>> naptan:BusStopType=(bus stop type)
>>
>> and if the status is not "act" I add
>>
>> naptan:Status=(status)
>>
>
> These tags all seem reasonable to import to me. Would be curious to learn
> more about your route maintenance process. I have a list of local bus route
> relations I've been meaning to update, but it's hard to do so without all
> of the stops mapped (hence my desire to import the available data).
>
>
>> ___
>> 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
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Importing NaPTAN Data

[Dave F via Talk-GB]

Please, please don't use public_transport=platform unless you're 
actually mapping an actual, physical, raised object, similar to railway 
platforms.


'platform' has been misappropriated from the physical railway=platform 
by those who developed the PT schema to mean an arbitrary area of 
pavement that's somewhere, roughly near where a bus stops. In OSM we map 
*physical* objects only.


It has now been regressed one stage further, being superfluously added 
to highway=bus_stop nodes. So much of the PT schema is just duplicating 
valid, existing data which leads to confusion & errors. It is a waste of 
time & effort.


--

if you're adding the bus stop & your source is naptan how can 
naptan:verified=no?


DaveF


On 02/07/2019 11:06, Ed Loach wrote:

David wrote:


Given that few people like maintenance work, if you can't map all
the
stops from first principles, it is very unlikely that imported ones will
get maintained.  Retaining the NaPTAN tagging is important in
allowing
any later remerge of the updated NaPTAN data.

I've been regularly updating local bus route relations (all now upgraded to PT 
schema v2) in Tendring [1], Colchester [1] and Maldon [2] areas of Essex. This 
involves more maintenance than just the bus stops (which for Essex were 
imported some years ago). I've written a program to help me with this, 
comparing the opendata with the OSM data so I can work out what needs updating.

Occasionally I encounter a bus stop used by a bus route which wasn't imported 
previously. In these cases I add the stop from NaPTAN (based on their latitude 
and longitude) and add the tags:
highway=bus_stop
public_transport=platform
source=naptan
naptan:verified=no
name=(NaPTAN name)
naptan:AtcoCode=(whatever)
naptan:NaptanCode=(whatever)

If the bus stop type is not MKD I add

naptan:BusStopType=(bus stop type)

and if the status is not "act" I add

naptan:Status=(status)

This last one is very rare as I think it is only once that I've found a deleted 
bus stop still part of a bus route (the road had been diverted and new stops 
installed - the old stop was on what is now a cycle path).
  

Another problem with NaPTAN stops, which applies to non-OSM
users as
well is that they have virtual stops in Hail and Ride areas.  Routers
seem to only like people boarding at those place, so, in my case, can
take me about 7 minutes out of my way against the direction of
travel,
so tell me I have missed a bus that could be easily caught.

I'll agree with this. I've been adding them at the NaPTAN location as described 
above if they aren't already in, but these are occasionally up cul-de-sacs 
(usually at the start or end of the route).

Ed

[1] https://wiki.openstreetmap.org/wiki/Tendring(Essex)/Bus_Routes
[2] https://wiki.openstreetmap.org/wiki/Maldon(Essex_District)/Bus_Routes



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


___
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] Importing NaPTAN Data

[Brian Prangle]

 naptan:verified=no dates back to the original import in 2009 and was there
to indicate the bus stop needed surveying to verify its position- when a
survey was done the process was for this tag to be deleted. Might be good
to adopt this process here too?

Regards

Brian

On Thu, 4 Jul 2019 at 16:10, Dave F via Talk-GB 
wrote:

>
> Please, please don't use public_transport=platform unless you're
> actually mapping an actual, physical, raised object, similar to railway
> platforms.
>
> 'platform' has been misappropriated from the physical railway=platform
> by those who developed the PT schema to mean an arbitrary area of
> pavement that's somewhere, roughly near where a bus stops. In OSM we map
> *physical* objects only.
>
> It has now been regressed one stage further, being superfluously added
> to highway=bus_stop nodes. So much of the PT schema is just duplicating
> valid, existing data which leads to confusion & errors. It is a waste of
> time & effort.
>
> --
>
> if you're adding the bus stop & your source is naptan how can
> naptan:verified=no?
>
> DaveF
>
>
> On 02/07/2019 11:06, Ed Loach wrote:
> > David wrote:
> >
> >> Given that few people like maintenance work, if you can't map all
> >> the
> >> stops from first principles, it is very unlikely that imported ones will
> >> get maintained.  Retaining the NaPTAN tagging is important in
> >> allowing
> >> any later remerge of the updated NaPTAN data.
> > I've been regularly updating local bus route relations (all now upgraded
> to PT schema v2) in Tendring [1], Colchester [1] and Maldon [2] areas of
> Essex. This involves more maintenance than just the bus stops (which for
> Essex were imported some years ago). I've written a program to help me with
> this, comparing the opendata with the OSM data so I can work out what needs
> updating.
> >
> > Occasionally I encounter a bus stop used by a bus route which wasn't
> imported previously. In these cases I add the stop from NaPTAN (based on
> their latitude and longitude) and add the tags:
> > highway=bus_stop
> > public_transport=platform
> > source=naptan
> > naptan:verified=no
> > name=(NaPTAN name)
> > naptan:AtcoCode=(whatever)
> > naptan:NaptanCode=(whatever)
> >
> > If the bus stop type is not MKD I add
> >
> > naptan:BusStopType=(bus stop type)
> >
> > and if the status is not "act" I add
> >
> > naptan:Status=(status)
> >
> > This last one is very rare as I think it is only once that I've found a
> deleted bus stop still part of a bus route (the road had been diverted and
> new stops installed - the old stop was on what is now a cycle path).
> >
> >> Another problem with NaPTAN stops, which applies to non-OSM
> >> users as
> >> well is that they have virtual stops in Hail and Ride areas.  Routers
> >> seem to only like people boarding at those place, so, in my case, can
> >> take me about 7 minutes out of my way against the direction of
> >> travel,
> >> so tell me I have missed a bus that could be easily caught.
> > I'll agree with this. I've been adding them at the NaPTAN location as
> described above if they aren't already in, but these are occasionally up
> cul-de-sacs (usually at the start or end of the route).
> >
> > Ed
> >
> > [1] https://wiki.openstreetmap.org/wiki/Tendring(Essex)/Bus_Routes
> > [2]
> https://wiki.openstreetmap.org/wiki/Maldon(Essex_District)/Bus_Routes
> >
> >
> >
> > ---
> > This email has been checked for viruses by Avast antivirus software.
> > https://www.avast.com/antivirus
> >
> >
> > ___
> > 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
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Importing NaPTAN Data

[Martin Wynne]

On 04/07/2019 16:11, Dave F via Talk-GB wrote:


In OSM we map 
*physical* objects only.


In rural areas there are many places where buses are timetabled to stop 
but where there is nothing physical -- no signpost or shelter.


Are these highway=bus_stop in OSM?

The wiki for highway says "Can be mapped more rigorously using 
public_transport=stop_position for the position where the vehicle stops 
and public_transport=platform for the place where passengers wait.


cheers,

Martin.

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

Re: [Talk-GB] Importing NaPTAN Data

[Silent Spike]

On Thu, Jul 4, 2019 at 4:10 PM Dave F via Talk-GB 
wrote:

>
> Please, please don't use public_transport=platform unless you're
> actually mapping an actual, physical, raised object, similar to railway
> platforms.
>
> It has now been regressed one stage further, being superfluously added
> to highway=bus_stop nodes. So much of the PT schema is just duplicating
> valid, existing data which leads to confusion & errors. It is a waste of
> time & effort.
>

My understanding is that `public_transport=platform` is any place where
public transport can be accessed and should not literally be interpreted as
a physical platform (tags not literally matching what they are used to map
seem to be very common in OSM). I think if you want to constructively
change tagging practise you need to discuss it on the tagging list and that
the import I would like to do should follow established tagging.

If anything `highway=bus_stop` is redundant data, however it's necessary
for render compatibility (violating the "don't tag for the renderer rule",
but everyone does it because default render still doesn't support PTv2
scheme).

Until the wider OSM community establishes better methods of tag creation
and deprecation these issues will continually crop up and (in my opinion)
should not impede mapping progress.


> ___
> 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] Importing NaPTAN Data

[Silent Spike]

On Thu, Jul 4, 2019 at 4:40 PM Martin Wynne  wrote:

> In rural areas there are many places where buses are timetabled to stop
> but where there is nothing physical -- no signpost or shelter.
>
> Are these highway=bus_stop in OSM?
>
> The wiki for highway says "Can be mapped more rigorously using
> public_transport=stop_position for the position where the vehicle stops
> and public_transport=platform for the place where passengers wait.
>

I believe such stops would just be mapped with stop positions. However, I
don't intend to import them currently as I'd need to look into that more
in-depth (and want to keep things simple for now). Just getting the
physical stops imported seems like a good first step which would have the
most significant improvement on available data in OSM.

___
> 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] Importing NaPTAN Data

[Andy Townsend]

On 04/07/2019 16:39, Martin Wynne wrote:
In rural areas there are many places where buses are timetabled to 
stop but where there is nothing physical -- no signpost or shelter.


Are these highway=bus_stop in OSM?


(following a previous discussion on this list) I've used 
"physically_present=no" on one of those - after verifying that buses 
actually stop there. Example:


https://www.openstreetmap.org/node/502390265

Best Regards,

Andy



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

Re: [Talk-GB] Importing NaPTAN Data

[Mateusz Konieczny]

4 lip 2019, 17:11 od talk-gb@openstreetmap.org:

>
> In OSM we map *physical* objects only.
>
What about border - especially 
lower administrative units and 
nature reserves?___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Importing NaPTAN Data

[Dave F via Talk-GB]

On 04/07/2019 16:39, Martin Wynne wrote:

On 04/07/2019 16:11, Dave F via Talk-GB wrote:


In OSM we map *physical* objects only.


In rural areas there are many places where buses are timetabled to 
stop but where there is nothing physical -- no signpost or shelter.


These are still 'physical' in the sense that they exist in the timetable 
& Naptan documents. (Think also boundaries which don't have dashed lines 
painted across fields)




Are these highway=bus_stop in OSM?


As a guesstimate, if they came from the naptan import, then probably yes



The wiki for highway says "Can be mapped more rigorously using 
public_transport=stop_position for the position where the vehicle 
stops and public_transport=platform for the place where passengers wait.


It's disappointing to see, once again, the PT schema developers 
hi-jacking wiki pages to enforce their schema. The comments column is 
meant to describe how to use the tag not promote alternatives. This 
needs changing.



"public_transport=stop_position for the position where the vehicle stops"
But that's not happening, is it? it's being wastefully duplicated on the 
highway=bus_stop which is most often at the pole/sign location, not on 
the highway.


highway=bus_stop is perfectly adequate to locate the place where people 
wait for a bus. 'platform' is redundant


PTv2 is a complete mess. it needs rescinding.

DaveF

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

Re: [Talk-GB] Importing NaPTAN Data

[Silent Spike]

This is getting a little bit off topic. I guess to bring things back on
track, would there be any objections to an import along these lines:

   1. Import data specifically for the Aberdeen admin area (ATCO code 639)
   2. Import stops of type BCT ("On-street Bus / Coach / Trolley Stop.")
   3. Import BCT stops of type MKD ("Marked (pole, shelter etc)")
   4. Manually conflate and review the data before upload using JOSM
   5. Split the edits up according to the "LocalityName" data field
   (basically districts from what I can tell)  [or is it better to be one
   changeset for the whole area?]
   6. Tag the stops using:
  - `highway=bus_stop`
  - `public_transport=platform`
  - `bus=yes`
  - `name=*` [Imported]
  - `naptan:AtcoCode=*` [Imported]
  - `naptan:NaptanCode=*` [Imported]
  - `source=naptan`
  - `naptan:verified=no`



___
> 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] Importing NaPTAN Data

[Dave F via Talk-GB]

On 04/07/2019 16:59, Silent Spike wrote:


My understanding is that `public_transport=platform` is any place where
public transport can be accessed


Same as bus_stop/tram_stop, you mean?


and should not literally be interpreted as
a physical platform


then why hi-jack the word 'platform' which has a clear, specific 
meaning? Yet more confusion



If anything `highway=bus_stop` is redundant data,


It's is a well established, popular tag far exceeding any PT tags


however it's necessary
for render compatibility (violating the "don't tag for the renderer rule"


I think your logic got a bit twisted around. bus_stop is the original & 
no PT tag adds anything extra to improve the database.



and (in my opinion) should not impede mapping progress.


Existing tags work, Changing for the sake of change is irrelevant. PTv2 
needs to be rescinded.


DaveF

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

Re: [Talk-GB] Importing NaPTAN Data

[Dave F via Talk-GB]

In OSM we map *physical* objects only.

What about border - especially
lower administrative units and
nature reserves?


From a previous post:
These are still 'physical' in the sense that they exist in the timetable 
& Naptan documents. (Think also boundaries which don't have dashed lines 
painted across fields)


DaveF

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

Re: [Talk-GB] Importing NaPTAN Data

[Martin Wynne]

On 04/07/2019 18:51, Dave F via Talk-GB wrote:


These are still 'physical' in the sense that they exist in the timetable 
& Naptan documents. (Think also boundaries which don't have dashed lines 
painted across fields)


This strikes me as a strange definition of "physical" and could cover 
almost anything.


My definition of "physical" is something I can take a photograph of.

But I don't see any reason why OSM should be limited to such "physical" 
objects. Most maps show all sorts of non-physical data.


cheers,

Martin.

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

Re: [Talk-GB] Importing NaPTAN Data

[ael via Talk-GB]

On Thu, Jul 04, 2019 at 06:49:10PM +0100, Dave F via Talk-GB wrote:
> 
> 
> On 04/07/2019 16:59, Silent Spike wrote:
> > 
> > My understanding is that `public_transport=platform` is any place where
> > public transport can be accessed
> 
> Same as bus_stop/tram_stop, you mean?
> 
> > and should not literally be interpreted as
> > a physical platform
> 
> then why hi-jack the word 'platform' which has a clear, specific meaning?
> Yet more confusion
> 
> > If anything `highway=bus_stop` is redundant data,
> 
> It's is a well established, popular tag far exceeding any PT tags
> 
> > however it's necessary
> > for render compatibility (violating the "don't tag for the renderer rule"
> 
> I think your logic got a bit twisted around. bus_stop is the original & no
> PT tag adds anything extra to improve the database.
> 
> > and (in my opinion) should not impede mapping progress.
> 
> Existing tags work, Changing for the sake of change is irrelevant. PTv2
> needs to be rescinded.

+1

ael


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

Re: [Talk-GB] Importing NaPTAN Data

[Mateusz Konieczny]

4 lip 2019, 19:28 od talk-gb@openstreetmap.org:

> On 04/07/2019 16:39, Martin Wynne wrote:
>
>> On 04/07/2019 16:11, Dave F via Talk-GB wrote:
>>
>>>
>>> In OSM we map *physical* objects only.
>>>
>>
>> In rural areas there are many places where buses are timetabled to stop but 
>> where there is nothing physical -- no signpost or shelter.
>>
>
> These are still 'physical' in the sense that they exist in the timetable & 
> Naptan documents. (Think also boundaries which don't have dashed lines 
> painted across fields)
>
In that sense everything is physical,
boundaries also have paper records
and there are some markers.
>>
>> The wiki for highway says "Can be mapped more rigorously using 
>> public_transport=stop_position for the position where the vehicle stops and 
>> public_transport=platform for the place where passengers wait.
>>
>
> It's disappointing to see, once again, the PT schema developers hi-jacking 
> wiki pages to enforce their schema. The comments column is meant to describe 
> how to use the tag not promote alternatives. This needs changing.
>
Yeah, there is nothing more rigorous
in extremely verbose PTv2 tagging.
> highway=bus_stop is perfectly adequate to locate the place where people wait 
> for a bus. 'platform' is redundant
>
> PTv2 is a complete mess. it needs rescinding.
>
I completely agree here.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Importing NaPTAN Data

[Ed Loach]

Silent Spike wrote:
> Would be curious to learn more about your route maintenance process. 
> I have a list of local bus route relations I've been meaning to update, but 
> it's hard to do so without all of the stops mapped (hence my desire to 
> import the available data).

The application I wrote and use is available on github and has some (perhaps 
now a bit dated) notes on use available there:
https://github.com/EdLoach/CheckPublicTransportRelations/tree/develop
The develop branch (above link) is what I'm currently using - I've not created 
a recent release to incorporate bug fixes, so should probably do so when I get 
a moment. I think there might be a current bug relating to adding new areas 
that aren't added in the default locations file on first run, so should 
probably fix that first.

I've avoided the recent tagging discussions emails. The app is written to 
validate against the adopted PT v2 schema as documented in the wiki, with 
additions to handle tagging noted in either the wiki or on this list dating 
from the time of the previous naptan stop import, and that I completely don't 
care about public_transport=stop_position. E.g. I have a "surveyed" property 
based on the various tags discussed previously: physically_present, flag, kerb, 
timetable_case and shelter (which I've taken as signs the imported stop has 
been physically surveyed, though typing this now I wonder if I should exclude 
shelter like I do layby as it can possibly be determined from aerial imagery - 
I just know I haven't locally):
https://github.com/EdLoach/CheckPublicTransportRelations/blob/master/CheckPublicTransportRelations/MainForm.cs#L365
(this is in the method that takes the OSM XML and converts it into one of by 
BusStop objects).

Basically it compares the OSM data with the Opendata and I try and fix 
discrepancies manually, either tweaking the route relations that have changed 
or by adding new route variants if required. I have occasionally been rate 
limited by overpass since I added a hyperlink column to zoom to a stop, rather 
than doing click on naptancode cell, ctrl-c, switch to JOSM, ctrl-f, ctrl-v, 
enter, check whether more than one node has been selected (as for example 
1500IM111 might match all these without adding extra bits after ctrl-v: 
1500IM111, 1500IM1110, 1500IM, 1500IM1112, 1500IM1112Y, 1500IM1114, 
1500IM1114Y, 1500IM1115, 1500IM1116, 1500IM1117, 1500IM1117Y, 1500IM1117YB, 
1500IM1117YC, 1500IM1119) - if I get limited I just take a break for a while.

The application isn't clever enough to know when a particular route variant 
runs, so if you run it at an unfortunate time you might find you add all the 
current route variants and all the ones that replace them starting soon so are 
also in the file, and next time you run the application have to delete half of 
what you added the previous time. A recent route change did give me forewarning 
of when a new roundabout on the A120 was about to open when a new route variant 
appeared, changing from the old route as it passed through a village near the 
new roundabout, to head northwest towards the roundabout instead of north to 
the gap in the dual carriageway that was due to close when the roundabout 
opened.

Ed



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Mateusz Konieczny]

5 Jul 2019, 09:04 by silentspike...@gmail.com:

> `naptan:AtcoCode=*` [Imported]
> `naptan:NaptanCode=*` [Imported]
>
I reformatted
https://wiki.openstreetmap.org/wiki/Key:naptan:AtcoCode 

https://wiki.openstreetmap.org/wiki/Key:naptan:NaptanCode 

(added templates making them machine readable, descriptions will appear
for example at Taginfo)

Is it useful to use both? What is the difference between them?
Is NaptanCode actually used as planned ("referring to the stop in public facing 
systems")?


> Alternatively, if you support the proposal then it's also useful to know 😊
>

It may help to include example (of full) .osm data file to make easy for mappers
to judge data quality in their area.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Gareth L]

I’m certain I’ve seen “text this bus stop code to see next departures” use the 
naptan code. Whether or not that service is still live, I dunno.

On 5 Jul 2019, at 10:17, Mateusz Konieczny 
mailto:matkoni...@tutanota.com>> wrote:


5 Jul 2019, 09:04 by silentspike...@gmail.com:

 *   `naptan:AtcoCode=*` [Imported]
 *   `naptan:NaptanCode=*` [Imported]

I reformatted
https://wiki.openstreetmap.org/wiki/Key:naptan:AtcoCode
https://wiki.openstreetmap.org/wiki/Key:naptan:NaptanCode
(added templates making them machine readable, descriptions will appear
for example at Taginfo)

Is it useful to use both? What is the difference between them?
Is NaptanCode actually used as planned ("referring to the stop in public facing 
systems")?

Alternatively, if you support the proposal then it's also useful to know 😊

It may help to include example (of full) .osm data file to make easy for mappers
to judge data quality in their area.
___
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] Importing NaPTAN Data [Thread 2]

[Stuart Reynolds]

Yes, both are still in use

AtcoCode is the unique “ID” of the bus stop and is the key that is used in 
databases to identify the stop. It is therefore also the key that gets used in 
an AnnotatedStopRef within the TransXChange (timetable) data.

NaptanCode is, in my view, unhelpfully named because in a NaPTAN database you 
would tend to think of it as the key. But it isn’t. It is certainly unique, but 
it has some constraints around which characters can follow other characters so 
that on (very old style, now) phones you didn’t have to push the same button 
twice in succession (and actually using a combination of letters that use the 
same key sequence also works). By and large it is text (except in Scotland, if 
I recall, where it is numeric) and is the code that you would send to the 
(charged for) 84628 “next departures” SMS service (Nextbuses). You can also use 
it online at nextbuses.mobi for free, although there you can also use the 
AtcoCode, confusingly.

For example, Southend Travel Centre stop A has the AtcoCode 15800720 (158 is 
the Southend prefix) and the NaptanCode soadjdaw (where soa is the Southend 
prefix). The next departures can be seen using  
http://nextbuses.mobi/WebView/BusStopSearch/BusStopSearchResults/soadjdaw

Both the SMS and Nexbuses services are still active, and not planned to be 
turned off any time soon.

Regards,
Stuart Reynolds
for traveline south east and anglia

On 5 Jul 2019, at 10:27, Gareth L mailto:o...@live.co.uk>> 
wrote:

I’m certain I’ve seen “text this bus stop code to see next departures” use the 
naptan code. Whether or not that service is still live, I dunno.

On 5 Jul 2019, at 10:17, Mateusz Konieczny 
mailto:matkoni...@tutanota.com>> wrote:


5 Jul 2019, 09:04 by silentspike...@gmail.com:

 *   `naptan:AtcoCode=*` [Imported]
 *   `naptan:NaptanCode=*` [Imported]

I reformatted
https://wiki.openstreetmap.org/wiki/Key:naptan:AtcoCode
https://wiki.openstreetmap.org/wiki/Key:naptan:NaptanCode
(added templates making them machine readable, descriptions will appear
for example at Taginfo)

Is it useful to use both? What is the difference between them?
Is NaptanCode actually used as planned ("referring to the stop in public facing 
systems")?

Alternatively, if you support the proposal then it's also useful to know 😊

It may help to include example (of full) .osm data file to make easy for mappers
to judge data quality in their area.
___
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

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

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Silent Spike]

On Fri, Jul 5, 2019 at 10:17 AM Mateusz Konieczny 
wrote:

> I reformatted
> https://wiki.openstreetmap.org/wiki/Key:naptan:AtcoCode
> https://wiki.openstreetmap.org/wiki/Key:naptan:NaptanCode
> (added templates making them machine readable, descriptions will appear
> for example at Taginfo)
>

Thank you, documentation of the tags imported previously has definitely
been lacking


> Is it useful to use both? What is the difference between them?
> Is NaptanCode actually used as planned ("referring to the stop in public
> facing systems")?
>

Of this I'm personally unsure, however there's not much harm in it and it
seems standard enough practise


> It may help to include example (of full) .osm data file to make easy for
> mappers
> to judge data quality in their area.
>

Here is a single file with all stops which I would be importing for the
Aberdeen area (
https://drive.google.com/open?id=1_QWn02Gi0YG8GCza0CeNQXtIKM_J82Y0), if
split into subdivisions there are 63 areas in total within this.


> ___
> 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] Importing NaPTAN Data [Thread 2]

[Silent Spike]

On Fri, Jul 5, 2019 at 10:52 AM Stuart Reynolds <
stu...@travelinesoutheast.org.uk> wrote:

> Yes, both are still in use
>
> -snip-
>
> Regards,
> Stuart Reynolds
> for traveline south east and anglia
>

As someone more in the know, are there any fields of the NaPTAN data which
you think should be imported which I haven't included?

___
> 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] Importing NaPTAN Data [Thread 2]

[Stuart Reynolds]

From your original post, I didn’t think so, especially.

However, the fields in NaPTAN are designed to be granular, and while many may 
seem to be irrelevant to OSM (e.g. why have a street name when the street is 
named on the map) different local authorities will have different approaches to 
using that granularity for flag display. So the stop in NaPTAN might have a 
common name of “Stuart Close” with an indicator of “adj”, showing that the stop 
was adjacent to Stuart Close. However, street name becomes relevant if the 
local authority shows e.g. "High Street / Stuart Close” on the flag (with High 
Street being the street that the stop is physically located on).

So it is a bit of a “suck it and see”, but in general I would suggest that, of 
the descriptive fields, you definitely want Common Name and Indicator, and you 
should consider including Streetname, Crossing and Landmark. In Wales and 
Gaelic-speaking parts of Scotland (including Ayr, apparently, where they are 
now erecting dual language signage) you should also include any non-English 
alternative names too. I’m less fussed about Locality, because the context of 
the map should give it, but sometimes child (lowest level) localities are not 
named on the map, or are named differently to the map.

I certainly wouldn’t include the short names (which are usually just the 
abbreviations on on-street real time displays or fronts of buses) or the plate 
/ cleardown etc codes.

Note in passing that NaPTAN status often gets mis-used. Some authorities have a 
tendency to mark a stop as deleted when it no longer has services at it, even 
thought the infrastructure is still in place on the ground. These are supposed 
to be ACT but unused in NaPTAN, not deleted. If they are covered up, or 
physically removed, then they can be deleted. But not otherwise. You may come 
across some of these (or you may not).

Hope that helps.

Regards,
Stuart Reynolds
for traveline south east and anglia

On 5 Jul 2019, at 10:57, Silent Spike 
mailto:silentspike...@gmail.com>> wrote:

On Fri, Jul 5, 2019 at 10:52 AM Stuart Reynolds 
mailto:stu...@travelinesoutheast.org.uk>> 
wrote:
Yes, both are still in use

-snip-

Regards,
Stuart Reynolds
for traveline south east and anglia

As someone more in the know, are there any fields of the NaPTAN data which you 
think should be imported which I haven't included?

___
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

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

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Silent Spike]

On Fri, Jul 5, 2019 at 11:35 AM Stuart Reynolds <
stu...@travelinesoutheast.org.uk> wrote:

> -snip-
>
> Hope that helps.
>

Pretty much the perfect response, thank you!

Good point about alternate names, will add support for those to my script
now (maybe unnecessary for my area, but I'd like to share it in future). I
see that many of the English alternate names are nearby landmarks or
features (e.g. "The Crossroads"). Should I include these too as `loc_name`
or similar (open question to all)?
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Gareth L]

Forgive me if this is silly question/statement, but the adj/alt names etc are 
in the naptan dataset. Wouldn’t it be better to have the link made between the 
stop in OSM and the record in naptan (using the codes prior mentioned).
My thinking is data consumers could link and retrieve values using that. 
Merging the extra data values again might potentially develop discrepancies 
over time.

I’d think the atco code is unique and (hopefully) not reused, but the alt names 
etc could be modified over time.


Gareth

On 5 Jul 2019, at 12:34, Silent Spike 
mailto:silentspike...@gmail.com>> wrote:

On Fri, Jul 5, 2019 at 11:35 AM Stuart Reynolds 
mailto:stu...@travelinesoutheast.org.uk>> 
wrote:
-snip-

Hope that helps.

Pretty much the perfect response, thank you!

Good point about alternate names, will add support for those to my script now 
(maybe unnecessary for my area, but I'd like to share it in future). I see that 
many of the English alternate names are nearby landmarks or features (e.g. "The 
Crossroads"). Should I include these too as `loc_name` or similar (open 
question to all)?
___
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] Importing NaPTAN Data [Thread 2]

[Silent Spike]

On Fri, Jul 5, 2019 at 1:02 PM Gareth L  wrote:

> Forgive me if this is silly question/statement, but the adj/alt names etc
> are in the naptan dataset. Wouldn’t it be better to have the link made
> between the stop in OSM and the record in naptan (using the codes prior
> mentioned).
> My thinking is data consumers could link and retrieve values using that.
> Merging the extra data values again might potentially develop discrepancies
> over time.
>
> I’d think the atco code is unique and (hopefully) not reused, but the alt
> names etc could be modified over time.
>

A perfectly valid question and something I wonder also.

For example, the indicator field is somewhat meaningless to a data consumer
unless they know what it represents as per the NaPTAN schema - so perhaps
it's best left out of the OSM data?
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Stuart Reynolds]

When you say that

the indicator field is somewhat meaningless to a data consumer

what did you have in mind? To the end-user of the data (i.e. someone wanting to 
know about where to catch the bus) this is absolutely critical.

For example, in my previous post I face a suggestion of “Stuart Close” with an 
indicator of “adj”. There would usually be a second stop of the same common 
name, Stuart Close, perhaps with the indicator “opp”. Without understanding the 
NaPTAN schema, “app Stuart Close” and “adj Stuart Close” are understandable and 
are service direction dependent.

Even more so in bus stations. The name Derby Bus Station (actually just "Bus 
Station” in the locality of Derby) applies equally to all 29 bays in the bus 
station. “Bay 1” through “Bay 29” are the indicators.

Regards,
Stuart Reynolds
for traveline south east and anglia

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

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Andy Townsend]

On 05/07/2019 13:19, Silent Spike wrote:
On Fri, Jul 5, 2019 at 1:02 PM Gareth L > wrote:


Forgive me if this is silly question/statement, but the adj/alt
names etc are in the naptan dataset. Wouldn’t it be better to have
the link made between the stop in OSM and the record in naptan
(using the codes prior mentioned).
My thinking is data consumers could link and retrieve values using
that. Merging the extra data values again might potentially
develop discrepancies over time.

I’d think the atco code is unique and (hopefully) not reused, but
the alt names etc could be modified over time.


A perfectly valid question and something I wonder also.

For example, the indicator field is somewhat meaningless to a data 
consumer unless they know what it represents as per the NaPTAN schema 
- so perhaps it's best left out of the OSM data?


FWIW I did actually append that to name when displaying those because it 
"looked useful" (to append to the name and distinguish between other 
identically named stops):


https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L5010

As to the original question "Would there be any objections to an import 
of the following scope" - certainly not from me.  I wouldn't personally 
use the PTv2 "platform" tag but its presence doesn't break anything.


The most interesting bit would be the "Manually conflate and review the 
data before upload using JOSM" - any JOSM CSS style that you end up 
using to highlight duplicates would be really useful, as would a basic 
OSM diary entry describing the process and the end result.


Best Regards,

Andy




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

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Ed Loach]

Stuart wrote:

> Even more so in bus stations. The name Derby Bus Station (actually 
> just "Bus Station” in the locality of Derby) applies equally to all 29 
> bays in the bus station. “Bay 1” through “Bay 29” are the indicators.

Agreed this is useful when adding the stops for the mapper, but unless we are 
going to keep updating the naptan information fields as well as the OSM fields, 
isn't the naptancode (or atcocode) sufficient to check the latest information? 
Take for example this bus stop, imported ages ago:
https://www.openstreetmap.org/node/474893182#map=19/51.88949/0.89687&layers=T
It has "naptan:Indicator"="Stop T" but "local_ref"="Fa" which might well be in 
the naptan indicator field now, but for a local mapper they are more likely to 
update local_ref to what is signposted when it changes than look at the naptan 
fields. And I don't think "opp" or "adj" belong in local ref.

What has been useful when adding routes is stop bearing, but again I can check 
this in NaPTAN data from the reference - it should be obvious in OSM from 
looking at the map. However I did find a few sections of very roughly traced 
roads that were the wrong side of the stops when I was creating the route 
relations, which I used the stop bearing and aerial imagery to sort out. 

Also, I suspect some latitudes and longitudes have been refined in NaPTAN since 
stops were first imported. I was creating one route where the stops showed as 
in the middle, or behind, the buildings fronting the road.

Ed


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Silent Spike]

On Fri, Jul 5, 2019 at 1:33 PM Stuart Reynolds <
stu...@travelinesoutheast.org.uk> wrote:

> what did you have in mind? To the end-user of the data (i.e. someone
> wanting to know about where to catch the bus) this is absolutely critical.
>
> For example, in my previous post I face a suggestion of “Stuart Close”
> with an indicator of “adj”. There would usually be a second stop of the
> same common name, Stuart Close, perhaps with the indicator “opp”. Without
> understanding the NaPTAN schema, “app Stuart Close” and “adj Stuart Close”
> are understandable and are service direction dependent.
>

Well I was just thinking they're often descriptive abbreviations (and
admittedly aren't hard to deduce) with limited possible values as per the
NaPTAN schema. However, if it's just following the NaPTAN schema is there a
point in including it in OSM if that data is available and more up to date
there? While tags such as the stop name have corresponding tags in OSM
which have use to consumers who are not strictly following the NaPTAN
schema.

I'm certainly not against it's inclusion and would defer to your opinion
that it's useful data.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Stuart Reynolds]

If you wanted to conflate indicator and common name into the OSM “name” field, 
then I can provide a list of what we call “prefix indicators” as opposed to 
“suffix indicators”. It’s fairly self-explanatory, as prefix indicators are 
generally those that are positional e.g. o/s, opp, adj, nr etc. For example, 
Stuart Close / opp -> “opp Stuart Close", whereas the suffix ones are not e.g. 
Bus Station / Bay 8 -> "Bus Station (Bay 8)”

Regards,
Stuart Reynolds
for traveline south east and anglia

On 5 Jul 2019, at 13:40, Andy Townsend 
mailto:ajt1...@gmail.com>> wrote:

On 05/07/2019 13:19, Silent Spike wrote:
On Fri, Jul 5, 2019 at 1:02 PM Gareth L 
mailto:o...@live.co.uk>> wrote:
Forgive me if this is silly question/statement, but the adj/alt names etc are 
in the naptan dataset. Wouldn’t it be better to have the link made between the 
stop in OSM and the record in naptan (using the codes prior mentioned).
My thinking is data consumers could link and retrieve values using that. 
Merging the extra data values again might potentially develop discrepancies 
over time.

I’d think the atco code is unique and (hopefully) not reused, but the alt names 
etc could be modified over time.

A perfectly valid question and something I wonder also.

For example, the indicator field is somewhat meaningless to a data consumer 
unless they know what it represents as per the NaPTAN schema - so perhaps it's 
best left out of the OSM data?

FWIW I did actually append that to name when displaying those because it 
"looked useful" (to append to the name and distinguish between other 
identically named stops):

https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L5010

As to the original question "Would there be any objections to an import of the 
following scope" - certainly not from me.  I wouldn't personally use the PTv2 
"platform" tag but its presence doesn't break anything.

The most interesting bit would be the "Manually conflate and review the data 
before upload using JOSM" - any JOSM CSS style that you end up using to 
highlight duplicates would be really useful, as would a basic OSM diary entry 
describing the process and the end result.

Best Regards,

Andy



___
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] Importing NaPTAN Data [Thread 2]

[Ed Loach]

I wrote:

> https://www.openstreetmap.org/node/474893182#map=19/51.889
> 49/0.89687&layers=T
> It has "naptan:Indicator"="Stop T" but "local_ref"="Fa" which might
> well be in the naptan indicator field now

Perhaps a better example would be further along the road at
https://www.openstreetmap.org/node/474893183
where neither the current local_ref or name are in the imported but dated 
naptan fields.

Ed


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Silent Spike]

On Fri, Jul 5, 2019 at 1:41 PM Andy Townsend  wrote:

> The most interesting bit would be the "Manually conflate and review the
> data before upload using JOSM" - any JOSM CSS style that you end up using
> to highlight duplicates would be really useful, as would a basic OSM diary
> entry describing the process and the end result.
>

Would be happy to write an entry about my process if it comes to fruition.
I suspect it won't be as interesting as you might imagine since there's
really not a huge existing coverage of stops in the area. However, anything
to help future mappers also interested in this available data.

By downloading only bus stops in JOSM from the overpass API can easily see
where duplicates exist just by proximity to the NaPTAN stops. Have
considered expanding my script to also assist in conflation (marking
possible duplicates for manual review before upload), but for the Aberdeen
area it's probably not worth it.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Silent Spike]

On Fri, Jul 5, 2019 at 8:04 AM Silent Spike 
wrote:

> Using the following established tags:
>

After all discussion so far I would update the list of tags to import as
follows:

   - `highway=bus_stop`
   - `public_transport=platform`
   - `bus=yes`
   - `name` [Imported - defer to existing tagging during conflation]
   - `naptan:AtcoCode` [Imported]
   - `naptan:NaptanCode` [Imported]
   - `naptan:CommonName` [Imported - should match `name` but may differ, is
   what the indicator is relative to]
   - `naptan:Indicator` [Imported - useful to distinguish stops and
   sometimes can be `loc_ref` data]
   - `naptan:verified=no` [Gets deleted upon verification according to the
   wiki]


I've checked and none of the stops here have Gaelic names (`name:gd`) -
though my script now supports them for import anyway. I also feel like
`source=naptan` is unnecessary since `naptan:verified` is basically the
same thing and the changeset(s) can have a source tag.

I'm trying to keep the amount of data somewhat minimal in line with the
following quote from the imports guidelines wiki page:

> However, don't go overboard with metadata. OSM is only interested in what
> is verifiable . This
> doesn't include (for example) foreign keys from another database, unless
> those are absolutely necessary for maintaining the data in future. Your
> data source may have many many fields, but OSM data elements with many many
> tags can be difficult to work with. Strike a balance. Figure out (discuss!)
> what fields the OSM community are interested in.
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb