А ещё, порядка 50 сельских поселений было удалено за последние дни. Где-то (особенно в Вологодской области) показатели просели сильно.
Возможно по тому, что точки находятся ровно в 180.0, попробуй в полигоне обрезки сделать границу 180.01
А также почему-то отсутствуют линии:
http://www.openstreetmap.org/way/134546604
http://www.openstreetmap.org/way/23824393
http://www.openstreetmap.org/way/239992379
(это линии содержащие точки -180).
Всё же мне это напоминает багу в osmconvert. Почему-то в старой версии osmconvert (год или 2 назад) проблем с этим poly файлом не было, а сейчас есть. Как-то несимметрично обрабатывается antimeridian - если +180.0000 - то точки/линии попадают в обрезку, если -180.0000 то точки/линии выбрасываются. Соответственно такая фигня у меня и судя по всему на ГИС-Лабе.
Остаётся попробовать обходной путь предложенный - freeExec. Явно кривое решение, но мне нужен правильный дамп а не красивое решение … Попробую завтра. Может с этим обходным путём другие проблемы всплывут
Остаётся попробовать обходной путь предложенный - freeExec. Явно кривое решение, но мне нужен правильный дамп а не красивое решение … Попробую завтра. Может с этим обходным путём другие проблемы всплывут
Сходу JOSM отверг такой poly-файл, сказал что точки “оказались за пределами мира” поэтому им перемещены (т.е. автоматически исправлены в 180.000000). Посмотрим что скажет osmconvert.
Возможно по тому, что точки находятся ровно в 180.0, попробуй в полигоне обрезки сделать границу 180.01
Собственно таким образом полученный дамп прошёл через валидатор без проблем. Точнее, +180.00000 обрабатывается osmconvert нормально, т.е. все линии и точки попадают в обрезку, но -180.00000 не отрабатывает, т.е. нужно ставить -180.00100
Предложения.
- Предлагаю доопределить первый уровень деления Федеральных городов (Москва, СПБ, Севастополь) кодами из ОКАТО, также как это сделано в ТЕРСОН-МО (коды ТЕРСОН приведены в справочнике по численности населения).
- Также не попали в административное деление управленческие округа Свердловской области и Бежтецкий участок, хотя им соответствуют объекты OSM, можно сгруппировать хотя бы по ним адм. единицы следующего уровня.
Вопросы.
Что можно предпринять, чтобы раз и навсегда устранить нелепые ошибки в делении. Начнем с того, что видно сразу.
а) Например, внутри города Балашиха почему то есть еще один город и сельские населенные пункты, продублированные в правильном месте.
б) Муниципальный округ Кунцево в Москве отсутствует в Западном административном округе, и висит выше уровнем под именем района Кунцево.
в) Амурская область. OSM объект ЗАТО Углегорск не ассоциируется с ОКТМО ЗАТО Циолковский.
г) Циолковский назван населенным пунктом, хотя у него есть код ОКТМО (почему-то здесь не указан), из которого однозначно следует, что он город (номера населенных пунктов 001-049 города, 051-099 пгт, 101 и далее сельские НП - это бы неплохо автоматизировать). Ранее он был Углегорском и впридачу поселком, как бы это указать?
P/s/ Я понимаю, что организационно эти вещи исправляются в josm довольно просто. Но то, что они существуют уже давно - это бага или фича? Какие именно исправления этих и им подобных ошибок не будут запилены под корень?
^^ Выше ошибки из ОСМ, возможно уже исправлены …
Обновился ОКТМО. В этот раз минимально - пара сельских поселений Ленинградской области стали городскими поселениями (нонсенс для последних лет), два малонаселённых поселений упразднено (Архангельская и Иркутская области). Также упразднено небольшое количество сельских НП.
При следующем обновлении валидатора подхватится последний классификатор. Только теперь валидатор обновляется несколько раз в неделю, поэтому трудно точно сказать когда это случиться. “На днях” будет самое точное.
Поскольку долго никто не спрашивает то отвечаю
Валидатор временно работает в режиме 1-2 обновления в неделю. И для этого есть важные причины. Ранее валидатор прекрасно работал на работе в утреннее/ночное время, к моему приходу на работу всё или отрабатывало или заканчивало работу. Но всё хорошее когда-либо кончается. Я потерял работу, валидатор был остановлен, запускался из дома. Новая работа нашлась довольно быстро, но там нет возможности ставить какой-либо сторонний софт - отключены USB, забанены GitHub, ftp, ssh, почтовые сервисы, мессенджеры и т.д. и т.п. Даже JOSM не запустить, нет коннекта с сервером. Вариант с ежедневным запуском на работе отсутствует в принципе.
Но как говорится, “беда не приходит одна” и помимо всего прочего пришлось съехать с хорошей квартиры в тесную однушку в которой физически нет места чтобы поставить стационарный компьютер. Поэтому единственная возможность сейчас - гонять валидатор с маломощного ноутбука по выходным, чем я и занимаюсь.
Технически валидатор - легко переносимая вещь. Это образ в VirtualBox, т.е. развёртывание на новой машине это вопрос десятков минут. Но сейчас вопрос в том что развёртывать особо негде
Однако ситуация не выглядит безнадёжной. Через несколько месяцев мы должны будем перебраться в более комфортабельную квартиру и тогда валидатор будет запускаться более регулярно. Но пока будет текущий режим - один, может два раза в неделю. Т.е. валидатор жив, но обновляется не так часть как раньше.
Вопросы по развитию валидатора, понятно, не стоят. Это будет уже следующий шаг и точно не в этом году.
Но пока будет текущий режим - один, может два раза в неделю.
Это гораздо лучше чем вообще никак). Пользуюсь регулярно, очень нужная вещь. Учитывая, что альтернативный валидатор почти всё лето не обновлялся… спасибо, что поддерживаете всё равно свой независимо от жизненных обстоятельств!
С альтернативным почти та же история.
С рабочего убрал, ушел в отпуск, поставил на домашний, опять отпуск, переставил дома на другой.
Теперь все настроил и в выходные погонял. Восстановил работу через обновления, а не дампы.
Но всё равно - запуск по пинку по приходу с работы.
Вопрос по Казахстану. А когда в последний раз обновлялись по нему исходные данные?
А то наносишь нас.пункт, а он ликвидирован, или переименован.
И получается ошибка остается :(
Так не надо мапить под валидатор. Нет, так нет.
Я не маплю под него :).
Просто хотелось знать как часто обновляется то с чего берутся данные
Вопрос по Казахстану. А когда в последний раз обновлялись по нему исходные данные?
А то наносишь нас.пункт, а он ликвидирован, или переименован.
И получается ошибка остается :(
Валидатор Вовика 21 сентября последнее обновление
http://wowik.000space.com/places/kz/
Что касается ликвидированных населенных пунктов - не беда что их нет в КАТО, если есть жилые дома то лучше оставлять. С переименованными конечно веселее ))
Ликвидированые НП я обычно переделываю в place=isolated_dwelling (если наблюдается движуха) или was:place=hamlet
Понадобится людям посетить могилки предков - уже помощь.
Ликвидированые НП я обычно переделываю в place=isolated_dwelling (если наблюдается движуха) или was:place=hamlet
Почему не в place=locality + abandoned:place=hamlet?
Поскольку валидатор стал запускаться реже, то и ошибки стали повторяться чаще, что стало приводить к падению валидатора. За две недели так и не смог прогнать ни разу.
Первая ошибка - были массово включены relation которые не имели роли, хотя судя по всему предполагались как subarea. Валидатор трактовал роли в relation как outer и далее глючил. Вроде исправил всё.
Сейчас упал на таких данных:
name = Балта
place = village
source = [Redirect Notice
Какие ограничения длину строки у нас? Здесь 255 символов.
O! mosstreet лепит урли прямо с гуглевским редиректом
Его отрезали по максимуму, плюс место для нулевого бита. Будет 256 байт?
Будет 256 байт?
Только не байт, а символов, так как храниться в UTF-8.
O! mosstreet лепит урли прямо с гуглевским редиректом
Ага, в результате URL был обрезан и перестал быть валидным. Поправлю. А то source=google.ru несколько пугает
Валидатор таки обновился, но пока результат не красивый. Типовая ошибка - люди добавляют эксклавы для поселений/районов и забывают что эксклавы нужно проставлять и в областях/федеральных округах тоже. Я исправил, на выходных перепрогоню ещё раз.