Есть мысль порезать карту (например, для конвертации в Навител) по границам районов субъекта. Целесообразность такого подхода, наверняка спорная. Речь не об этом
В процессе ознакомления с состоянием “разграниченности” районов наткнулся на довольно частый случай, когда часть границы представлена фрагментом (веем) реки. Т.е. в релейшн границы входят веи boundary=administrative и waterway=river (например).
Это нормально?
Пример: http://osm.org/go/2Sz2yvvB– http://www.openstreetmap.org/browse/relation/1071133
Нормально. Если административная граница проходит по естественному объекту (фарватеру реки, берегу реки, дороге и т.п.) этот вей можно и нужно включать в релейшн границы. boundary=administrative; admin_level=* на вее ставить не обязательно, но желательно. По-хорошему, надо бы переделать границы областей проходящие по рекам. Сейчас там часто два параллельных вея, один для реки, второй для границы.
Это ещё зачем? Река физически - это сама река, на ней должны быть только те теги, которые описывают её физические характеристики (расход воды, глубина и пр.). Всякие теги виртуальных границ должны быть на самих отношениях этих границ.
Хороший вопрос подняли. Проблема в том, что у нас нет отношения, позволяющего объединять линии границ, а отношение boundary — фактически разновидность мультиполигона. Есть пропозал по отношению http://wiki.openstreetmap.org/wiki/Relations/Proposed/boundary_segment, но его никто не использует.
Помимо рек ещё проблема с дорогами — если граница проходит по оси улицы, обозначенной одной линией. На дороги теги границы обычно не ставят, и из-за этого граница не отображается в некоторых рендерах (например в Осмарендере). Если на дорогу поставить теги границы, то она в JOSM обозначается только как граница, что очень неудобно.
Недостаток нынешней схемы ещё и в дублировании на линиях/отношениях тегов boundary=* и admin_level=*, из-за чего границы криво рендерятся например в стандартном Мапнике (накладываются друг на друга).
Для решения этих проблем хорошо было бы разделить 2 понятия — линии границ (т.е. сами границы) и территории в этих границах.
Вижу такие варианты:
принимать boundary_segment и добиваться его поддержки, сохраняя тип boundary для полигонов (что совсем не логично);
использовать отношения boundary для линий границ, а территории обозначать мультиполигонами (желательно с ролями subarea, admin_centre и label)
А нафига он нужен? Только разве что для морских границ, которые вроде как законодательно определены незамкнутыми кусками.
Это проблемы конкретного рендера и конкретного редактора, не так ли?
Пример можно? Контрпример - Граница Питера и Ленобласти - это и admin_level=4 и 5 и 6 и 8. mapnik нормально всё рендерит - рисует самую жирную границу (admin_level=4).
Нужен хотя бы для того, чтоб сократить количество участников в отношениях boundary, а заодно тем самым упростить редактирование этих отношений. И для того чтоб не ставить boundary=* на реки/улицы/пути.
Это скорее проблема данных. Сочетание тегов highway=residential и boundary=administrative на одной линии довольно странное. То что границами в OSM назвали замкнутые территории, очерченные настоящими границами — тоже неправильно.
Подниму ка я эту тему. В продолжение последней дискуссии имею вопрос.
Зачем прописывать тэги boundary=administrative и admin_level=* линиям, если эта информация уже имеется в отношениях. Вроде как ненужное дублирование, нэ? Какую смысловую или иную роль сейчас играют эти тэги на линиях?
Если линия больше никакого смысла не имеет (только граница), то теги удобны при редактировании — чтобы не оставлять пустыми. А когда граница идёт по реке, например, — эти теги не нужны.
Да, все так и есть. Вроде логично - boundary ставим на линию, только если на ней больше нечего ставить (больше для наглядности, рендеры и так разбираются). Или если граница образована одной линией. Иначе ставим boundary=… на отношение type=boundary (не на мультполигон только…)
Меня как раз и напрягает вопрос логичности (местами я перфекционист). По вашему выходит, что если бы JOSM не умел правильно отображать мультиполигоны зданий, было бы вполне логично линиям зданий, образующим мультиполигон присваивать те же тэги building=yes. Так же и в случае с прочими мультиполи.
То есть грубо говоря мы рисуем под рендер JOSMа? Если бы он умел правильно отображать мультиполигоны границ, эти тэги на линиях не понадобились бы?
Как-то странно слышать такую аргументацию. Единственный пока весомый довод, который мне подсказали - конвертер в Навител не умеет обрабатывать отношения границ и берёт информацию из линий. Тоже своего рода рисование под рендер. Но это мне понятнее как-то…
Хмм… Возможно показалось. Josm не всегда правильно отображает границу без тэгов на линии. Закономерность. отловить не удалось. Я подумал, что в этом проблема. Если ошибся, тысяча извинений.
И всё же никак не могу понять смысл дублирования информации.
И что плохого в пустых тэгах? В мультиполигонах сплошь и рядом тэги линий пустые. Никого не смущает.
У жосма проблема с переносом тегов с отношений на линии, чаще всего при редактировании не снимаются какие-то атрибуты. Дублирования информации в OSM очень много, и цель всегда — удобство использования и редактирования. Но для границ теги имеют и физическое свойство: они показывают, что эта линия — граница. Изначально, ведь, отношений не было, были только границы. Отсюда и такой странный тег для обозначения административных единиц: стоило бы придумать другой в своё время, но момент упущен.
Есть вот еще вот какой момент - простого способа установить членом каких отношений была данная линия, не зная id этих релейшнов, нет. Это может приводить к некоторой путанице при возникновении осиротевшей линии (например, в результате неудачного split-а) - ни кому не будет понятно, что когда-то это была граница. Ну а при текущем варианте можно границы не являющиеся членами отношений в какой-нибудь валидатор добавить - то же вроде бы будет толк.