Talk:NaPTAN/Tag mappings

How to locate bus stops

Looking at the mapping information there is not a lon/lat position (or any other coordinates). The name of the street is given with some local landmark or another street crossing. How is any automated process going to place a bus stop in the right place? Is this only going to be useful for adding the NaPTAN info to existing stops, which could then be used for bus routes, timetabling, joined up transport routing etc. Chillly 13:21, 20 January 2009 (UTC)

There are, I merely omitted (some of) the obvious locational details that are present in the XML. --Thomas Wood 16:49, 20 January 2009 (UTC)

Using NaPTAN data to map blank or incomplete areas

It seems that if you view the Naptan data merely a list of points with associated street names then it would be helpful for general mapping. For example, locating a new road by its bus stops if surrounding roads are traced from Yahoo or NPE, adding street names to such traced areas with many no-names, spotting misaligned roads, detecting unmapped areas by comparing number of ways to number of bus stops (or proximity of stops to a way) and so on. I see discussion about more advanced transit routing activities but is there any work going on in that direction?

None as yet, but it'd be an awesome thing to do. I think we should concentrate on this kind of thing more when we're post-processing the data after we've done the preliminary import. --Thomas Wood 12:12, 27 January 2009 (UTC)

Special Points to Consider with the Schema

The schema seems to be particularly nasty in places - be careful when handling:

• Descriptor elements, don't just do a simple check for the subelements, make sure AlternativeDescriptors are recognised.
• StopAreas, this node has two uses, one as a second-level container of StopArea elements, the other use to contain StopAreaRefs on a StopPoint.
• In some places (TfLondon stops particularly), ref=* should be set to the Indicator element, rather than the NaptanCode. Other regions will have to be checked by hand to see what the best approach for filling ref=* should be.

--Thomas Wood 00:45, 15 February 2009 (UTC)

Offset

Please note the difference of meaning of "Offstreet" in NAPTAN and OSM. In NAPTAN it means a stop on some dedicated bus lane in contrast to "on a normally trafficed road". That said, a highway=bus_stop should ALWAYS be a node on a way. --Gerrit 16:19, 19 February 2009 (UTC)

s/on a way/near to the side of a way/, and there's no reason why highway ways may not run through a bus station. --Thomas Wood 01:26, 20 February 2009 (UTC)

So, you say NAPTAN stops are besides the road? Of course highway ways may run through bus stations. I don't understand what you are getting at here. --Gerrit 08:43, 20 February 2009 (UTC)

The current standard tagging for highway=bus_stop is as a node beside the way. --Thomas Wood 14:28, 20 February 2009 (UTC)

I know. But it isn't always done like that and it's opposite to the rail-bound public transport tagging. NAPTAN also seems to have the stop on the road. With the platform in my scheme the information from current mainstream bus_stop-tagging would be preserved. --Gerrit 18:17, 20 February 2009 (UTC)

Unified StopAreas

I'd like to point you to a proposal regarding bus/tram/train/... stops I developed. It seems to fit the NAPTAN-Model quite well. --Gerrit 16:19, 19 February 2009 (UTC)

I was considering on looking at this proposal when I start to implement StopAreas. I'm going to ignore the (in my opinion) pointless highway=platform tagging (not that NAPTAN provides that level of detail). I also disagree with over-generalisation of relations, I think it'd be good to use a specialised transit stoparea relation rather than a site one. Yes, both are technically correct, I'd like the relation to be more transit-specific in this case. --Thomas Wood 01:26, 20 February 2009 (UTC)

Why do you think its pointless? We need a topological representation of the stop (bus_stop as part of the road) and a geographical one (the platform besides the road).

I'd vote to integrate NAPTAN into OSM, not the other way around. Meaning: We choose a tagging which makes sense in the OSM-context, while the NAPTAN model may have a different purpose. Putting stop_area inside the site hierarchy has some advantages. For example: All "site" relation share the common characteristic that they group a couple of elements in a roughly circular area which in many purposes (e.g. lower zoom levels) appear as one entity. Same is true for routes, which also share some common characteristics between them (route=hiking, route=bus, route=ferry,...) --Gerrit 08:43, 20 February 2009 (UTC)

My apologies for being so obtuse regarding this proposal. To be honest, I hadn't fully read it, I've now looked into it more and am implementing it in the converter. --Thomas Wood 08:59, 28 February 2009 (UTC)

OSM is not a database dump.

As OSM is not a database dump, the only tag required within OSM is a reference back to the Naptan database. Similar to other external databases Naptan is maintained /much/ more accurately & frequently by the authorities responsible than it is in OSM by Naptan contributors.--DaveF63 (talk) 19:56, 25 February 2023 (UTC)