Собственно, а почему бы на отношение тоже не ставить addr:housenumber?
Имхо, так было бы логичнее.
Там есть и другие нелогичные вещи, поэтому я вместо address:тип= решил ставить name=.
Мне непонятно: почему номер владения надо называть HOUSEnumber?
На отношение лучше ref, ибо это самый настоящий ref.
Можно пойти ещё дальше и группировать дома с разными корпусами (что логично, имхо),
Кстати, это ведь решение для нескольких номеров у одного дома, не?
dimuzz, именно для нескольких адресов и делается отношение house.
Я и не говорю что сложно, если у дома 1 адрес - понятно что ничего не меняем.
Я вот этого не понял:
Делаются отношения на каждый адрес с включением их в нужные улицы.
Покажите на примере если не сложно.
(В общем то если я вас правильно понял, то я только за 
)
Что-то я подумал… Действительно, странно видеть у адреса в Part of: его части, а в Members — то, частью чего он является…
Конечно странно… Но броузинг отношений на сайте не предназначен для просмотра адресных отношений или автобусных маршрутов. Вместо этого нужны другие инструменты. Например: http://stat.latlon.org/by/latest/addr/79847.html
Интересно тогда, для чего он предназначен…
Итак, по результатам дискуссии:
- нужен способ группировки адресов в улицу. Я лично склоняюсь к этому пропозалу, хотя про теги можно ещё подумать.
- нужен способ задания альтернативного адреса. Тут белорусская схема сама по себе хороша, но мне не нравятся кривые теги. Так что предлагаю пока такие:
type=address:house (или просто house?)
addr:housenumber=<номер>
контур включается с любой ролью.
На выходных попробую частично добавить в конвертер.
А это не про решение для угловых домов. Это решение для двух адресных схем, существующих параллельно.
Для угловых домов было выше.
Ищите выше. Если вкратце, то для угловых домов включаем релейшен, в котором прописан нужный тег и включен полигон дома в качестве boundary.
Ну вот и попытайтесь через is_in включить один дом в две разных улицы, да еще с разными номерами. Не получится.
Кривые тэги никто не мешает переименовать в нормальные, если этому будет аргументированное объяснение.
Мне тоже не нравятся кривые теги. А адрес с номером имеют не только дома. Поэтому house не катит.
А можно ссылочку на готовый пример? Ну хоть один дом оформленный. Для наглядности…
Эта разные адреса. Разные схемы.
А решение для 3 и более адресов здесь уже приводилось.
В чем жесть-то? В одной макроподстановке? В интепретируемых языках это вообще делается одним оператором.
Hint: я сам программист и использовал подобные трюки.
у меня так улицы все заделаны, именно через чистый street, так что я – за. (я ведь и выбирал в своё время ЭТОТ пропозал для себя, как близкий “духовно”)))
Только раньше там было роль дома address, а сейчас address/house – какой в каком случае? Теперь не address писать, а house, да?
может просто address? у нас двоеточие означает подтип тега, address:house → тип тега address, подтип (расширение) house. А тут вроде не этот случай. Хотя бы через подчёркивание, что ли))
Тип отношения – Адрес. Пойдёт? так чисто как и по-русски произносить. type=address. Или мы что-то еще смысловое вкладываем в это отношение?
с любой ролью, это кажется хорошо.
Ну вот, сделал для примера.
http://www.openstreetmap.org/browse/relation/418770
На конкретных тегах не настаиваю, но надо с чего-то начать
Ничивинипонял 
А Трубную улицу как из этого отношения вывести? И что включать в отношение street? и как понять, он 26 по Сухаревскому и 1 по Трубной или наоборот???
У меня получился такой вариант. Чем-то придется расширять отношение house, иначе сразу не понятно, куда он выведет.