Hi, I have reverted the name tag here changeset/190416433

Hello,

Thanks, and fair enough — that page does say what you say it does, and I hadn't given it enough weight. I take the point that there's guidance behind you and that some areas have gone that way.

Where I've ended up is that neither source survives being applied mechanically. Liverpool is a good example of NaPTAN itself holding poor data: stops like node/533861420 are name=WOODEND AVE/SHAW LANE, imported straight from the common name in capitals, while the same record carries naptan:ShortCommonName=Woodend Av/Shaw Ln in proper case — so NaPTAN doesn't even agree with itself. Nobody would argue for shouting a stop's name just because that's what the field says.

So I'm happy to leave things where they are. I won't go through and rename anything further, and I'd rather the wider community settled the pattern than the two of us settling Gloucestershire between us — the forum thread seems the right place for that. I'll keep updating the rest of the NaPTAN tags if they are missing or need updating in general.

Thanks for the kind words about the routes, and for taking the time over this.

Ryan

Hello,

I've looked at the Queens Court pair properly, and I think they cut the other way.

Both platforms are naptan:CommonName=Queens Court. Queens Court is the residential road joining Queen's Road right by the stops, so NaPTAN has named them after the joining road, as stop names usually do, while the NW stop has used the road they stand on. That's the less useful of the two: Queen's Road also carries the Cheltenham Spa Railway Station stops, so "Queen's Road" covers three platforms in two places, whereas "Queens Court" points at one junction. The other side, node/11143130705, has been "Queens Court" since 2023 and through a number of mappers' edits, which suggests the plain name has been reading fine for people.

On the prefix, the stops just east of here show the problem: "Lansdown, after Eldorado Road" and "Lansdown, outside Homespa House" sit alongside "Cheltenham, opposite Lansdown Walk" — so the prefix flips to Cheltenham for a stop that's named after Lansdown Walk, next to its Lansdown-prefixed neighbours. The indicators in the same handful of stops run after, near, adjacent, outside, opposite, by and before, which reads to me like a field describing where a stop sits rather than part of its name. I also don't think anyone local uses the long form — people say Queens Court or Eldorado Road, not "Lansdown, after Eldorado Road". That version is how the timetable system assembles NaPTAN's locality, indicator and common name for print.

The NaPTAN tag mappings page maps naptan:CommonName straight to name, with naptan:Street kept separately and the indicator going to local_ref where it's a bay or stand number. It doesn't describe joining those fields into one name, which matches how these stops have been tagged for years.

Where I agree with you is that a real difference between flag and database shouldn't vanish. I'd avoid local_name, since that's for what people actually call a place and this is the sign generator using the street field, but alt_name=Queen's Road on the NW platform records it and keeps it searchable.

And you're right that bus_display_name isn't it. Nothing established covers "the text on the flag", which is probably the real gap here — worth raising on the thread, and I'd back a signed_name-style tag.

Thanks, Ryan

Hello, Thanks for getting in touch. I'd read the stop as two separate parts: "UP HATHERLEY" is the locality heading, and the stop line is "opposite Village Hall", which is the indicator plus the stop name. The comma-joined form on the timetable is how the timetable system puts together NaPTAN's locality, indicator and common name, so I don't think it's a separate name. The stop is called Village Hall, in Up Hatherley, on the opposite side of the Hall.

It's also not what anyone local would call it. People would say they're getting off at Village Hall, not at "Up Hatherley, opposite Village Hall". The long form only exists on printed timetables.

Keeping name=Village Hall means both platforms match their stop area, and "before"/"after" stays in naptan:Indicator. I wouldn't use alt_name, since nobody uses the long form as a name. If you want the sign text recorded, the bus_display_name idea from the forum thread would fit better.

Thanks, Ryan

Afternoon,

I wasn't aware of this tagging scheme. I have updated the markers here (changeset/187942730).

Thanks, Ryan

Hello,

The node was updated to a Beefeater in changeset #146263214, my update simply changes it from a pub to restaurant, as all Beefeaters are. This was checked via their website (https://www.beefeater.co.uk/en-gb/locations/cheshire/springwood-park).

The note should have been closed 2 years ago when the original change was made.

Thanks, Ryan

No worries, I have replaced the name with the ref which is visible.

I have changed the capacity & sockets to 1. It's a bit misleading as the front facing as both a "A" and "B" side to it.

See changeset/185925859

No problem, we all start somewhere. The wiki is a great place to help ensure things are tagged correctly.

One slight note is could you square the buildings by using "Q", this just makes them look much better.

Hi,

There is no issue with garages being spilt up for separate houses, I haven't modified any of these.

We don't tag addresses on garages as this duplicates data already tagged on the house, therefore I have removed these. Some garages might have URPNs, in which case they can be tagged.

Thanks, Ryan

Hey,

Thanks for doing this, I was meant to exclude it from my script but forgot.

Ryan

Thanks, I have corrected this here changeset/177185677

Thanks for spotting this. I have added them here changeset/174745210 . Thanks, Ryan

Thanks for bringing this to my attention. Turns out my keybind got overridden so I assumed I was copying the history when I wasn't. Going forward it will be correct.

I have re-added the missing stream names (changeset/174694794) and gone back over my last 2 months of edits to ensure I have got them all. If I have missed any please let me know, Ryan.

Thanks for bringing this to my attention. Turns out my keybind got overridden so I assumed I was copying the history when I wasn't. Going forward it will be correct.

I have also added flowlines and re-added the missing stream names (changeset/174694794). If I have missed any please let me know, Ryan.

You're right, I've added it back into the relation here changeset/163781977

My bad, I seam to have copied the tag from my other computer wrong. I see you have corrected it, thanks.

Hey, you’re right looks like I made a mistake there, I should have corrected it in changeset/154669305