Вот даже всю тему читать не охота, хотя стоит. Вот вам аргумент для street-отношений, что б не заносили в каждый дом тег wikipedia= … → гляньте на страницу (внимание! Хунта не дремлет!) (к примеру) [улица Артема](http://uk.wikipedia.org/wiki/Вулиця Артема (Донецьк)), и нажмите на кнопку глобуса викиминиатласа или ‘показать карту’… И решайте чего оно стоит - связывать все обьекты улицы через названия на каждом обекте, или все обьекты группировать по общем!.у названию единой сущеости.
Если есть подобные примеры ‘на костылях’ приведите, интересна сложность их реализации.
“Литеры” в Москве - это чисто инвентаризационная штука, к адресам не имеющая ни малейшего отношения: https://wiki.openstreetmap.org/wiki/RU:Addresses#.D0.9B.D0.B8.D1.82.D0.B5.D1.80.D0.B0.D1.86.D0.B8.D1.8F_.D0.B4.D0.BE.D0.BC.D0.BE.D0.B2_.D0.B2_.D0.A0.D0.BE.D1.81.D1.81.D0.B8.D0.B8
Возможно. Поэтому и говорю, что аналог литеры там называется “строение”. Документ именно про нумерацию московских строений имелся в виду. Хотя грань между инвентаризацией и адресацией довольно хрупка. Литеры СПб - это тоже не почтовый адрес, а скорее учетно-инвентаризационный.
Ребята, что касатся двойных (и более)) адресов копайте в сторону отношений! Они все єто позволяют! Хотя схему тегирования элементов отношений есть смысл, и потенциал, расширить.
Есть затык у отношений - где на доме указать эти два номера дома и как их соотнести с нужным отношением улицы.
Надо признать, что для однозначной привязки адресных точек ко всем «адресуемым» объектам — лучшего способа, чем отношение, не придумаешь.
associatedStreet увязывает линии дорог-улиц с уже адресованными объектами (street+house). Оно не решает проблемы «мультиадреса» у объекта или кучи объектов с одинаковым адресом (который может быть ещё и «мульти»).
Требуется отношение вроде associatedAddress, в котором будут address+object. Само отношение не будет нести никаких тегов, а станет тем каркасом и фильтром, который снимет обязательность (но не желательность!) геометрической привязки и всяческие другие неоднозначности и лишние операции.
«Принято» бояться отношений, но страшного ничего нет и многое (если не всё) становится на свои места.
Так почему бы не воспользоваться хорошим «инструментом» в виде relation type=associatedAddress?
Оно, в свою очередь, может (но не обязано!) — по аналогии с мастер-маршрутами — быть включено в associatedStreet в роли house, и никто не уйдёт обиженным. 
Описано пока что только на украинском:
http://wiki.openstreetmap.org/wiki/Uk:%D0%90%D0%B4%D1%80%D0%B5%D1%81%D0%B0%D1%86%D1%96%D1%8F#.D0.91.D1.83.D0.B4.D1.96.D0.B2.D0.BB.D1.96_.D0.B7_.D0.BA.D1.96.D0.BB.D1.8C.D0.BA.D0.BE.D0.BC.D0.B0_.D0.B0.D0.B4.D1.80.D0.B5.D1.81.D0.B0.D0.BC.D0.B8
К сожалению не увидел ответа, может дашь ссылку на реальный пример?
Контур дома http://www.openstreetmap.org/way/239569335 включён в отношение улицы http://www.openstreetmap.org/relation/3556573 ;
адресная точка внутри этого дома http://www.openstreetmap.org/node/2702822803 включена в отношение другой улицы http://www.openstreetmap.org/relation/3556570
Этот способ привязывает только саму адресную точку и контур дома (как замечено выше). А где решение по поводу
?
Ведь упирается вся эта кухня в точечные POI. Кстати, associatedStreet в показанном примере по сути ничего не меняет. И без этого отношения будут спокойно отыскиваться и точка, и контур дома по соответствующим адресным запросам (только улицу надо, как сейчас, прописывать, конечно).
А поменять картинку должен associatedAddress, где будет всё красиво и просто.
Вот сделал вандальную правку для дома сугубо примера наглядного ради. Просьба к Эдуарду: после ознакомления сжечь откатить, чтобы никто не волновался.
А ежели понравится — так оставляйте, будет почин. 
На случай, если Эдуард поспешит с откатом, создал в своей вотчине (сам и прослежу) предлагаемое отношение. Обратите внимание, что оно является дочерним по отношению к associatedStreet, которое создал попутно. С этим вовсе не обязательно заморачиваться, делал только для примера.
В данном примере можно добавлять сколько угодно адресных точек, включаемых в отношение и автоматически «адресующих» все объекты (от контура здания, до POI), а впоследствии легко и просто добавлять сколько угодно POI с тем же эффектом.
Несколько примечаний.
-
Адресные тэги проставлены и на здание, и на адресную точку. Дублирование, что есть нехорошо. Рекормендую в таких случаях вообще не создавать адресную точку, а здание с проставленным адресом включать в отношение дважды: один раз с ролью object (чтобы показать адресуемый объект), второй раз с ролью address (показать, что именно отсюда следует брать адрес).
-
Зачем нам это труднопроизносимое в camel-Case-стиле тэгирование – “associatedAddress”? Давайте назовём тип отношения просто “address”. Несколько раз набирал “associatedAddress”, пальцы запутывались в клавишах каждый раз.
У меня Список населенных мест еще не дошел пока до POI, но домики и выше именно так и переносят addr:* и вверх родительскому объекту (то, что там уместно и не заполнено), и вниз дочернему (если там чего-то не хватает в явно указанном). То есть, если на домике указано addr:country=RU, то всем охватывающим родителям при случае, припишут addr:country=RU (или получат конфликт. если там уже указанно другое).
Дублирование получилось из-за того, что не стал удалять адресные теги со здания (но в чистом виде — надо бы). Адресные точки, по мне — удобнее, нагляднее, интуитивнее, универсальнее.
Название придумал по аналогии, отношение и по функционалу схожее и в чистом переводе соответствует смысловой нагрузке, опять же. А набирать каждый раз не надо, потом можно копировать или JOSM сам подставляет ранее набранное. А может быть в плагин relation toolbox Илья добавит? (тогда — только выбрать из списка).
Есть ли у кого возражения/замечания?
Хи-хи! Это в духе relation первого созыва, когда отношение было пустым, а теги брались с одного из членов.
Опять клятая совместимость?
Что по мне, так геометрическое включение в здание уже есть некое отношение (заданное геометрически, а не отдельно)
И совместимость, и простота, и достаточная необходимость. Геометрическое включение не отменяется и одно другому не мешает, а дополняет (отношение скрепляет однозначно то, что надо и устраняет много нюансов и сложностей, о которых мне тут говорили в процессе обсуждения). Кто посчитает более простым использовать геометрическую вложенность, вместо учёта отношений — будет иметь такую возможность, не вижу препятствий.
Будет ли конструктивная критика предложения? Если нет, то — конструктивная поддержка? Чтобы не получалось так, как обычно: «да, хорошо всё и правильно, только это никому не нужно (читай: никто не будет этим заниматься)»
Ну какая тут критика, и так очевидно оверхерт отношений, да ещё дублирующих геометрическую связь. Причём точка на стене не сильно большой даёт выигрыш по сравнению с отрезком одноименной улицы, рендеры поворачивающие номер дома к улице передают вам привет.
А в данном случае по-другому и не получится. Пока, к сожалению, нельзя назначить тэги на роль — можно только на отношение или на входящие в него сущности.
Поэтому для многоадресных зданий придется включать в отношение несколько объектов с ролью «address» (будь это адресная точка или контур самого объекта) — по одному для каждого адреса.
Я, честно, офигеваю с такого подхода (мягко говоря). Вы же собственнолично выше приводили кучу примеров, когда геометрический подход имеет слабости и есть сложность в корректном определении адреса. Когда было предложено на него не полагаться (хотя и не исключать!), а прибегнуть к однозначному тегированию адресной информации, вы начинаете какие-то страшные слова приводить и ныть про «дублирование геометрической связи». При чём здесь «точки на стене и рендеры, передающие приветы»? Пример смотрите (Эдуард не откатывал его ещё).
Вот это и есть «и так, и этак нам хреново (а чего хотим-то?), пусть будет та лажа, что и сейчас, лишь бы нихрена не делать». Заведомо тупиковый подход. И похоже, что он преобладает в сообществе (и не только OSM). Видимо поэтому за 10 лет не смогли ничего вразумительного придумать по адресации.