Административные границы Казахстана

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=<название с.о.>

Вот замечательная статья на эту тему Relations are not Categories

И ещё давно хотел спросить про Алматы
http://wiki.openstreetmap.org/wiki/Relation:boundary

Из описания вики видно что районы города, включаемые в виде вложенных relation с ролью subarea, избыточны и от них тоже со временем надо избавляться. Они и так попадают в контур Алматы и принадлежат полигону города геометрически. Можно оставить конечно, но уж точно не надо делать подобное с другими НП т.к. это устаревшая и неподдерживаемая схема.

Согласен, думаю нужно будет убрать, раз уже считается лишним.

Касаемо границ Г.А. и С.О. ты уверен “на все 100”, что они из себя представляют целый (не разрозненный) полигон? или же все равно отношение+эксклавы?

Тут еще чтение разных постановлений навело на мысль (у тебя видимо прозрение раньше случилось) о том, что административные границы НП ( а соответственно и Г.А. и с.о.) могут включать еще и части пахотных земель вокруг… что переводит задачу по нарисовке адм. границы НП в mission impossible, по крайней мере в данный момент…
В итоге: либо начать рисовать примерно (с отношениями и пр. сложностями), а потом по мере появления данных уточнять границы, т.е. занимаем позицию: “Иногда лучше иметь на карте объект с приблизительными координатами, чем не иметь его вообще”, либо все мапить, как ты и говорил (только жилые\пром. зоны - полигон+place+addr:subdistrict… и т.д.), выстраивая адм. иерархию в адресном пространстве.

Моё предпочтение (хотя и не принципиальное) “иметь объект на карте”. Пока не знаю к каким последствия может привести и чем плох этот вариант (у кого есть опыт?).
Уже хотелось бы определенности куда движемся (в принципе, я за любой обоснованный\согласованный вариант)

Куда пропали наши казахстанские маперы… никто не отзывается… У нас тут междусобойчик получается…

ANick
Лучше не делать отношения с.о. без необходимости, а когда будет информация и нужда в них - тогда наносить, т.е. решать проблему по мере поступления.
Я так делал с Рудным Г.А., остановился на admin_level=6, населенным пунктам внутри него назначил соответствующие addr:district, а там где есть +addr:subdistrict. Всё работает, валидаторы проходит, в навигаторах ищет, районные границы рисуются на мапнике… Главное ответить для себя на вопрос - “зачем нужны границы”. Рисовать только ради самого процесса, да ещё фиктивные границы - потом вообще невозможно будет разгрести что правда, а что нет :slight_smile: Полностью переносить КАТО со всей его иерархией в ОСМ совсем необязательно, это всего лишь справочник без указания геометрии. Зачем нам додумывать границы с.о. если мы их не знаем, фиктивные данные у нас никогда не приветствовались.

ОК, аргумент! :slight_smile:
Нужно схему тегирования описать… а то http://www.openstreetmap.org/relation/2498788 :slight_smile:

Сдается мне, что Г.А, содержащая один нп имеет с ним тождественную границу. Аналогично с г.а., п.а. и с.о.
Но поскольку это всё-таки два разных объекта (имена и коды разные), приходится их разлеплять на два.

boundary=administrative не забывайте, пожалуйста

Я где то пропустил?

Дюжину уж точно. Уж не помню - исправлял сразу.

Порекламирую валидатор имен НП, добавили name:kk:
http://navitel.osm.rambler.ru/names/kazakhstan-place.osm.htm

Жалко, что он не проверяет, что имена не разошлись, то есть хотя бы, что name совпадает с одним из name:*

Бауыржан Момышулы с.о.	Б.Момышулы с.о.	Бауыржан Момышұлы атын. а.о.

Да, и он ничего не печатает, если нет name (а name:ru и т.п. есть)

Неплохой валидатор, вот только Украину в нем лучше не открывать, станица загружается очень долго. :slight_smile:
Кстати, багрепорт по Грузии в этом валидаторе: в пределах Грузии определяется 0 нп.

Очень, минут 10 где то. Но если надо можно и подождать.

Это всё из-за вчерашних проблем с гислабом.

Всех с наступившим!

wowik, есть вопрос по валидатору, нп Урджар http://wowik.freevar.com/places/kz-test/1130.htm, является районным центром, население 16к чел. (т.е. тянет на town), но в валидаторе отмечен как hamlet. Ошибка вкралась?

wowik
Может игнорировать это поле при сверке ?

(added)
Сорри, ложная тревога, оказывается это исключительно информационное поле и валидатор нашел нужный объект. У меня была другая проблема - объект не идентифицировался валидатором, я решил что из-за разницы значения place.

Если place точки и вея не совпадают, то они не слипаются в один НП. Соответственно их получается два и посему ни один потом не матчатся со справочником из-за неоднозначности.
Планируется попробовать слеплять-таки, но красить ошибкой.

Вопрос возник, по admin_centre.
Есть в городе два акимата, один городской, второй областной. Расположены в разных местах.
По идее нужно указать в отношении границ города адм. центр города (гор. акимат) а в области адм. центр области (областной акимат)
Точка центра города с тэгами:

addr:country=KZ
addr:district=Караганда Г.А.
addr:region=Карагандинская область
int_name=Karaganda
...
name:kk=Қарағанды
name:ru=Караганда
name=Караганда
place=city
..

указана как admin_centre для полигона границ города.
Не пойму, как в этом случае тэгировать и указывать областной центр? перенести тэги с границ области на точку и включить ее (не абсурд)?

ANick
admin_centre указывается точка place, которая может просто стоять на центральной площади. То что я раньше предлагал как акимат - это было предположение для самого низкого уровня деления, т.е. когда boundary=administrative делается для населенного пункта. Но для более крупных границ всё-равно точка населенного пункта. Так всегда делали и не вижу смысла менять, иностранцы знать не знают про наши акиматы, одно их название введёт в ступор )))

Что-то много бредовых addr:* пошло от этого господина

http://www.openstreetmap.org/node/412258736/history
Здесь еще целый список: http://wowik.freevar.com/places/kz-test/751.htm
http://www.openstreetmap.org/node/242940822/history
и т.д.

Где-то у него границы неверно обрабатываются, или в OSM они там не все есть и не все быть может валидные, посему на них нельзя было так слепо полагаться.
Плюс модель данных чуть отличается от российской