Hey Dave, thanks for letting me know. Seems I forgot to set the repository as public, Should now be visible!

Good question. You’re right that the NaPTAN data has a status field which should be set to del when a stop is physically removed.

For this import I simply filtered those out and focused on additive importing as I think to delete a feature it should be confirmed on the ground that the feature is gone. I’m told the status field is sometimes misused to mark inactive stops as del when they still have a physical presence.

I did encounter a single stop which had a naptan:AtcoCode which didn’t match anything during conflation (so I believe the stop must have been marked deleted in NaPTAN). However, I left it where it was for the above reasoning.

On the flip side, I did come across four stops with the opposite issue. I’m often in this area and know there aren’t stops here, but the NaPTAN data still had them present (believe they must be from before the road was redeveloped). I decided to leave them in and then just remove the bus stop tagging from them and add a note on why they’re there. This way, if a re-import were to occur the nodes can be matched by their naptan:AtcoCode and not be mistakenly re-added as bus stops. Hopefully the NaPTAN data will be eventually updated to reflect what’s on the ground - I’m not sure if there’s a way to flag things for correction in the dataset.

I should have said in my original comment:

This is a great post! I’ve recently become interested in updating and fixing the bus routes in my area and also found that the wiki pages were not very succinct. My understanding matches yours and it seems much more approachable presented like it is here.

I’m also “guilty” of double tagging bus stops and areas of grass for the renderer as I don’t think it’s a big deal for these specific cases because both tags do reflect what is on the ground. It’s just good for newer editors to be aware of why they’re adding tags (i.e. the highway=bus_stop tag isn’t actually needed for PTv2, it’s just generally added because it renders).

Hey Warin,

I don’t think the bus route "platform" members actually need the highway=bus_stop tag, people just commonly double tag that because public_transport=platform is not yet rendered in the standard OSM map layer.

You may want to make this clear as technically it’s tagging for the renderer.

Very pleased to see the beginnings of Q/A support in iD!

I make heavy use of KeepRight, Osmose and OSM Inspector and think making such tools more accessible is very valuable to new users.

The main weakness I foresee in showing Q/A tool messages in iD is that most currently aren’t very enlightening in regards to how to correct the issue. For example, in the image above a totally new user might be led to believe a junction node is necessary, but it could be that one highway is a bridge/tunnel that’s improperly mapped. Hopefully most users would realise this and then investigate how to tag the feature appropriately, but in future I’d love to see more verbose descriptions that cover possible causes and how to correct them (even linking the appropriate wiki pages).

The reason I mention this is that I’ve ran into it myself, KeepRight’s almost junction warning made me think I had to move the end of one way further from another and it wasn’t until I started using Osmose later that I found out about the noexit tag.