А что это за проблема?
Индекс может и не нужен, а вот основная адресация нужна
Не видно границ НП (place), даже если они известны. Если хотим добавить boundary, place приходиться делать мультиполигоном, даже если в нем нет дырок.
boundary c name=имя города запутывает окончательно, place= на отношении тоже как-то не так…
Ут-точните, ппжалуста, я записываю 
Которые addr:country, addr:district, addr:region? Они кстати, далеко не на всех полигонах place стоят и с этим надо что-то делать…
Тут надо определяться. Варианты:
- ставим только сами, обязательно
- если сами не поставили - ставятся ботом по топологии границ
- не ставим, ищем точку внутри и берём с неё (много чего работать не будет? )
- теги переносятся ботом с точки
Какая-то чушь, честно говоря. Что за проблема совпаделия границ и place, что за проблема убирания place с границы, какая вообще связь между границами и place?
Вообще, ситуация точно такая же, как и с улицами и с домами из кусков. Вменяемых вариантов всего два - либо тэги и на точке, и на полигоне, либо только на отношении, которое включает и точку и полигон. Во втором случае какое вообще отношение предлагается использовать и кто его поддерживает? Вариант с тэгами только на точке тоже приемлим, но в таком случае для получения свойств НП по полигону требуется дополнительный запрос, и не надо забывать что есть НП без точек.
Разумеется, нельзя.
Надо - будут.
Резюме:
Общей точки зрения нет.
Две основный позиции -
А) 2,4 (wiki, все основные теги на точке, если 100% известна официальная информация, граница собирается в отношение boundary/administrative)
Б) 1,3 (пока нет вменяемого отношения, дублируем теги полностью)
Конструктивные предложения:
-
Принять A.
-
Если нужны теги на полигоне (1) для быстрого поиска, переносить их с точки с помощью бота. Если теги уже есть - не стирать, а сделать валидатор.
-
Точки добавить во все place-полигоны в обязательном порядке (валидатор).
-
Начать договариваться о вменяемом отношении, которое все будут поддерживать.
Да блин, сделайте type=place, не знаю, в самом деле. По типу мультиполигона, плюс с точкой с ролью centre. Только не ломайте текущую схему. И не надо уродства с boundary=* и, тем более, ботов.
Ещё раз по пунктам:
а) boundary/administrative не имеет никакого отношения к нас. пунктам, не надо её сюда приплетать
б) нас. пункты положено обозначать двумя объектами: точкой центра и полигоном территории. Оба они обозначаются как place=* (никаких boundary!!!), теги адресации addr:* желательно вешать и туда и туда
в) придумывание новых отношений - неплохая разминка для мозга, но практической пользы от него не много
Предлагается основными считать теги на точке, а на полигоне их либо не ставить (кроме 1-2 шт), либо переносить автоматически.
Официальные границы НП (поселений) всё равно являются административными низкого уровня, никуда от этого не деться. То, что наша схема этого не поддерживает - проблема нашей схемы, незаметная из-за недостатка данных по границам единиц мельче районов.
Разумеется, все от балды нарисованные place тут действительно ни при чём и расставлять куда попало boundary нельзя.
Согласен. Отношение нужно как альтернативный вариант. За бугром это мелкомодульный type=boundary или мультиполигон, в Белоруссии- address.
Бот может пригодиться только для автодублирования тегов, если оно требуется.
Кто будет делать автоматический перенос?
Не являются. Именно поэтому не надо их смешивать.
PS.
НП != поселения, пойми это уже наконец.
akks
ещё раз: у отдельных деревень границ НЕТ вообще. Даже в законах. В кадастре есть “земли поселений”, однако: 1. Кадастровое деление отличается от административного. 2. НП может состоять из любого количества КК, КК могут частью быть в НП, а частью - в лесу или в поле. 3. В кадастре у КК в отличие от участков (“деревня Осьмовка, ул. Стива Коста, д. 1”) нет никакого текстового описания вообще - нельзя определить, к чему там что относится.
По существующей системе да. Но вас не смущает что boundary=administrative admin_level=10 и полигон place для одного и того же населённого пункта несут абсолютно одинаковую информацию? Они просто дублируют друг друга. И так в случае с любым населённым пунктом, граница которого известна и нанесена. Зачем?
Разве мы не можем совместить систему адресации и административно территориального деления. Тем более, что в жизни адресация на него как раз и завязана.
to Alexandr Zeinalov, liosha. Границы населённых пунктов есть. Не везде. Но их очень много. Нужны подробности?
Alexandr Zeinalov, на самом деле границы у деревень есть. Только они ни разу не “административные” и их хрен найдёшь даже в словесном описании.
Правильно, никаких boundary=administrative admin_level=10 быть не должно - это ошибочное обозначение. Откуда вы его постоянно выуживаете??
Не можем, это разные вещи. Административные границы должны разделять административные единицы, а нас.пункты не являются административными единицами.
Нет, адресация идёт вообще параллельно, хотя кое в чём и пересекается
Это потому, что у нас пока с кадастром бардак не разобрали. Все будет через год-другой. И реестры адресные допилят. Деревни-ладно. Но по городам данные уже появляются. То есть на будущее такая возможность должна быть, а пока за неимением данных это не используется и запрещается)
Ok. Понимаю о чём вы. Тогда как нам обозначать границы населённых пунктов? Заводить для них новую сущность?
На счёт параллельность тоже согласен. Там всё сложно. Но вся эта “параллельность” обычно идёт до уровня где заканчивается “административность.” Почему бы не подвязать адресацию “снизу” под административным делением. Я не так хорошо знаком с тонкостями почтовой адресации. Возможно существуют какие-то препятствия. Но они мне не известны. Если расскажете, буду весьма признателен.
Зачем?? Нас. пункты мы обозначаем полигоном place. “Граница н.п”, если она так уж нужна, - это граница этого полигона.
Сложности хотя бы в том, что не все административные уровни участвуют в адресации. Например, сельское поселение туда попадает только в случае неоднозначности н.п, а ГО отбрасывается для головного города.
Значит весь топик у нас об особенностях описания состава муниципальных образований?
Я наверное выгляжу глупо, упершись как баран в этот admin_level=10. Но почему, хотя бы муниципальное деление не сделать продолжением административного? Тот самый пресловутый admin_level=10.
А здесь вообще никаких сложностей вроде нет. Нет, серьёзно.
А оно и есть продолжение административного. Верхний уровень (районы и ГО) - admin_level=6, нижний (поселения) - admin_level=8. Глубже только admin_level=9 - деление некоторых ГО на районы.
Что-то ещё надо поделить?
Особых сложностей тут нет, конечно, я просто показываю, что административное деление не совпадает с адресацией.
В общем, должна быть -корректная возможность- совместить place c boundary, которая ничего не будет рушить. Пользоваться ей в массовом порядке пока не стоит из-за нехватки данных.
Административное деление:
- РФ, ЦФО, Калужская область, Юхновский район, СП деревня Погореловка, деревня Екатериновка.
- РФ, ЦФО, Калужская область, Юхновский район, СП деревня Чемоданово, деревня Екатериновка.
Почтовый адрес:
- 249903, Калужская область, Юхновский район, п/о Крюково, деревня Екатериновка.
- 249923, Калужская область, Юхновский район, п/о Чемоданово, деревня Екатериновка.
Не надо упорно пытаться упростить то, что не упрощается. Есть куча нюансов, которые придётся разруливать.
И ещё раз: не надо пытаться совмещать place c boundary: это разные вещи, а разные вещи обозначаться должны по-разному. Попытки их совместить приводят только к идиотизмам типа admin_level=10