Обсуждаем способы задать адресацию

Я сначала хотел настроить бота на релейшены, но, во-первых, это сложнее, а во-вторых создает конфликт человек - робот.
Робот не совершенен, и поэтому позволять ему править за человеком рискованно. Настроить его на внесение/исправление техничесокй информации - вполне нормально.

Предполагается, что кладр-код периодически проверяется ботом на соответствие тэгу addr:street.

По правде говоря, не уловил, в чем принципиальная особенность. И в Москве таких домов предостаточно. Да хотя бы взять те же угловые здания.
Во всех этих случаях вариант адресации по кладр-коду реализуем. Можно н/р указывать

addr:street=Московский проспект
addr:housenumber=159
addr:street2=56-й комплекс
addr:housenumber2=14
addr:street3=Набережные Челны
addr:housenumber3=56/14
...

Это, конечно, пока только предложение.
2-й вариант предложил ViVish на форуме Покетгиса: обводить в таких случаях контуры зданий несколько раз и указывать для каждого контура свой адрес. ИМХО, довольно топорный вариант, но зато работает уже сейчас без переделки конвертеров.

Не хотеть такого. Это то же самое, что жестко захардкодить элементы массива в отдельные переменные. Думаю, многие программисты со мной согласятся. :3

liosha, ну я то взял за основу почтовый адрес, в котором идет (почти) именно такое разделение.

Еще один интересный момент. Кол-во уровней нужно только в том случае, если делать единственный, универсальный релейшен для любого уровня иерархии. Минус в том, что такой релейшен будет перегруженным, сложным для составления и валидации.

Есть предложение сделать несколько различных релейшенов для разных целей:
streetaddress для сбора домов в улицы; districtaddress для сбора в районы; settlementaddress для сбора в НП; regionaddress для региона. Момент в том, что disctrictaddress и settlementaddress можно включать друг в друга в любой последовательности, что дает любой уровень иерархии.

Фактически же, у нас есть уже несколько используемых релейшенов, которые легко можно приспособить под адресацию для уровней начиная с районов. Достаточно вспомнить, что вся Россия собрана в collection “Административное деление России”, в котором есть ссылки на все регионы. Такие же collection с районами есть по многим регионам, осталось в районах собрать collection с НП, а в НП - с улицами. Промежуточных collection можно собрать сколько угодно. Так что достаточно решить во что и как собирать улицы с домами :slight_smile:

ПыСы. А в collection можно добавить необязательный тег postal_name и при разворачивании цепочки у нас выстроится полный адрес.

В случае нашей схемы - на контуре дома оставляется только информация для рендерера (типа address:housenumber=107/38)
На отдельные адреса делаются релейшены, в которых пишется адрес и в который включается контур.
Дальше каждый из этих релейшенов идёт своим путём, как отдельный объект.

(про нижнюю часть иерархии: улица-дом)
Да, единственная накладка – это двойные адреса. На вскидку хочется тогда вытащить с дома номер как-то в само отношение street, а на доме оставить только buildig=yes. Но это слишком нереально))

“addr:street3, addr:housenumber3” – тоже весьма пугает…

Остаётся не очень прочувствованная мной Котярная схема с отношениями И на адреса, в которые (как-то?) включается контур дома. Котяра, с какой ролью сам билдинг включается в отношение адреса?

А она документирована где-нибудь? Интересно посмотреть :3

Если хочется иметь возможность двойной адресации то без родителя не обойтись. addr:street в купе с addr:housenumber это ни что иное как ссылка на родителя с атрибутом под каким номером ребенок входит в состав родителя.

Для того чтобы привязать дом к двум улицам (либо к улице и НП) под разными номерами в любом случае требуется отношение вида is_in с указанием номера. (addr:street с addr:housenumber - это лишь вариант реализации такого отношения).

Релейшен, который просто группирует все здания относящиеся к одной улице, новых возможностей по построению иерархии адресов не дает. В общем к чему я все это: если хочется использовать двойную аддресацию или пропускать уровни адресной иерархии то основных варианта два: релейшен is_in и addr:street2.

is_in мне как то поприятнее в силу его универсальности.

http://www.openstreetmap.org/browse/way/25426285 - классический пример.

Как видно, по API можно лазать по адресам что вверх, что вниз.

http://sites.google.com/site/osmbelarus/Home/manuals/osm-manual/osm-manuals-address - собственно, описание схемы.

А мне нравится схема Котяры. Все равно в релейшен улицы будут включаться релейшены сложносоставных (типа с внутренними дворами) зданий.
Получается, что релейшен улицы включает в себя релейшены с номерами домов и ссылками на контур. Это решает любые проблемы с двойной-тройной адресацией.

Единственное предложение, не обзывать это улицей. Т.к. адресация не всегда основана на улице.

Если уж продолжать идею адресной иерархии, то самым нижним отношением, должен быть номер дома, в которое включен контур дома (да, а если контуров несколько? такие извращения встречаются) и is_in с отношением улицы, площади или другого верхнего уровня. Кстати, зачем вообще считать и эти уровни? Просто берём адрес, и последовательно включаем в is_in его элементы. Сколько элементов — столько уровней в данном конкретном случае.
Да и для почтовых индексов тоже можно релейшн сделать подобный (включающий, например, почтамт, родительский (районный?) почтамт)

http://wiki.openstreetmap.org/wiki/Relations/Multipolygon
Мультиполигон - тоже контур.

Включить в качестве контура не полигон, а мультиполигон.

Мне не совсем нравится идея с is_in.
По крайней мере в той ссылке, что выкладывал Котяра, я, перейдя с дома на улицу, не смог перейти на другие дома этой улицы:
кликаем на 173380, видим Челюскинцев, 13, кликаем на Челюскинцев (81850). Все. Никаких домов не видим.
По идее улица включает в себя дома, а не дома указывают, что они находятся на улице.
А еще у is_in развернутая логика. Находясь на той же Челюскинцев (81850) мы видим, что в участниках Минск, т.е. не улица “участвует в” городе, а наоборот, город в улице… Как-то это не совсем правильно.

Что-то мне не нравится идея создавать релейшн на каждый адресуемый объект. Попахивает удвоением сущностей, хотя нельзя не признать логичность подхода.

Удалился размышлять

Hind, для домов нужно только для тех, у кого больше одного адреса. Остальное не так страшно.

Hind, а если не на каждый, а только на ‘когда это надо’? То есть, всегда улица ссылается на дом, и только в редком (всё же редком) случае организуется ‘прослойка’ отношение адреса, для случая много-адресных домов. То есть, это будет штатный выверт. И пложения сущностей не будет. Мне тоже эта лишняя прослойка на каждый дом - не нравится.
И в общем случае мне тоже близка мысль ikz, что это не обязательно улица, но любое нужное и логичное образование. Но как правило - улица.
И я бы тоже попытался обойтись в схеме без is_in как ссылки на родителя, путем наличия собственно участия ребенка (дома) в отношении Улица. Is_in ведь тоже удвоение сущностей в базе.

Да, как-то я и не подумал про “когда надо”.

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? Зачем он нужен?

Да ладно. Я вообще думаю, что лучше оставить за нодами и веями геометрию, а вся фактическая инфа пусть лучше в релейшенах содержится. И вей — это вовсе лишь урезанный вид релейшена, с безымянными мемберами и их одним их типом (ноды). :slight_smile:

А вот насчёт того, что is_in — вывернутая идеология — в принципе можно согласиться. Обычно указывают на член более низкий в иерархии. Хотя и обратные примеры есть (система категорий в Медиавики, к примеру). Впрочем, если есть вохможность быстро ходить по отношениям и в ту, и в другую сторону, это не имеет принципиального значения, т. к. a.is_in(b) эквивалентно b.contains(a)

Я эту мысль независимо проталкивал в ирке, но никто не внял :3