Ну так в чём проблема - пишете пропозал, предлагаете патчи к редакторам, конвертерам и рендерерам.
После этого все начинают пользоваться новой замечательной схемой, все довольны, все смеются.
А можно подробностей про котярину схему? Мног слышал, но не видел.
[Zverik], [Hind], спаибо. Буду просветляться
Я регулярно заезжаю на велосипеде в города, из которых в осме есть только три улицы и центр. И таки да, в поисках центра я еду именно к точке. На крупном масштабе. Ибо знаю, что где-то там я найду жизнь.
Автовычисление “центра” есть форменный идиотизм. А ещё есть города с эксклавами, отнесёнными на десятки километров (пример — Минск и аэропорт Минск-2 с посёлком Сокол, которые входят в городскую черту, хоть и находятся далеко).
dr&mx, зачем вы вставляете в вику отсебятину про boundary=yes?
http://wiki.openstreetmap.org/w/index.php?title=RU:Key:place&oldid=653596
Да, давайте уж разберёмся и догорворимся, как лучше - relation на всё равно нужен, чтобы не дублировать информацию НП (то, что сейчас - костыль, хоть и работающий), а boundary=administrative портит валидацию.
Опять же, в невидимых границах посёлков в большинстве рендеров ничего хорошего нет (мало ли, что они кривые - так их и править никому не захочется! ). У нас уже residential штампуют на все посёлки, и я не могу сказать, что они неправы - иначе совсем не видно.
Так что, то что есть сейчас - никак не идеал. Заменять его на другие костыли - ещё хуже (ибо лучше не станет, а валидаторы переписывать). Давайте уж попытаемся сделать как у людей…
вы что вообще. полигон, внутри одна точка: они связаны топологически. Вы же не проставляете addr:city, addr:district, addr:region и addr:country каждой улице и дому в своём городе? Информацию дублировать не надо, всё вешается только на точку.
А на полигональную границу посёлка мы что, только place и place_name вешаем? Причём place_name совпадающий (магическим образом) с некой точкой внутри?
Давайте так тогда в вики и напишем - а то, понимаешь, закордонные буржуи напридумывали релейшенов каких-то
Тэги надо ставить и на полигон и на точку - это, в общем, равноправные объекты, один из них может отсутствовать (т.е. ещё не был нарисован), и должна быть возможность выгрузив только точки или только полигоны с place иметь полную информацию.
Вот и ставим сейчас - по другому-то никак… А потом разбираться, у кого population правильный, а то и place. Вот это и есть дублирование.
А то кто-то центр города откроет, добавит population, а на полигон - не добавит. Другой-наоборот…
Проверьте, ради интереса, по базе совпадение тегов по всем place России (PostGIS не учился ещё…)
Дублирование очень много где есть и никого это особо не огорчает. Для population вообще надо ставить source:population и population:year. И всё это всегда можно проверить валидатором.
Принадлежность зданий месту рассчитывается из окружающего их полигона, а не ближайшей точки. Потому точка только для рендера и приблизительного расчёта расстояний. А информация на полигон или отношение
Вот я и говорю - договариваться надо. Причём по-хорошему
На мой взгляд, точка центра - вторичный объект и нужен чисто для удобства поиска (при имеющейся границе). Зато её куда проще найти и обработать - если всё вешать на границу, то скрипты будет тяжелее и медленнее.
Отношение со всей информацией может быть не таким уж плохим выбором (но не единственно возможным, разумеется). По большому счёту точки нужны только для совместимости, а границы place - для валидаторов (не рендерятся же, собаки!).
А, например, ближайший НП - из точки. Ещё раз - все данные должны быть и там, и там.
Дублирование данных - это зло. Причины уже выше были озвучены.
Насколько технически сложно обрабатывать такой вариант: данные на релейшене, который включает в себя и полигон и точку центра?
place и place_name на полигоне - неизбежность, согласен. Но вот зачем всякие индексы и коды c населением дублировать?
Кстати, много где границы place всё же являются и административными границами. Приходится одни и те же линии в 3 отношения совать - multipolygon-place, boundary-город и boundary-район снаружи.
Вот-вот, и я к тому же. Необходимый минимум оставить в точке (name и place), всё остальное - в отношении (в Белоруссии так и есть - Котярина схема, да? но там такой подход аж до домов, что наверное, слишком).
Ну, может place_name на границе продублировать, и то не обязательно - топологическая связность есть, да ещё и отношение.
Place-мультиполигоны же нормально обрабатываются.
Итак, варианты:
Основной вариант, судя по последнему варианту wiki - 2+4. Я не против, главное - чтобы порядок был и ничего лишнего
- place-точка и place -полигон/мультиполигон c полностью совпадающими тегами
- ничего менять не надо, привыкли
- дублирование и неизвестно, где первоисточник
- проблема совпадения границ и place
- Все теги на точке, точка в полигоне/мультиполигоне с place=_ и может быть, place_name=_.
- нет дублирования большого количества тегов
- из базы можно только повыкидывать лишнее
- менять в софте ничего не надо. Или надо? Если кому нужен почтовый индекс “вот-этого-полигона”, доберутся ли до него по имени или топологии?
- проблема совпадения границ и place
- а если точки нет, а полигон есть? (поставить точку и не париться, что ли)
- Все теги на отношении, в нем же участки границы НП
- дублирования нет
- быстро находится центр по границе и обратно
- всё рушится, ибо с границы убирается place.
- (wiki) Опционально - если известна граница, создаётся отношение со ссылкой на центр. Все теги - по прежнему в точке центра.
Можно ли отныне считать, что 1,3 - это плохо? (Ведь много где в другизх странах 3 - основной способ). И если так, будут ли валидаторы/боты?