Talk:NaPTAN/Surveying and Merging NaPTAN and OSM data

Moving Stops using aerial imagery

Is it OK to move a bus stop if I can see from the aerial photography that it's slightly off? OliverLondon 11:23, 18 August 2009 (UTC)

Procedure for Merging

I've changed the procedure for merging today after looking at some discussions on talk groups. Its been done with the aim of getting the ball rolling, and I hope it gets edited and improved --Jamicu 13:33, 8 September 2009 (UTC)

kerb=raised

As brought up in the talk-gb mailing list, I think we should be marking the raised kerbs used to aid accessibility as kerb=raised.

See http://www.flickr.com/photos/pobice/3925707792/ for an example of a raised kerb.

I did suggest wheelchair=yes, but as pointed out in the thread, the kerbs don't just aid wheelchair access, plus its hard to verify if all buses serving the stop will have a low floor. --Pobice 09:46, 21 September 2009 (UTC)

Physically Present ambiguity

RE: "Do NOT add a highway=bus_stop tag, or delete the existing highway=bus_stop tag"

I assume it is best to remove the highway=bus_stop tag for stops that don't exist, since these shouldn't appear on rendered maps. I have seen several customary NaPTAN bus stops without the highway=bus_stop indicating this sort of use. The above phrasing though is ambiguous. Shouldn't it just be "Remove the highway=bus_stop tag (if present)" ?

--Pinkduck 16:28, 16 November 2009 (UTC)

I agree. Could be clearer.

I think maybe in some areas, or at an earlier stage some NaPTAN nodes were imported without the highway=bus_stop tag, and procedure then was to add the tag. ...maybe -- Harry Wood 17:09, 16 November 2009 (UTC)

Resolved: seems that this is nowadays resolved Mateusz Konieczny (talk) 10:01, 4 September 2020 (UTC)

Relations for groups of stops

The NaPTAN inport has introduced relations for groups of individual bus stops that are adjacent to each other and share the same name. However, these relations don't have a type attribute. Should we be thinking about a suitable 'type' to add? It seems that having that attribute is a common feature of all the other documented uses of Relations.

With this in mind, there's a proposal at Stop_area#Stop_.28Stop_Place.29_2 to use type=site and site=stop_area for such relations. There's also a more complicated proposal at Proposed_features/Stop_Place#Stop_Area which would use type=site and then either site=bus_stop or site=bus_station for bus stop grouping. Both agree on type=site, which fits into the broader Relations/Proposed/Site. Any thoughts?

-- Rjw62 21:12, 1 December 2009 (UTC)

http://wiki.openstreetmap.org/wiki/NaPTAN/Tag_mappings#StopArea states that site=stop_area should be used, with further tagging to identify the type of stop collection. -- Rjw62 20:11, 8 December 2009 (UTC)

Hail and Ride

Near me there is a section of bus route that is hail and ride. There do seem to be timetables, attached, to lamp posts, at or near most of the NapTAN nodes, but no stop sign and, whilst people will often congregate round one, when waiting for a bus, the bus will stop anywhere safe.

Should these be treated as present or not present? (There doesn't seem to be a mechanism for marking hail and ride sections, although one NapTAN stop, which doesn't even have a timetable, marks the end of the hail and ride section, and I suspect that some that do have time tables, mark the start.) -- Hadw (talk) 16:28, 18 August 2013 (UTC)

SMS Information Request Codes in London

London bus stops now seem to have a five digit or one letter and 4 digit code number to allow SMS enquiries about real time running times. These are not obviously derivable form the NaPTAN references. Is there any consensus as to whether these should be attached to the bus stop node, and, if so, what key should be used? -- Hadw (talk) 10:48, 19 August 2013 (UTC)

But smscode is a field in the NaPTAN data as a "NaPTANCode" field. ...and has been imported in 'ref' key.

SMS codes are generally five numeric digits in London (see the ref tag on this stop for example. Alphabetic elsewhere, but I thought NaPTAN had this empty in a lot of places where SMS codes is not available.

-- Harry Wood (talk) 13:03, 13 July 2016 (UTC)

Keeping nonexisting stops

"If a NaPTAN node is not physically present on the ground and you have no knowledge that it is used as a stop then: (...) Add a physically_present=no tag"

I think that such node should be simply deleted Mateusz Konieczny (talk) 10:01, 4 September 2020 (UTC)

By deleting highway=bus_stop the node is no longer a propper OSM named node. Osmose brings up an issue for this, namely: "Untagged named object".

If there is a desire to keep these nonexistent stops around for a while in OSM I think there should be active discussion as to how long to keep them.

Could someone explain the reasoning (and add it to the wiki page) as to why the recommended process is what it is? Coolmule0 (talk)