Согласен, думаю нужно будет убрать, раз уже считается лишним.
Касаемо границ Г.А. и С.О. ты уверен “на все 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 они там не все есть и не все быть может валидные, посему на них нельзя было так слепо полагаться.
Плюс модель данных чуть отличается от российской
Там между многими областями действительно кривые границы, до 2-5 км в сторону. Исправляем понемногу, пока что ручаюсь за Костанайскую, Южно-Казахстанскую и Акмолинскую области. Жамбылская среднего качества.
Полностью переносить КАТО со всей его иерархией в ОСМ совсем необязательно, это всего лишь справочник без указания геометрии. Зачем нам додумывать границы с.о. если мы их не знаем, фиктивные данные у нас никогда не приветствовались.