An explicit, optional spatial container defining the verifiable area that is one specific address. Inner features inherit the address unless they carry a different tagged address.
Please discuss this proposal on its wiki talk page.
1 Like
“There is no top-level feature” - as mentioned on the other thread, standalone addr: tags ARE top-level feature
5 Likes
Mikołaja Kopernika 26, Kraków: church + university library + retail bookshop
and based on what boundary=address would be drawn there? How it could be verifiably surveyed? What it would add over existing tagging?
(it so happens that I cycled there hundreds, maybe thousands of times)
2 Likes
This is addressed in the first section of the proposal. Please discuss the proposal on the discussion page, not here.
I cannot survey the whole perimeter via Street View alone, but there seem to be quite clear walls, fences, etc.
Mikołaja Kopernika 26 itself, not just some of the buildings in it.
That’s really cool! Amazing coincidence :D
1 Like
but this does not necessarily delineate addressable area (in fact, based on survey there, I have no idea what is the extent of addressable area there)
it sits on East-West cycling route going through city center (there are other East-West routes, but this one is superior to almost all of them, and to all of going through city center)
I’ll change the section title to “Examples of areas where existing tags wouldn’t work”. I didn’t go as far as checking if each area’s address extent is verifiable, just that it can’t be all covered by a landuse, plot or amenity.
As a side note, is it just me, or is the “Please discuss this proposal on its wiki talk page” boilerplate the single most routinely ignored guidance anywhere on the wiki? We can’t fault any proposer for taking that line seriously, but I can’t think of a time when a proposer refused to engage with discussion elsewhere, whether here or on the tagging mailing list (RIP). So I guess don’t feel like you have to ignore the feedback you get here because it’s technically out of place. 
12 Likes
The rationale for this proposal touches on some themes that we debated last year as well. Apparently there’s also an object:*=* scheme for saying that some piece of street furniture is associated with a certain address but only secondarily, not as the main assignee.
1 Like
I hope you’re not suggesting that you’re mapping via Google StreetView, as it’s use in OSM is strictly forbidden.
5 Likes
Putting aside whether it even makes sense to map “address extents” directly in OSM (in your country it may, in Australia it makes more sense to conflate with cadastral data outside of OSM) - for a lot of the examples you’ve listed it isn’t clear how mapping address areas like this actually benefits the database.
With the example of Way: Asklepios Klinik Barmbek (32803835) | OpenStreetMap and Way: Kindertagesstätte Rübennasen (120300390) | OpenStreetMap, in my opinion wrapping an area around both features is completely redundant. Given both the hospital and kindergarten are POIs, they would still most likely be tagged with an address. Therefore, if data consumers wanted to ask where “Rübenkamp 220” applies, wouldn’t an explicit address boundary be functionally equivalent to just dissolving those two areas?
With your example of Way: 15c Podmiejska (193956288) | OpenStreetMap and Way: Cemex - Wytwórnia Betonu Towarowego (521939413) | OpenStreetMap - why do we need to be explicit with boundary=address?
In situations like this, there is no benefit to mapping an address boundary explicitly. This only creates a maintenance burden for mappers, similar to how associatedStreet expects mappers to manually maintain a “feature ↔ street” relationship that is functionally redundant with addr:street (or with this proposal, a “feature ↔ address” relationship that is functionally redundant with addr:*).
I’m not saying this proposal is therefore bad, there are some use cases where I can see something like this being useful - but I don’t think you’ll get much support for it when a lot of the examples appear to create more work for mappers with very little benefit.
7 Likes
The thing is that it seems like everyone with feedback here hasn’t read the proposal. The requirement to at least open the page would filter away a lot of arguments to respond to that the proposal already addresses, and would compile all the feedback into one place where it would be more clear whether the concerns have been resolved or not.
It’s insane how everything I say is twisted into the worst possible interpretation. I’m responding to Mateusz that I can’t tell where the address would do but that you could probably see it in real life.
2 Likes
addr:* expects mappers to maintain a feature ↔ street relationship that is functionally redundant with boundary=address. If the address of a place changes, you’d have to update every addressed object inside it. How is that not more comparable to associatedStreet than a single boundary way defining the address?
having the address explicitly on the feature is very clear, simple and stable, if you are filtering data by type of thing, you get automatically the address on the features you selected, with no processing required (to get addresses from enclosing objects) and no risk of someone inadvertently changing the address by slightly moving things.
2 Likes
Inferring features from containing polygon is a standard thing that geocoders like Nominatim precompute, but I agree that it is trading simplicity (of computation) for elegance.
I canceled the proposal since everyone hates it
2 Likes
Thanks for this well-written proposal, with lots of examples.
That said, it’s a clear no for me:
-
This would require extra work from mappers, keeping address boundaries in sync when reshaping the objects inside them
-
Having the address tag directly on an object saves data consumers from running a spatial query to discover a potential address boundary
-
From a data storage standpoint, duplicated address tags are much cheaper than storing an extra polygon
2 Likes
Maybe?, but when you say “I cannot survey the whole perimeter via Street View alone” that immediately rings alarm bells! 
4 Likes