Importing NaPTAN Data

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Importing NaPTAN Data

Silent Spike
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb


_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Importing NaPTAN Data

TonyS
In reply to this post by Silent Spike

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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb

_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Importing NaPTAN Data

Silent Spike
In reply to this post by Stuart Reynolds
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb


_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Importing NaPTAN Data

Silent Spike
In reply to this post by TonyS
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 <[hidden email]> 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 list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb

_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Importing NaPTAN Data

David Woolley
In reply to this post by Silent Spike
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Importing NaPTAN Data

Silent Spike
On Tue, Jul 2, 2019 at 10:00 AM David Woolley <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb

_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Importing NaPTAN Data

Ed Loach-2
In reply to this post by David Woolley
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Importing NaPTAN Data

Silent Spike
On Tue, Jul 2, 2019 at 11:07 AM Ed Loach <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb

_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Importing NaPTAN Data

Brian Prangle-2
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 <[hidden email]> wrote:
On Tue, Jul 2, 2019 at 11:07 AM Ed Loach <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb

_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Importing NaPTAN Data

Great Britain mailing list
In reply to this post by Ed Loach-2

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
> [hidden email]
> https://lists.openstreetmap.org/listinfo/talk-gb


_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Importing NaPTAN Data

Brian Prangle-2
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 <[hidden email]> 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
> [hidden email]
> https://lists.openstreetmap.org/listinfo/talk-gb


_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb

_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Importing NaPTAN Data

Martin Wynne
In reply to this post by Great Britain mailing list
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Importing NaPTAN Data

Silent Spike
In reply to this post by Great Britain mailing list
On Thu, Jul 4, 2019 at 4:10 PM Dave F via Talk-GB <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb

_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Importing NaPTAN Data

Silent Spike
In reply to this post by Martin Wynne
On Thu, Jul 4, 2019 at 4:40 PM Martin Wynne <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb

_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Importing NaPTAN Data

Andy Townsend
In reply to this post by Martin Wynne
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Importing NaPTAN Data

Mateusz Konieczny-3
In reply to this post by Great Britain mailing list


4 lip 2019, 17:11 od [hidden email]:

In OSM we map *physical* objects only.
What about border - especially 
lower administrative units and 
nature reserves?

_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Importing NaPTAN Data

Great Britain mailing list
In reply to this post by Martin Wynne
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb

_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Importing NaPTAN Data

Great Britain mailing list
In reply to this post by Silent Spike


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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
12