street/associatedStreet еще не самые сложные отношения - address-отношения куда круче http://www.openstreetmap.org/browse/relation/81777
И всё таки с его помощью замапили пол Минска.
Дублирования данных кстати тоже не удалось избежать, но там необходимость дублирования наверняка имеет какое-то “правильное” обоснование
А на второй половине поняли беспреспективность? или устали?
Судя по http://www.openstreetmap.org/browse/relation/79847 хватило на 1303 улицы, наверное это даже больше половины.
Но вот на Брест уже не хватило энтузиазма: http://www.openstreetmap.org/browse/relation/79955 – только 25 
Наверное осознали что кроме пяти-десяти человек никто это поддерживать не будет.
очень оптимистично 
ну, я думаю, тут не младенцы картинки рисуют. Если есть желание мапить, то человек почитает форумы, вики, задаст вопросы и разберётся.
Хотя, гм… Белорусская схема адресации действительно сложная. Украинская попроще будет.
схема адресации не украинская, а Karlsruhe, описанная в принятом пропозале от 2008-31-12 и поддерживается хотя бы частью инструментов, хотя бы тем же Nominatim-ом.
и вообще, что за двойные стандарты? адресное отношение - очень сложно и непонятно для новичков, а мультиполигоны рисовать на полстраны - нормально.
Мультиполигоны тоже ничуть не нормально 
Если вспомнить о сущности отношений как они есть, то это объект OSM, показывающий, как относится объект(ы) к другому.
В идеальном мире каждый объект, имеющий адрес, должен иметь отношение, показывающее, что данный объект относится к такой-то адресной группе (улице, кварталу, …).
То есть, каждый дом, каждый магазин в нем, каждая сущность, имеющая адрес, должна иметь такое отношение.
А редакторы должны всё это удобно показывать.
Отношения - правильно и нормально … но не с нашими инструментами. Это как сказать что автомобиль это хорошо и купить ВАЗ-2101.
Да, поэтому сейчас я всеми лапами за addr:, addr2: и далее.
Хотя мне не нравится слитное написание номера, это уже сложившаяся практика. Я бы сделал addr[2], например.
А если вешать точки на сам полигон? На стороны, параллельные адресным улицам или на самые приближенные к ним точки. Каковы очевидные недостатки такого метода?
Эскиз, чтобы было легче понять:
Сам я скептичен по поводу такого варианта, но любознательность не даёт пройти мимо.
Дык на угловые легче тогда, дабы не плодить лишних точек (на примере - карлова сделать на левом нижнем, воскресенскую на правом верхнем - близость к улицам сохранена)
Бинго, настоящие адреса остались на правильном месте, и если принять во внимание вечный зов “осм - не карта”, то все правильно: навигатор ведет к адресу, для которого наличие полигона building не обязательно (поправьте, ежели ошибаюсь)
Человек поедет не к полигону, а к адресу.
Другое дело, что новичок может наляпать еще один адрес с дробью на здание, вот тут уже веселуха
Короче. Предлагаю пользоваться addr:, addr2:, …, addrn:* и не ругаться. Схема проста, дуракоустойчива, достаточно интуитивно понятна (увидел раз — можешь делать так же), конвертируема.
Знает. Читайте раздел «угловые дома».
Ну тогда было бы неплохо задействовать addrN в конвертерах по полной программе. Сейчас только Навител (если не ошибаюсь) использует addr и addr2.
Легко могу обеспечить по addr4 включительно
Alpha version of indoor mapping visualization:
http://dotevo.geowebhost.pl/osmpoi/# Slowly and with bugs but the main idea is visible.
Changing between levels is there possible. Elevators and steps as well.
Please inform, when You have such mapped areas (like shopping centres etc…).
Не получится. Напомню, что проблема была не столько с угловыми домами, сколько в том, на каком языке писать addr:street, чтобы никого не обидеть. Это одна из причин, по которой в Украине была принята система адресации с использованием релейшенов. Дом имеет только addr:housenumber и привязан к отрезкам улицы с помощью релейшена. При этом улица может иметь кучу названий на разных языках name:xx и не иметь name. При таком способе адресации дом в адресном поиске никуда не денется.