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.
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
