41

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

42

IMHO тремя уровнями иерархии не обойтись. Ведь надо, чтобы было все по человечески и легко проверяемо.
Возникают вопросы к “адрес НП внутри страны” - сколько НП будет в таком релейшене? Как его проверять? Как его поддерживать?
Аналогично и по “адрес владения/дома внутри НП” - сколько там домов внутри той же Москвы? Размер такого релейшена трудно представить…

Таки 5 уровней более приемлемо и контролируемо.
Дома собираются в улицы, улицы в НП, НП в районы/ГО, районы/ГО в регионы, регионы в страну. Объем одного релейшена на каждом уровне не сильно большой и вполне поддается проверке и модификации.
Разберу на своем доме (Челны - ГО, поэтому отнес к уровню 3):
(1) дом 2 по бульвару 60 лет Октября, (3) в г.Наб.Челны, (4) в РТ, (5) в России.
или
(1) дом 7/09 [в 7ом комплексе], (2) в Новом городе, (3) в г.Наб.Челны, (4) в РТ, (5) в России.
Такая схема позволит получать полный адрес объекта последовательным соединением полей name (кроме дома, где вместо name берется addr:housenumber/addr:streetnumber или еще какой number).

43

Во-первых, три уровня - это базовые уровни. Они есть всегда и без них не обойтись.
Иногда их достаточно трёх: Россия, г. Зеленоград, к100.
Иногда гораздо больше: в адрес могут при необходимости включаться и регион, и муниципальный район, и сельсовет, и городской район, и улицы, и микрорайоны, и ещё фиг знает что. Но всегда половина адреса будет описывать НП внутри страны, а другая половина - дом внутри НП.

Во-вторых, не надо смешивать адресацию (НП) с административным делением (ГО). Это совершенно разные и слабо связанные вещи.
И не надо упираться в релейшены, на них свет клином не сошёлся. Первична задача, а не средства. :slight_smile:

44

Ну вот вы сразу круто спорить взялись, с количеством уровней… Щас все испортите :slight_smile: Давайте сперва про улицы с домами договоримся?
Взять тот же street, добавить (хотя бы по варианту ikz) возможность включить один дом в два отношения…

45

А номера как указывать?

46

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

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

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

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

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

47

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

48

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

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

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

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

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

49

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

50

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

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

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

51

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

52

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

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

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

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

53

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

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

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

54

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

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

55

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

56

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

57

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

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

58

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

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

59

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

60

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