Валидатор населённых пунктов и границ (http://atd.openstreetmap.ru)

Исправленный валидатор упал на проверке геометрии … поскольку не хочется править ещё не проверенный алгоритм то пока не буду разбираться в проблемах …

В общем пользователь GT21 смог сделать линию из одной точки на контуре (почему ОСМ API такое пропускает?) - https://www.openstreetmap.org/way/235968803
Соответственно Московский и Ленский районы Чебоксар стали падать при построении контура. Я поправил у себя в данных, но хотелось бы чтобы и в ОСМ не было линии с единственной точкой, при этом лежащем на outer.

Мне казалось что валидатор такое отслеживал, но сейчас разбираться уже не буду, мне сейчас важнее убедиться что проблема найденная dair разрешена.

Видимо это кривой потланчер, в JOSM как я ни пробовал линия с 1 точкой удаляется.

Догнал валидатор (после падения на точке-линии), указанная ошибка исправлена. Результат за вчера не сильно отличается от сегодняшнего: +13 НП распозналось (из них 5 НП в Ленинградской области на которых алгоритм сбоил), что в пределах статистики ежедневных правок. Так что ошибка оказалась некритичной … Но всё равно, видите ошибки - пишите. Я слежу только за глобальной статистикой и о мелких штучных ошибках могу даже не знать.

Да, там Потлач.

Границы ломаются настолько регулярно что остаётся задаться вопросом - а почему элементарные проверки на валидность мультиполигонов должны делать сторонние валидаторы … Сервер не должен принимать разрушенные данные … 21 век, блин, транзакции, целостность данных …

http://atd.osm.rambler.ru/broken.html. Сейчас Мамай ОСМеры прошлись по Тверской и Новосибирской областям.

Аннексия городским поселением :slight_smile:

fserges в JOSM есть такая проверка? Валидатор и нужен, что бы фиксить, фиксить и ещё раз фиксить : ) .Я то же по старому правил так: Наделаешь фиг значит чего- на следующее утро поправляешь - и потом всё ок.

http://atd.osm.rambler.ru/r1697847.html отсутствуют тцать сельских поселений https://ru.wikipedia.org/wiki/%D0%91%D1%83%D0%B9%D1%81%D0%BA%D0%B8%D0%B9_%D1%80%D0%B0%D0%B9%D0%BE%D0%BD

А если прочитать эту статью в википедии до конца, то можно узнать, что их всё-таки три.

Планируется ли переходить на валидацию в реальном времени (по минутным дифам)?

Давно не новость, но все таки акцентирую: Согласно закона Курской области № 34-ЗКО от 10,06,2014 поселка Северный Курского района Курской области больше не существует, он вошел в состав города Курска. На карте исправил положение вещей, теперь хотелось бы чтоб валидаторы не выдавали ошибку в связи с отсутствием поселка Северный.

Спустись на землю, до сих пор не может перейди на собственные дампы чтобы наконец Крым вошёл в состав России. Ну и технология не позволяет этого, т.к. полный проход занимает пару часов.

Какое-то время назад я думал про такую концепцию (хотя конечно речь не о минутных дифах) но понял что это совсем другой подход к проектированию валидатора. Там получаются слишком сложные для меня алгоритмы да и софт будет совсем другой. Но с другой стороны данные АТД реально не сильно меняются, в идеале достаточно нескольких обновлений в день. Технически это достижимо, валидатор полностью обрабатывает дамп за 4-5 часов, т.е. 4-5 раз в день валидатор сможет проходить. Практически это означает что должна быть выделенная машина которая в общем-то только этим и занята. Я сейчас использую свою машину в лабе но мне не хочется чтобы она всё время работала, т.к. я на ней ещё и работу работаю.

Сейчас я готовлю компромиссный вариант - делать свой дамп ночью (когда наша страна спит и данные правятся минимально) чтобы утром отчёт был бы готов. Т.е. время от момента правки до отчёта должно стать строго меньше 24 часов (разве что за исключением Дальнего Востока). В таком ракурсе можно и 2 раза в день прогонять валидатор, т.е. делать и утренний и ночной отчёты. Но для начала мне нужно хотя бы сесть за самостоятельное приготовление дампов.

Тогда предлагаю снимать дампы в 6 утра (чтобы ночные правки были) и в 6 вечера (чтобы дневные правки были). Накатка суточного дампа занимает меньше 10 минут.

Я почитал новости касаемо этого решения и похоже НП действительно упразднён а не перешёл в состав городского округа. В общем-то ничего не мешает мне просто удалить данный НП из базы. Но здесь есть тонкий и общий момент который хочется решить в более глобальном ключе. На самом деле изменения в АТД происходят регулярно и проходит некоторое время прежде чем законы просачиваются во всевозможные базы классификаторы/базы данных. Например, сейчас данные в ОКТМО по Дальнему Востоку довольно серьёзно отстают от текущего состояния, например не учтены такие изменения:

законом Магаданской области от 31.07.2014 N 1777-ОЗ в Хасынском районе упразднено сельское поселение Карамкен. Входящее в его состав село Карамкен отнесено теперь к межселенной территории Хасынского района;

и законом Магаданской области от 31.07.2014 N 1778-ОЗ в Среднекамском районе упразднено сельское поселение Село Колымское. Входящее в его состав село Колымское отнесено теперь к межселенной территории Среднекамского района.

и таких изменений на самом деле довольно много. Но здесь вступает в силу проблема синхронизации. Новый ОКТМО обновляется довольно регулярно но задержки всё равно составляют 3-9 месяцев (по моим подсчётам). Но если я удалю упраздённые элементы АТД а Росстандарт задержит обновление то при очередной синхронизации с ОКТМО удалённые поселения/НП снова будут созданы. Поэтому нужно не просто удалить а создать механизм чтобы это удаление/уточнение было бы постоянным.

Пока этим заниматься не хочется так как ОКТМО на практике показался довольно нормально обновляемым документом а ОСМеры отслеживают далеко не все изменения в АТД. Можно просто подождать пару месяцев и дождаться нового обновления ОКТМО :slight_smile:

Я ожидаю такое обновление в ближайшее время и если в этом обновлении многие из изменений не будут учтены то буду прикручивать механизм пометки данных АТД как устаревшие.

Ну моя жизнь не только из ОСМа состоит :slight_smile: Поэтому как только появится свободное время так сразу, сейчас же дела были поважнее :slight_smile:

Если вдруг (мало ли, может пригодится) я тут отслеживаю регулярно изменения АТД по ДФО в хранилище http://cloud.mail.ru/public/bc5a62323e39/ДФО, в папке Доп.инфо или прямая ссылка http://goo.gl/tNznbV.

Что-то поломали много нового - Приволжский ФО и много всего в Новосибирской области.
Детали как обычно здесь - http://atd.osm.rambler.ru/broken.html

Теперь об этом можно рассказать в discussion автору правки http://www.openstreetmap.org/changeset/26475677

Границы починены и на фоне последних дней выглядят подозрительно хорошими :slight_smile:

А тем временем у меня произошёл качественный скачок. Собственно данный валидатор начинался как внутренний проект для анализа данных по АТД которые я собирался использовать после для валидирования моих данных используемых в научной работе. В публичный проект оно вышло только по причине отсутствия каких-либо альтернатив на тот момент. Но, например, данные о координатах всех райцентров у меня были собраны сразу после появления космоснимков Гугла (и когда-то они казались детальными!), т.е. много лет назад, но с тех пор качество мною не перепроверялось.

Теперь же наконец-то руки дошли до стыковки моей базы данных и валидатора и я наконец-то смогу проверить или точность/полноту моих данных или точность/полноту данных ОСМа. А это меняет подход к валидатору. Если раньше это был чисто академический проект - не все жёлтые НП распознались - ну и ладно, валидатору интересны только “зелёные” НП то теперь для валидации моих данных нужна более точная обработка “жёлтых” НП. Поэтому обнаружив что в отчёте “жёлтые” НП заданы или точками или контурами пришлось поискать ошибку. Их оказалось несколько, но в результате теперь и “зелёные” и “жёлтые” НП описаны как нодами там и веями.

В общем теперь валидатор будет иметь большее для меня значение чем раньше, поэтому стоит ожидать определённых улучшений в нём. Хотя далеко уходить за пределы работы с АТД/НП я и не собираюсь - данная область не относится к области моих научных интересов а время как известно ресурс дефицитный.