Because housenumber is not subordinate to housename, so the house name becomes something like a terraced subsection of the street with its own little name. Indeed, "For UK addresses **the house name will appear before any house number when the address is written out on an envelope (and after any unit number)**" -- osm.wiki/Addresses_in_the_United_Kingdom

I don't think we want that, but avoiding it with substreet is clumsy, true. If you want the number appearing before the building name, like

133 Peacock House
Baynhams Drive
[...]

they have to be addr:flats or addr:unit.

Of course, we can't do the addr:interpolation trick with at that level - it only interpolates addr:housenumber and nothing else.

Peacock house is quite illustrative, by the way. Even the ground floor apartments at the back with their own doors, overlooking the lake, have their letterboxes inside the common lobby at the street front. They too are subordinate to the building despite being much more house-like in character.

I'd be happiest with the following, I think:

```
addr:unit=123b
addr:housename=Peacock House
addr:street=Baynhams Drive
addr:suburb=Wolvercote
addr:city=Oxford
```

which formats the way we want it, as:

```
123b Peacock House
Baynhams Drive
Wolvercote
Oxford
```

Good plan? There's nothing saying that streets can't have gaps in their addr:housenumber runs, or that flat/unit numbers have to start at 1! Nor anything that the one sequence can't take over from the other for a bit.

That was fast! I can confirm that it's an ST6, from memory.

What's your source for this information, OOI?

The extra detail is handy for Peacock House, which has the previously missing 123s and 125s around its edge, plus an entrance lobby with the mail slots for all of them.

Trying addr:interpolation on the main entrance nodes since JOSM isn't whining about overlap between Gatekeeper House and Comma House. It feels less bad than putting it on a closed way with no addressed nodes in it!

We'll see what the search makes of it all.

→ changeset/153011576

A few of those examples could probably do with a review tbh., and a close check against of osm.wiki/Addresses_in_the_United_Kingdom. My bad.

OK, quick Q: does it appear on envelopes as

77 Baynhams Drive
Hawk House
[Wolvercote]
OXFORD

or

77 Hawk House
Baynhams Drive
[Wolvercote]
OXFORD

or something even weirder?

I think the addr:interpolation really needed to be removed from the building outline. addr:interpolation is just not allowed on closed ways, and is meaningless without nodes on it containing addresses.

Although, IMO, an interpolation is needed for big apartment blocks sometimes because there can be absolutely loads of addresses, and it'd be hellish to do them with comma-separated addr:flats or addr:housenumber.

-------------------8<------------------

So how to do it right? The best way might be to tie it down to entrance locations, one way or another. That's kinda meaningful to users because it tells you where to walk and/or what doorbell to ring straight away:

- osm.org/?mlat=51.77122&mlon=-1.21397#map=19/51.77122/-1.21397 (lots of addresses per entrance, so use an interpolation)

- or osm.org/?mlat=51.76531&mlon=-1.20268#map=19/51.76531/-1.20268 (only 3 addresses per entrance, so comma-separated is fine)

- the even wackier situation with Cavalier Court, where there's different continuous runs on different levels, presumably corridors: way/129003603#map=19/51.76858/-1.22687&layers=D

addr:*s are ultimately just an attempt to physically locate the delivery endpoint, however it's done.

Oh drat. Have I been doing this all wrong?

I may have made the same mistake a few times locally. Sorry. Am I just imagining that it used to be good practice to tag the real-world stop lines before the traffic signals abstraction?

I'm hoping I find the time to repair it. I've bookmarked https://overpass-turbo.eu/s/1M87 now for my own QA purposes, and I'll get on with fixing them (but feel free to dive in!)

See also:

https://bustimes.org/services/14-oxford-city-centre-john-radcliffe-hospital#map

https://www.oxfordbus.co.uk/services/SCOX/14

Ah, no problem. It happens.

This is a very large area, across multiple countries. Please keep your edits a little smaller and more self-contained, thanks!

You have a claimed Street View source, and I understand from a different changeset you mean Google Street View. We cannot use this data if that's the only source. Please have a read of osm.wiki/Copyright, and kindly remove any information that cannot be represented here without violating copyright. *Independently* verifying information you receive using satellite imagery available within the editor here may be fine, but you need to say exactly where you got the data so it can be checked, if necessary.

If you just want to flag an error so that local mappers can visit and check out the location, you can use the Map Notes layer from the sidebar, and (right button) → Leave a note here.

Happy mapping and/or bugreporting (from acceptable sources)!

You are not permitted to use (solely) Google Streetview information, or any other proprietary information. Real life knowledge covering the same thing independently is fine, though, so it sounds like customer info sourced data wins here!

Info: osm.wiki/Copyright

No problem! My choice of tag on the day was a guess, so let's try this next change as a slight improvement...

It's labelled on the ground as "Doctor", and near a health facility (though the building offers lots of other things too). Going with "staff" for now, but it can be refined if needed.

This is a public car park, not a health facility, assuming you mean the staff_count:doctors in osm.wiki/Global_Healthsites_Mapping_Project

I will tag the relevant parking space (and the others, *sigh*) using parking_space=*

Bah. "11X", not "X11"!

Anyway, the rel is fine. Surprised it doesn't stop at the P&R.

Replaced with relation/16507614

↑ specifically, the curved section to the S of the Churchill Hospital probably isn't used in either direction

Forgot to add: OBC now reckon this from the Atkinson Close stop in Barton, where the loop diverges. That's a sensible place for OSM to start too, I guess.

I've done the few stops the route has in that order, and made things continuous out for a bit from there.

Done. Thanks.

eep. That's useful info, thank you.

Would you mind adding a reminder about this relation to osm.wiki/Oxford as well, with a description of where the info came from, and how it ought to be maintained? Thanks!

This commit is over 3 years old. Practice may have moved on.

Which shop node are we talking about here? Well, I guess only M&S is that big....

The node or area we are using to represent the "shopness" of M&S should be located nearer Queen Street than Pembroke Street, to respect where the main entrance is. Perhaps it could sensibly be moved closer to Queen Street?

I somewhat disagree with the official docs,
osm.wiki/One_feature,_one_OSM_element , in that I prefer usage-elements like shop=* to float within building-elements because a) sometimes the extent and ownership of a building isn't immediately obvious from satellite & other sources, and b) sometimes buildings get knocked-through or subdivided or otherwise change usage patterns over time. **The general pattern is sound though**, and helps prevent over-mapping (i.e. the same thing being mapped with multiple different schemata).

I think relations are never for grouping, and mappers' groupings are going to vary. There are a handful of controlled uses of relations, stick to those.

It is fine to put a shop=* node inside a building outline. Remember that the OSM database is geographical - physical withinness is inherently testable for the practical purposes that the vast majority of map users put their maps to.

It is fine to put a shop=* tag on a building outline, but less expressive.

Suggest "topshop?" → "Topshop" nearby.

Suggest verifying "Size?" nearby - the quiestion mark looks dubious in the name, and I suspect it is not part of the shop's name.