Proposal talk:AssociatedAddress

no relation necessary

I would map this situation - multiple POIs have the same address, but not all POIs in the building have the same address - by simply using the same set of addr:* tags on several POIs. Mapping it that way is easier than using a relation (especially for inexperienced mappers, I assume), and the data can still be clearly understood by other mappers and applications. --Tordanik 20:43, 24 April 2011 (BST)

of course you can do that, but redundancy should be avoided by all means and this relations solves the 1% of cases where it wasn't possible now. inexperienced mappers wouldn't touch situations like that anyway, so i'm not considering this an argument against relations. relations are one of the three cornerstones of the OSM data model and should be treated equaly to nodes and ways/areas. imagine an office building with two addresses and 50 companies inside it. how should renderers handle situations like that? draw the two house numbers 25 times each inside the buildings boundary? or navigation programs for blind people: when they enter an address, they should preferable be routed to the correct entrance, that is why you should map the address once to the entrance node if possible and not spread it all over the map. --Flaimo 22:35, 24 April 2011 (BST)

I happen to disagree with your principle that "redundancy should be avoided by all means" in the context of OSM tagging, is not supported by practical arguments. I also fundamentally disagree with the statement that relations play a similar role in the data model as ways and nodes. They may be similar if you look at databases or XML files. However, OSM tagging needs to serve the needs of human mappers using graphical editing tools. And unlike nodes and ways, relations in general allow no intuitive generic visualization. I believe that this disadvantage makes avoiding unnecessary relations an important priority for new tagging concepts.

About your application examples: A renderer should obviously not draw the same house number multiple times just because there are multiple nodes with the same house number tag. Similarly, it also shouldn't draw a street name more or less frequently just because I split the street way into several segments. Yes, it's easier for the renderer if there is only one house number node. But not only does (imo) easier editing outweigh easier use by applications, whether it's actually easier to use also depends on the application: a single address node might make things easier for renderers, but makes them harder for an application that lets me click on POIs to bring up the address.

Oh, and I don't understand why you bring up navigation for the blind. What they need is the entrance that lets them physically access their point of interest - i.e. they need Relations/Proposed/Associated Entrance. --Tordanik 23:15, 24 April 2011 (BST)

type=site

Isn't it already possible with the site relation?--vsandre 09:45, 28 April 2011 (BST)

would only work if the site would have only one address. m:n connections won't work with a site relation --Flaimo 13:29, 28 April 2011 (BST)

Relations are overkill

Redundant information is not bad. It is good. It helps with finding problems in the data. Relations make using the data much more difficult as everybody who has actually implemented code following relations can tell you. Chances are this proposal will never be actually implemented by people who actually use the address information, because it adds a huge amount of complexity for little gain in just a few corner cases. Joto 08:00, 2 May 2011 (BST)

Spelling: associated_address instead of associatedAddress

Following the standard OSM spelling rules, the relation should be called type=associated_address or simply type=address. Yes, I know that associatedStreet exists, but that is pretty much the one exception from the rule. No reason to repeat that mistake. --Tordanik 11:09, 7 March 2016 (UTC)