А я считаю, что очень дельное предложение высказал Hind ещё джва года назад:
От себя добавил бы ещё в это отношение
: boundary
: label
И у нас получилась бы очень чёткая и прозрачная сверху вниз система границ и адресации.
А я считаю, что очень дельное предложение высказал Hind ещё джва года назад:
От себя добавил бы ещё в это отношение
: boundary
: label
И у нас получилась бы очень чёткая и прозрачная сверху вниз система границ и адресации.
Её, по идее, надо доработать, а если её доработать, то получится Котярная схема адресации, а её никто не будет поддерживать. Кроме меня :3
Ну так в чём проблема - пишете пропозал, предлагаете патчи к редакторам, конвертерам и рендерерам.
После этого все начинают пользоваться новой замечательной схемой, все довольны, все смеются.
А можно подробностей про котярину схему? Мног слышал, но не видел.
[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-район снаружи.