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

В КЗ административное (нет муниципального деления - компактное государство, по численности как Москва с приезжими)
(КАТО) (далее - классификатор) устанавливает структуру, порядок ведения и коды административно-территориальных объектов Республики Казахстан.
КАТО предназначен для применения в отраслях экономики Республики Казахстан при решении задач административного и статистического учета, ведения различных регистров, организации баз данных в территориальном разрезе на разных уровнях государственного управления.

UPD: можно конечно ГА отнести к муниципальному делению, но по моему, не совсем верно.

Это временно… я понимаю, что нет ничего постоянней, чем… но надо стремиться… все равно когда нибудь будут границы.

В Алма-Ате обновил границы районов (в некоторых были потеряны связи), теперь все замкнуты и соответствуют границам города.

Схема сложная, но правильная. Какие могут возникнуть проблемы (кроме конечно муторного нанесения)?

Видел, Турксибский район замкнулся, Алма-ата нашлась, ибо boundary не хватало.

И где “Бостандыкский район” ?

И того по уровням:https://docs.google.com/spreadsheet/ccc?key=0AqtKZqOHU5V-dGEwTTJjb3BVSzZ0SzVyX3J1UlBpN2c&usp=sharing

Сломал… :frowning:

UPD: не сломал… такое впечатление, что и не было его… добавил

Обновил http://wowik.freevar.com/places/kz-test/

wowik
Спасибо.

Посмотри пожалуйста свой источник, похоже заглавная латинская H вместо русского Н в названии Наурзумского района Костанайской области. В ОСМ всё корректно.
http://wowik.freevar.com/places/kz-test/1727.htm

У нас с ANick возник вопрос - какие теги вешать на НП, что убирать в relation, что оставлять на контуре.

Мысли такие (относится только к полигонам !!!):

  1. place=* + landuse=residential - обычно эта комбинация используется как затычка для мелких населенных пунктов. Если рисовать более детально то эти теги вешаются на разные полигоны.
  2. landuse из п.1 - это площадной объект, т.е.
    2.1 - либо обычный замкнутый вей
    2.2 - либо мультиполигон, т.е. relation type=multipolygon (не boundary!!!)

Теперь вопрос про админ.границы для НП. По моему мнению вешать их на все контуры place=* - неправильно: place обычно рисуется наугад, в зависимости от того как дрожала рука художника лишь бы внутрь попали все адресуемые объекты. Т.е. подход должен быть строго индивидуальный, а не массовая замена тегов. Если же нужно чтобы отображалось на рендере - достаточно поточнее обрисовать застройку и назначить landuse=residential | industrial и т.д. От этого гораздо больше смысла и нет никакого обмана.

Во-вторых даже если вешать теги, то решить вопросы:

  • Нужен ли admin_centre для НП ?
  • Если ставить admin_centre, то для НП это скорее акимат, а не точка с тегом place ?
  • Делать ли отдельный relation для этого ?

В общем много вопросов как правильно замапить НП.

Какие будут соображения ?

И как понимать если полигон place вылезет за границу boundary одного и того же НП ?

Наверное рисовать place точнее и только тогда вешать на него boundary… Вот и хотим разобраться.
http://www.openstreetmap.org/relation/3392134#map=14/45.0291/78.4178

пос. Еркин явно надо что-то делать. Тег landuse, наверное, выносить из рилейшена на контур, admin_centre на акимат и пр. Если акимат не нарисован - то и рилейшн не нужен, boundary повесить прямо на контур. Или нельзя ?

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 не забывайте, пожалуйста

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