[Tagging] interpolated housenumbers on single objects

[Will Phillips]

I often use the addr:interpolation tag on entrances or buildings. I 
don't understand some people's objection to this. I don't see any 
ambiguity: if the addr:interpolation tag is present the addr:housenumber 
tag represents a range, otherwise it should be interpreted as a single 
address. As someone who maps addresses regularly I find this a quick and 
convenient way to do it. All the alternatives are either cumbersome for 
the mapper, or are hacky, because they involve putting addresses at 
arbitrary positions within a building.

I find that by far the most time consuming part of surveying house 
numbers is actually adding the data afterwards and for this reason I 
think we should be trying to make the tagging quick and straightforward 
for mappers wherever possible. To me restricting the use of 
addr:interpolation seems an unnecessary rule that makes things more 
difficult. Additionally, we should avoid making it unnecessarily 
complicated for mappers to add useful information. For example, if 
numbers 20 to 40 on a street are accessed through a particular door, I 
want to tag that explicitly, because it's useful for routing and 
accessibility. Advocating tagging that forces me instead to stick the 
addresses at an arbitrary position within the building outline is unhelpful.

The proposed Node relation mentioned by Janko Mihelic is I think a 
useful idea for certain situations. For example, I've encountered cases 
where addresses accessed through a single door have more than one 
postcode, so can't be accurately represented on a single node. These 
relations would allow all the addresses to be associated with the 
entrance. However, I'm not convinced it's a good solution for simpler 
cases because making mappers create separate nodes for all the numbers 
in a range and then linking them together with a relation seems 
over-complicated.

The wiki documentation for using addr:interpolation on single objects 
has been changed several times. As Dan noted, the current version 
recommends against it. A few months ago I reinstated an earlier version 
that recognised and briefly explained this usage, but it was removed by 
a user who wrote it was ambiguous, but they didn't really explain why 
they thought it so. I propose adding it again.