Да, давайте уж разберёмся и догорворимся, как лучше - relation на всё равно нужен, чтобы не дублировать информацию НП (то, что сейчас - костыль, хоть и работающий), а boundary=administrative портит валидацию.
Опять же, в невидимых границах посёлков в большинстве рендеров ничего хорошего нет (мало ли, что они кривые - так их и править никому не захочется! ). У нас уже residential штампуют на все посёлки, и я не могу сказать, что они неправы - иначе совсем не видно.
Так что, то что есть сейчас - никак не идеал. Заменять его на другие костыли - ещё хуже (ибо лучше не станет, а валидаторы переписывать). Давайте уж попытаемся сделать как у людей…
вы что вообще. полигон, внутри одна точка: они связаны топологически. Вы же не проставляете addr:city, addr:district, addr:region и addr:country каждой улице и дому в своём городе? Информацию дублировать не надо, всё вешается только на точку.
Тэги надо ставить и на полигон и на точку - это, в общем, равноправные объекты, один из них может отсутствовать (т.е. ещё не был нарисован), и должна быть возможность выгрузив только точки или только полигоны с place иметь полную информацию.
Дублирование очень много где есть и никого это особо не огорчает. Для population вообще надо ставить source:population и population:year. И всё это всегда можно проверить валидатором.
Принадлежность зданий месту рассчитывается из окружающего их полигона, а не ближайшей точки. Потому точка только для рендера и приблизительного расчёта расстояний. А информация на полигон или отношение
Вот я и говорю - договариваться надо. Причём по-хорошему
На мой взгляд, точка центра - вторичный объект и нужен чисто для удобства поиска (при имеющейся границе). Зато её куда проще найти и обработать - если всё вешать на границу, то скрипты будет тяжелее и медленнее.
Отношение со всей информацией может быть не таким уж плохим выбором (но не единственно возможным, разумеется). По большому счёту точки нужны только для совместимости, а границы place - для валидаторов (не рендерятся же, собаки!).
Дублирование данных - это зло. Причины уже выше были озвучены.
Насколько технически сложно обрабатывать такой вариант: данные на релейшене, который включает в себя и полигон и точку центра?
place и place_name на полигоне - неизбежность, согласен. Но вот зачем всякие индексы и коды c населением дублировать?
Кстати, много где границы place всё же являются и административными границами. Приходится одни и те же линии в 3 отношения совать - multipolygon-place, boundary-город и boundary-район снаружи.
Вот-вот, и я к тому же. Необходимый минимум оставить в точке (name и place), всё остальное - в отношении (в Белоруссии так и есть - Котярина схема, да? но там такой подход аж до домов, что наверное, слишком).
Ну, может place_name на границе продублировать, и то не обязательно - топологическая связность есть, да ещё и отношение.
Place-мультиполигоны же нормально обрабатываются.
Не видно границ НП (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.
Бот может пригодиться только для автодублирования тегов, если оно требуется.
). У нас уже residential штампуют на все посёлки, и я не могу сказать, что они неправы - иначе совсем не видно.