chnav, ты все отношения посмотрел? там их несколько… вот хотел помимо всего прочего услышать о них, можно ли так тегировать:
Отношение: Еркинский с.о. http://www.openstreetmap.org/relation/3392136 ,не хватает еще двух НП (“Отделение 3” и “Отдельно стоящие дома”) не знаю где они, была бы карта генштаба этого района можно было бы определить “Отделение 3” ну а дома на глазок либо после уточнения на местности.
Отношение: Талдыкорган Г.А. http://www.openstreetmap.org/relation/3392135#map=13/45.0130/78.3672
UPD: прочел позже твой ответ в личке. Насчет границ Г.А. в него входят НП и НП могут находиться на определенном расстоянии, я не думаю что территория между ними обязательно должна подчиняться Г.А. Так же я не думаю, что есть какие либо офиц. картографические материалы которые будут четко указывать эти самые границы. Скорей всего все сделано на уровне домов\дворов, что позволяет только “на глазок” прикинуть эти границы (также и с с.о. эти самые “дома отдельно стоящие” могут находиться по другую сторону Талдыкургана, не будешь же чертить границу через него)
Своё мнение насчет отношений с.о. я высказывал ранее - смысл в них есть только если известны границы земельных владений. Если такой информации нет то достаточно ставить на полигон и точку place тег subdistrict=<название с.о.>
Мне кажется есть небольшая путаница: административная граница с.о. - это некий контур, в которые должны попасть не только НП, но и земли. Если же просто делать relation, в который включить объекты place то это не relation boundary - это relation collection, которых в ОСМ стараются избегать т.к. достаточно сделать выборку по базе всех НП с заданными свойствами subdistrict=<название с.о.>
Из описания вики видно что районы города, включаемые в виде вложенных relation с ролью subarea, избыточны и от них тоже со временем надо избавляться. Они и так попадают в контур Алматы и принадлежат полигону города геометрически. Можно оставить конечно, но уж точно не надо делать подобное с другими НП т.к. это устаревшая и неподдерживаемая схема.
Согласен, думаю нужно будет убрать, раз уже считается лишним.
Касаемо границ Г.А. и С.О. ты уверен “на все 100”, что они из себя представляют целый (не разрозненный) полигон? или же все равно отношение+эксклавы?
Тут еще чтение разных постановлений навело на мысль (у тебя видимо прозрение раньше случилось) о том, что административные границы НП ( а соответственно и Г.А. и с.о.) могут включать еще и части пахотных земель вокруг… что переводит задачу по нарисовке адм. границы НП в mission impossible, по крайней мере в данный момент…
В итоге: либо начать рисовать примерно (с отношениями и пр. сложностями), а потом по мере появления данных уточнять границы, т.е. занимаем позицию: “Иногда лучше иметь на карте объект с приблизительными координатами, чем не иметь его вообще”, либо все мапить, как ты и говорил (только жилые\пром. зоны - полигон+place+addr:subdistrict… и т.д.), выстраивая адм. иерархию в адресном пространстве.
Моё предпочтение (хотя и не принципиальное) “иметь объект на карте”. Пока не знаю к каким последствия может привести и чем плох этот вариант (у кого есть опыт?).
Уже хотелось бы определенности куда движемся (в принципе, я за любой обоснованный\согласованный вариант)
Куда пропали наши казахстанские маперы… никто не отзывается… У нас тут междусобойчик получается…
ANick
Лучше не делать отношения с.о. без необходимости, а когда будет информация и нужда в них - тогда наносить, т.е. решать проблему по мере поступления.
Я так делал с Рудным Г.А., остановился на admin_level=6, населенным пунктам внутри него назначил соответствующие addr:district, а там где есть +addr:subdistrict. Всё работает, валидаторы проходит, в навигаторах ищет, районные границы рисуются на мапнике… Главное ответить для себя на вопрос - “зачем нужны границы”. Рисовать только ради самого процесса, да ещё фиктивные границы - потом вообще невозможно будет разгрести что правда, а что нет Полностью переносить КАТО со всей его иерархией в ОСМ совсем необязательно, это всего лишь справочник без указания геометрии. Зачем нам додумывать границы с.о. если мы их не знаем, фиктивные данные у нас никогда не приветствовались.
Сдается мне, что Г.А, содержащая один нп имеет с ним тождественную границу. Аналогично с г.а., п.а. и с.о.
Но поскольку это всё-таки два разных объекта (имена и коды разные), приходится их разлеплять на два.
Неплохой валидатор, вот только Украину в нем лучше не открывать, станица загружается очень долго.
Кстати, багрепорт по Грузии в этом валидаторе: в пределах Грузии определяется 0 нп.
wowik, есть вопрос по валидатору, нп Урджар http://wowik.freevar.com/places/kz-test/1130.htm, является районным центром, население 16к чел. (т.е. тянет на town), но в валидаторе отмечен как hamlet. Ошибка вкралась?
(added)
Сорри, ложная тревога, оказывается это исключительно информационное поле и валидатор нашел нужный объект. У меня была другая проблема - объект не идентифицировался валидатором, я решил что из-за разницы значения place.
Если place точки и вея не совпадают, то они не слипаются в один НП. Соответственно их получается два и посему ни один потом не матчатся со справочником из-за неоднозначности.
Планируется попробовать слеплять-таки, но красить ошибкой.
Вопрос возник, по admin_centre.
Есть в городе два акимата, один городской, второй областной. Расположены в разных местах.
По идее нужно указать в отношении границ города адм. центр города (гор. акимат) а в области адм. центр области (областной акимат)
Точка центра города с тэгами:
указана как admin_centre для полигона границ города.
Не пойму, как в этом случае тэгировать и указывать областной центр? перенести тэги с границ области на точку и включить ее (не абсурд)?
ANick admin_centre указывается точка place, которая может просто стоять на центральной площади. То что я раньше предлагал как акимат - это было предположение для самого низкого уровня деления, т.е. когда boundary=administrative делается для населенного пункта. Но для более крупных границ всё-равно точка населенного пункта. Так всегда делали и не вижу смысла менять, иностранцы знать не знают про наши акиматы, одно их название введёт в ступор )))
Где-то у него границы неверно обрабатываются, или в OSM они там не все есть и не все быть может валидные, посему на них нельзя было так слепо полагаться.
Плюс модель данных чуть отличается от российской