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

Hind · 2010-02-26 19:38:28

coolkaas wrote:

Котярная схема

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

dkiselev · 2010-02-26 19:46:41

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

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

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

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

Komяpa · 2010-02-26 20:00:41

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

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

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

Last edited by Komяpa (2010-02-26 20:04:37)

ikz · 2010-02-26 20:40:17

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

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

Vovanium · 2010-02-26 20:53:28

Hind wrote:

ImmortAlex wrote:
возможность включить один дом в два отношения...
А номера как указывать?

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

Komяpa · 2010-02-26 21:00:47

Vovanium wrote:

да, а если контуров несколько? такие извращения встречаются

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

ikz · 2010-02-26 21:01:46

Vovanium wrote:

да, а если контуров несколько? такие извращения встречаются

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

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

Last edited by ikz (2010-02-26 21:11:55)

Hind · 2010-02-26 21:50:07

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

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

Alexandr Zeinalov · 2010-02-26 21:53:06

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

coolkaas · 2010-02-26 22:05:38

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

Hind · 2010-02-26 22:08:58

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

is_in, кажется, не нужен. Интересно, зачем его добавили.

Нарисовалась идея плагина к джосму, кот будет менеджить адресные отношения. То есть показывать всю иерархию в открытом файле OSM, иметь инструменты создания улиц и, возможно, конвертировать между стандартами адресации. :3

Last edited by Hind (2010-02-26 22:14:42)

Alexandr Zeinalov · 2010-02-26 22:38:35

Я могу ответить на вопрос, зачем адрес строится снизу вверх. Пусть мы хотим загрузить маленький кусочек Москвы в редактор. Тогда вместе с ним у нас будет загружено отношение "Москва", ссылающееся на 3681 (результат bzgrep 77000000000 street.csv.bz2 |wc -l) улицу. При необходимости мы можем через API получить все улицы Москвы. Для Минска это: http://www.openstreetmap.org/browse/relation/79847 и http://api.openstreetmap.org/api/0.6/re … /relations

Hind · 2010-02-26 22:54:30

Ничего не понял. Это ответ на что? Снизу вверх - это is_in? Зачем он нужен?

Vovanium · 2010-02-27 00:32:42

Hind wrote:

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

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

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

Hind · 2010-02-27 01:39:35

Vovanium wrote:

вей — это вовсе лишь урезанный вид релейшена, с безымянными мемберами и их одним их типом (ноды)

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

ikz · 2010-02-27 06:09:57

Провел эксперимент. Внес свой дом в два адресных отношения - по улице и по комплексу.
Результат можно посмотреть здесь. Можно перейти в любой релейшен, а с него - на любой другой дом.
Единственный минус - при просмотре адресного релейшена не видны номера домов, а только иды объектов.

Update:
Еще минус - при включении релейшена дома в адресный релейшен он не подсвечивается на карте, но перейти на него можно.

Update2:
Вывел эти отношения по иерархии в address Челны. Так что никаких проблем с иерархией и уровнями вложенности.

Last edited by ikz (2010-02-27 07:29:53)

coolkaas · 2010-02-27 08:40:34

Hind wrote:

is_in, кажется, не нужен. Интересно, зачем его добавили.

А я тебе скажу, зачем его добавили. Добавили его затем, что пока мы оперируем понятием 'база', 'выборка из базы', то всё получается. Но как только мы переходим к Геометрии, к физическому отображению, то у любого программиста, реализующего это всё, и видящего, какие объемы информации надо перекопатить (та же трассировка точки на принадлежность контуру), что сразу возникает желание сделать себе 'предварительный расчет', заготовку прямо в базе (по сути - подпорку) - и логически обосновать ее необходимость То есть, вся проблема is_in'a в отсутствии строгой иерархии вложенности объектов осм. Которая (иерархия) напрашивается именно для плоскостного, геометрического отображения данных базы (сиречь создание карты).

Hind wrote:

Нарисовалась идея плагина к джосму, кот будет менеджить адресные отношения.

Идея незримого главенства котэ в осм засчитана
На самом деле, если будет одна адресация, то и никакой плаг не понадобится, поддержка ТАКОЙ адресации будет частью редактора. По идее..

liosha · 2010-02-27 08:59:23

Чем лично мне не нравится белорусская схема:
* во-первых, это голая иерархия, совершенно не учитвывающая гео-природу имеющихся данных.
* во-вторых, слишком много лишних сущностей - отдельный релейшен на КАЖДЫЙ объект. Оккам в гробу перевернётся.
* ну и в третьих, несмотря на сложность самой схемы, всё равно для некоторых адресов нужны будут костыли.

shadowjack · 2010-02-27 10:19:35

coolkaas, почему нереально?

Vovanium · 2010-02-27 10:22:39

liosha wrote:

Чем лично мне не нравится белорусская схема:
* во-первых, это голая иерархия, совершенно не учитвывающая гео-природу имеющихся данных.

То есть? Как можно её учитывать?

liosha wrote:

* во-вторых, слишком много лишних сущностей - отдельный релейшен на КАЖДЫЙ объект. Оккам в гробу перевернётся.

Один объект на местности — один в базе. Ничего избыточного.
Оккам скорее переворачивается от схемы Karlsruhe, c кучей повторяющихся по сотне раз тегов addr:street, addr:region, addr:country...

liosha wrote:

* ну и в третьих, несмотря на сложность самой схемы, всё равно для некоторых адресов нужны будут костыли.

Примеры?

Vovanium · 2010-02-27 10:23:34

Hind wrote:

Vovanium wrote:
вей — это вовсе лишь урезанный вид релейшена, с безымянными мемберами и их одним их типом (ноды)
Я эту мысль независимо проталкивал в ирке, но никто не внял :3

Получается, человек должен до этого дойти сам. :-)

liosha · 2010-02-27 10:29:20

Vovanium wrote:

liosha wrote:
* во-первых, это голая иерархия, совершенно не учитвывающая гео-природу имеющихся данных.
То есть? Как можно её учитывать?

Например, естественная пространственная вложенность.

Vovanium wrote:

liosha wrote:
* во-вторых, слишком много лишних сущностей - отдельный релейшен на КАЖДЫЙ объект. Оккам в гробу перевернётся.
Один объект на местности — один в базе. Ничего избыточного.

Схему-то почитай
Там к каждому одному объекту на местности добавляется ещё один объект: "адрес объекта".

Vovanium wrote:

Примеры?

Пример классический - куда сельсоветы пихать?

Komяpa · 2010-02-27 11:01:08

liosha wrote:

Например, естественная пространственная вложенность.

Очевидно, не работающая на обрезанных дампах. И не будем тыкать пальцем в скорость выборки

liosha wrote:

Vovanium wrote:
Один объект на местности — один в базе. Ничего избыточного.
Схему-то почитай
Там к каждому одному объекту на местности добавляется ещё один объект: "адрес объекта".

Простите? Добавляется релейшен на адрес только в случае, когда у контура адресов несколько. Если он там один, то адрес (номер дома) остаётся на вее.

liosha wrote:

Vovanium wrote:
Примеры?
Пример классический - куда сельсоветы пихать?

Пример почтового адреса, включающий сельсовет?

Last edited by Komяpa (2010-02-27 11:02:30)

liosha · 2010-02-27 11:08:20

Komяpa, в России полно деревень, названия которых повторяются внутри района - тогда сельсовет включается в адрес. В КЛАДР-е они так и обозначены: Новая (Еласовский с/с), Новая (Троицко-Посадский с/с)

Что касается адреса на вее, как к вею мембер is_in назначить? Адресация-то снизу.

dkiselev · 2010-02-27 11:19:22

ikz wrote:

Провел эксперимент. Внес свой дом в два адресных отношения - по улице и по комплексу.
Результат можно посмотреть здесь. Можно перейти в любой релейшен, а с него - на любой другой дом.
Единственный минус - при просмотре адресного релейшена не видны номера домов, а только иды объектов.

Дак а как это решает проблему двух адресов у здания?

А понял, housenumbers = addr:streetnumbers - указывает на то под каким атрибутом прячется номер дома под которым он входит в улицу, только это ни разу не айс, и вот почему:

Для жилишьных комплексов еще работает но для нумерации угловых домов в городе вам понадобиться для каждой улицы вводить свое (уникальное в рамках города) значение тэга housenumbers что не удобно, прежде всего по тому что очень не универсально.

is_in используется как раз для того чтобы не формировать для каждой улицы уникальное имя тэга показывающего под каким номером дом входит в улицу.

P.S. Что на счет избыточности: хотим сократить объем данных - избавляемся от избыточности, хотим сократить количество вычислений - вводим избыточность.

Last edited by dkiselev (2010-02-27 11:26:11)

Announcement

#51 2010-02-26 19:38:28

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

#52 2010-02-26 19:46:41

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

#53 2010-02-26 20:00:41

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

#54 2010-02-26 20:40:17

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

#55 2010-02-26 20:53:28

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

#56 2010-02-26 21:00:47

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

#57 2010-02-26 21:01:46

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

#58 2010-02-26 21:50:07

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

#59 2010-02-26 21:53:06

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

#60 2010-02-26 22:05:38

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

#61 2010-02-26 22:08:58

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

#62 2010-02-26 22:38:35

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

#63 2010-02-26 22:54:30

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

#64 2010-02-27 00:32:42

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

#65 2010-02-27 01:39:35

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

#66 2010-02-27 06:09:57

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

#67 2010-02-27 08:40:34

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

#68 2010-02-27 08:59:23

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

#69 2010-02-27 10:19:35

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

#70 2010-02-27 10:22:39

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

#71 2010-02-27 10:23:34

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

#72 2010-02-27 10:29:20

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

#73 2010-02-27 11:01:08

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

#74 2010-02-27 11:08:20

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

#75 2010-02-27 11:19:22

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

Board footer