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

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

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

Чем лично мне не нравится белорусская схема:

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

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

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

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

Примеры?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну вот единственное что и мне не нравится.

Не путайте адресацию с административным подчинением.

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

Адрес объекта — это тоже объект. Причём он может даже не соответствовать ничему материальному, например «владение» с номером, которое является просто куском территории.

Кстати, тот же вопрос про внутригородские районы: в Москве, например, есть четыре улицы 8 марта.
И если “в любом случае нужен какой-то костыль” - это УЖЕ не универсальная схема.

Vovanium, кусок территории - вполне себе материальный объект :slight_smile:

И ещё: в адресе используют не с/с (не смотрите в КЛАДР, это вредно), а п/о, а оно не обязано совпадать с с/с. Пример: с/с с/п Погореловка (КЛАДР 4002500009900) получает почту через п/о Крюково (КЛАДР 4002500005700).

Напиши, как ты напишешь письмо на почте в каждую из этих улиц.

Alexandr Zeinalov, адрес - это не только почта :slight_smile:
Для регистрации строения или прописки нужен именно адрес с с/с. Адрес с п/о - это уже альтернатива.

Как правильно писать на 8-е марта - я хз, я там не живу.
Кое-где пишут Москва, Липки, ул. 8 марта, кое-где Москва, ул. 8 марта (Липки)

Я не знаю как с 8 марта, но в адресах на ул. Центральная пишут “Москва, Внуково, ул. Центральная” или “Москва, Толстопальцево, ул. Центральная”.

Любая модель будет в чём-то неунивесальной. Схема Карлсруэ ещё менее универсальна. Но можно расширить схему, чтобы она покрывала нужные нам схемы адресации.

В чём различаются адреса, относящиеся к различным улицам 8 марта?

Это не материальный объект в том смысле, что его никак нельзя определить визуально — земля во владении и вокуг на вид одинаковая.

Vovanium, административная граница - объект настолько же материальный, насколько и граница земельного участка. Её тоже визуально не определишь.

Я, кстати, ни разу не выступаю за использование Карлсруэ, мне она нравится не намного больше, чем a3-a6.

ikz


addr:housenumber = 7/08
addr:streetnumber = 2

Имеем то же, что и addr:housenumber, addr:housenumber2, только в неуниверсальном виде.
Такую конструкцию не получится использовать для домов с 3-мя и более адресами.

А указание на адреса в отношениях


housenumbers = addr:housenumbers
housenumbers = addr:streetnumbers

  • жестилово для программистов.

Больше нравится схема Котяры. Только одно не понял там. Зачем вводится тэг address:house? Почему нельзя ограничиться addr:housenumber?