по воронежской области:
Города без полигональных границ:
“Марківка” - украина.
Города без точечного центра:
“Михайло-Хлюстино”, “Плехановка”, “Ближние Россошки” - точка есть. не воронежская обл, hamlet.
по воронежской области:
Города без полигональных границ:
“Марківка” - украина.
Города без точечного центра:
“Михайло-Хлюстино”, “Плехановка”, “Ближние Россошки” - точка есть. не воронежская обл, hamlet.
Вопросы, аналогичные Воронежским, есть и по Брянской области.
Обновите, пожалуйста, границу Владимирской области.
http://dl.dropbox.com/u/101358077/RU-VLA.zip
Ототдвинул границу с населенных пунктов, что бы они целиком попадали/не попадали.
AlexeyS, помню, сделаю, наверно уже в понедельник.
НЕБОЛЬШОЕ ОБЪЯВЛЕНИЕ
По многочисленным просьбам трудящихся добавил в валидатор отображение изолятов и улиц вне городов списками. Надеюсь от этого станет удобнее.
Сварганил тут небольшой плугинчик к osmosis, который занимается анализом связности графа. Его можно использовать для разных целей:
Пример обработки Ленобласти (это граф от trunk до service с выделенными изолятами всех уровней):
Командная строка: osmosis --read-xml RU-LEN.osm.bz2 --lp --build-routing-graph graphLevel=service --write-xml RU-LEN_f.osm
На моём домашнем компьютере эта обработка заняла 17 минут.
Замечания, предложения, комментарии - приветствуются.
Контроль качества (RU-TA) в категории Города без точечного центра выдает ошибку на Коркатово (http://osm.org/go/2QiMpFyS–).
Точечный центр есть, имя у него такое же, как и у полигона, в чем проблема, не ясно.
Точечный центр не попадает в выгрузку, т.к. это Марийка. Полигон цепляется из-за граница+10 км обрезки.
IMHO, перед валидацией надо дополнительно обрезать регионы по границе…
Ага, спасибо, жду
Только нужно добавить вот этот, который последний указал. Я ранее старый где-то указывал - там мало испралвлений.
AlexeyS,
прошло, проверяйте.
shafr, ikz,
какая бы ни была обрезка, пусть даже по границе, она может что-нибудь разломать: границы НП, озера, захватить гранцы но не захватить пунсон нп, итд. Поэтому мы границы обрезки переодически корректируем. Обрезка строго по админ. границе тоже не совсем хороша, потому что в такой границе слишком много точек и потому что могут не вполне удовлетворятся условия к выборке дорог. Последнее - сложная тема, кратко можно сказать, что для СГ желательно чтобы область карты была выпуклой
Ткните носом, как сделать poly-файл: по Брянской области проблемы с графом сейчас, в основном, ютятся в Белоруссии и на Украине.
При сохранении в POLY формате плагин возвращает коорднаты
3.991392E+01 5.695309E+01
Я не знаю как такие координаты понравятся системе обрезки и насколько урезанная точность будет неущербна.
Что бы это все не выяснять я скачал:
osm2poly.pl link
тот к удивлению вернул такие же “нехорошие” координаты
но после исправления одной из строчек
$polybuf .= sprintf(" %E %E\n", $nodes->{$id}->[1], $nodes->{$id}->[0]);
в такой вид
$polybuf .= sprintf(" %.12g %.12g\n", $nodes->{$id}->[1], $nodes->{$id}->[0]);
Выдал нужный результат.
Где качать нужные poly и насколько правильны мои действия, я бы хотел, чтобы уточнил многоуважаемый Zkir
AlexeyS,
спасибо, все правильно.
Скачать поли нужно здесь: https://github.com/Zkir/osm2dcm/tree/master/osm2dcm/poly
так должно работать. А вот название области в первой строчке крайне желательно, оно нужно чтобы я понимал что это за файл.
Уже процесс редактирования границы описан неплохо вот здесь:
http://wiki.openstreetmap.org/wiki/RU:%D0%A1%D0%B8%D1%82%D0%B8%D0%93%D0%98%D0%94#.D0.93.D1.80.D0.B0.D0.BD.D0.B8.D1.86.D1.8B_.D0.BA.D0.B0.D1.80.D1.82.D1.8B
Вообще-то этот формат чисел (“научный”) прописан как канонический в спецификации формата. Его понимают абсолютно все популярные языки программирования наравне с обычным форматом с плавающей точкой. Поэтому не нужно портить инструменты, пользуйтесь функцией сохранения poly в JOSM.
я понимаю что это за формат немножко программирую на досуге
но в таком формате точность уменьшается - мне вот за это обидно стало, да и оригинальный поли был без степеней. и не понимаю зачем нужны тут степени, ведь больших знечений степени тут не подразумевается.
Ну да ладно. Раз стандарт принят, и не надо конвертить - настаивать на этом шаге не буду.
Мне тоже кажется что “научный” формат чисел попал в спецификацию формата не от большого ума
Географические координаты изменяются в весьма узких пределах (-90…90 и -180…180), поэтому степень и мантисса в применении к ним выглядят более чем странно.
Может запилите Украину в валидаторе по областях?
Угу, особенно при том, что в самом осм координаты хранятся с фиксированной запятой.
На самом деле никто не заставляет писать именно с Е, без него тоже все поймут.
Это так нужно? Какую проблему это решит?
Подскажите, отношение “Зеленоград” с “comment = Для адресов” - это нужно для данного конвертера/валидатора?
http://www.openstreetmap.org/browse/relation/1988678/history
Валидатор ОКТМО ругается “Вложенные НП (полигон внутри полигона)”:
http://yav.gis-lab.info/boundaries/r1988678
Судя по “матрёшке”, place=town внутри Москвы не предусмотрен.
В матрёшке же лежит “Зеленоградский административный округ”:
http://www.openstreetmap.org/browse/relation/1320358/
Scondo, создавший указанное отношение “Зеленоград”, пишет что “возможно была завязка на выгрузки в СитиГид”.