Да, как-то я и не подумал про “когда надо”.
is_in, кажется, не нужен. Интересно, зачем его добавили.
Нарисовалась идея плагина к джосму, кот будет менеджить адресные отношения. То есть показывать всю иерархию в открытом файле OSM, иметь инструменты создания улиц и, возможно, конвертировать между стандартами адресации. :3
Я могу ответить на вопрос, зачем адрес строится снизу вверх. Пусть мы хотим загрузить маленький кусочек Москвы в редактор. Тогда вместе с ним у нас будет загружено отношение “Москва”, ссылающееся на 3681 (результат bzgrep 77000000000 street.csv.bz2 |wc -l) улицу. При необходимости мы можем через API получить все улицы Москвы. Для Минска это: http://www.openstreetmap.org/browse/relation/79847 и http://api.openstreetmap.org/api/0.6/relation/79847/relations
Ничего не понял. Это ответ на что? Снизу вверх - это is_in? Зачем он нужен?
Да ладно. Я вообще думаю, что лучше оставить за нодами и веями геометрию, а вся фактическая инфа пусть лучше в релейшенах содержится. И вей — это вовсе лишь урезанный вид релейшена, с безымянными мемберами и их одним их типом (ноды). 
А вот насчёт того, что is_in — вывернутая идеология — в принципе можно согласиться. Обычно указывают на член более низкий в иерархии. Хотя и обратные примеры есть (система категорий в Медиавики, к примеру). Впрочем, если есть вохможность быстро ходить по отношениям и в ту, и в другую сторону, это не имеет принципиального значения, т. к. a.is_in(b) эквивалентно b.contains(a)
Я эту мысль независимо проталкивал в ирке, но никто не внял :3
Провел эксперимент. Внес свой дом в два адресных отношения - по улице и по комплексу.
Результат можно посмотреть здесь. Можно перейти в любой релейшен, а с него - на любой другой дом.
Единственный минус - при просмотре адресного релейшена не видны номера домов, а только иды объектов.
Update:
Еще минус - при включении релейшена дома в адресный релейшен он не подсвечивается на карте, но перейти на него можно.
Update2:
Вывел эти отношения по иерархии в address Челны. Так что никаких проблем с иерархией и уровнями вложенности.
А я тебе скажу, зачем его добавили. Добавили его затем, что пока мы оперируем понятием ‘база’, ‘выборка из базы’, то всё получается. Но как только мы переходим к Геометрии, к физическому отображению, то у любого программиста, реализующего это всё, и видящего, какие объемы информации надо перекопатить (та же трассировка точки на принадлежность контуру), что сразу возникает желание сделать себе ‘предварительный расчет’, заготовку прямо в базе (по сути - подпорку) - и логически обосновать ее необходимость То есть, вся проблема is_in’a в отсутствии строгой иерархии вложенности объектов осм. Которая (иерархия) напрашивается именно для плоскостного, геометрического отображения данных базы (сиречь создание карты).
Идея незримого главенства котэ в осм засчитана
На самом деле, если будет одна адресация, то и никакой плаг не понадобится, поддержка ТАКОЙ адресации будет частью редактора. По идее…
Чем лично мне не нравится белорусская схема:
coolkaas, почему нереально?
То есть? Как можно её учитывать?
Один объект на местности — один в базе. Ничего избыточного.
Оккам скорее переворачивается от схемы Karlsruhe, c кучей повторяющихся по сотне раз тегов addr:street, addr:region, addr:country…
Примеры?
Получается, человек должен до этого дойти сам.
Например, естественная пространственная вложенность.
Схему-то почитай
Там к каждому одному объекту на местности добавляется ещё один объект: “адрес объекта”.
Пример классический - куда сельсоветы пихать?
Очевидно, не работающая на обрезанных дампах. И не будем тыкать пальцем в скорость выборки
Простите? Добавляется релейшен на адрес только в случае, когда у контура адресов несколько. Если он там один, то адрес (номер дома) остаётся на вее.
Пример почтового адреса, включающий сельсовет?
Komяpa, в России полно деревень, названия которых повторяются внутри района - тогда сельсовет включается в адрес. В КЛАДР-е они так и обозначены: Новая (Еласовский с/с), Новая (Троицко-Посадский с/с)
Что касается адреса на вее, как к вею мембер is_in назначить? Адресация-то снизу.
Дак а как это решает проблему двух адресов у здания?
А понял, housenumbers = addr:streetnumbers - указывает на то под каким атрибутом прячется номер дома под которым он входит в улицу, только это ни разу не айс, и вот почему:
Для жилишьных комплексов еще работает но для нумерации угловых домов в городе вам понадобиться для каждой улицы вводить свое (уникальное в рамках города) значение тэга housenumbers что не удобно, прежде всего по тому что очень не универсально.
is_in используется как раз для того чтобы не формировать для каждой улицы уникальное имя тэга показывающего под каким номером дом входит в улицу.
P.S. Что на счет избыточности: хотим сократить объем данных - избавляемся от избыточности, хотим сократить количество вычислений - вводим избыточность.
Для этого в любом случае нужен какой-то костыль. Либо просто включить как дополнительный уровень адресации, но с пометкой (какой-нибудь тег), что использовать только при коллизиях.
Ну вот единственное что и мне не нравится.
Не путайте адресацию с административным подчинением.
dkiselev, если у дома один адрес - ничего на него плодить не нужно, просто включить с ролью house в улицу. Если больше одного - делаются отношения на каждый адрес с включением их в нужные улицы. Всё на самом деле не так сложно.
Адрес объекта — это тоже объект. Причём он может даже не соответствовать ничему материальному, например «владение» с номером, которое является просто куском территории.
Кстати, тот же вопрос про внутригородские районы: в Москве, например, есть четыре улицы 8 марта.
И если “в любом случае нужен какой-то костыль” - это УЖЕ не универсальная схема.
Vovanium, кусок территории - вполне себе материальный объект 
И ещё: в адресе используют не с/с (не смотрите в КЛАДР, это вредно), а п/о, а оно не обязано совпадать с с/с. Пример: с/с с/п Погореловка (КЛАДР 4002500009900) получает почту через п/о Крюково (КЛАДР 4002500005700).