Да, выглядит странно. Либо посыпался алгоритм (но я давно ничего не менял) либо какое-то разрушение данных (что тоже странно). Скоро добежит прогон и я подебажу на готовых данных.
Хм, посмотрел на сырых данных, ошибку не нашёл. При проверке отдельных методов получаю правильные результаты. Нужно будет дебажить основной алгоритм что более трудозатратно. Займусь проверкой завтра. А вообще это странно конечно выглядит. Во всяком случае ошибками геометрии здесь не пахнет, геометрическая вложенность отрабатывается правильно.
Может быть точка в Ладожском озере выпала за пределы области? Или база целиком валидируется, не порезанная на области?
К сожалению ошибка оказалась нетривиальной а времени на её поиск нет совсем. Чтобы сузить поиск отключил сегодня все оптимизации чтобы сделать чистый прогон … но ничего не изменилось. Похоже проблема не так катастрофична как я предположил изначально но всё равно непонятно. Буду копаться на выходных, раньше времени найти не удастся.
Ошибка нашлась в одном из оптимизационных алгоритмов … Но блин, она очень очень общая, странно что всё работало столько месяцев … Если кратко то в ряде случаев неверно считался описанный прямоугольник вокруг контура. Судя по всему это не сильно било если точки расположены рядом, единственно это срабатывало только если была очень далеко вынесена единственная точка типа как здесь - http://www.openstreetmap.org/relation/1726335 при этом и точки НП должны уходить за пределы контура описанного остальными точками.
Поправил алгоритмы, запустил пару тестов. Но полный прогон буду делать завтра, там всё выяснится … Если не сломалось чего ещё будет интересно сравнить результаты … Ошибка теоретически может проявляться на относительно большом количестве объектов (десятки).
P.S. А действительно приозёрных у поселений такие странные границы? На бумаге можно что угодно рисовать, но в реальности иметь такие границы - реально неудобно.
Багфикс - это отлично!
А границы так они их описывают и рисуют, даже на изолированных генпланах. Понятно, что в реальности эти границы по озеру никак не используются, особенно там, где нет островов. На карельской части островов больше, так там и границы осмысленнее.
Исправленный валидатор упал на проверке геометрии … поскольку не хочется править ещё не проверенный алгоритм то пока не буду разбираться в проблемах …
В общем пользователь GT21 смог сделать линию из одной точки на контуре (почему ОСМ API такое пропускает?) - https://www.openstreetmap.org/way/235968803
Соответственно Московский и Ленский районы Чебоксар стали падать при построении контура. Я поправил у себя в данных, но хотелось бы чтобы и в ОСМ не было линии с единственной точкой, при этом лежащем на outer.
Мне казалось что валидатор такое отслеживал, но сейчас разбираться уже не буду, мне сейчас важнее убедиться что проблема найденная dair разрешена.
Видимо это кривой потланчер, в JOSM как я ни пробовал линия с 1 точкой удаляется.
Догнал валидатор (после падения на точке-линии), указанная ошибка исправлена. Результат за вчера не сильно отличается от сегодняшнего: +13 НП распозналось (из них 5 НП в Ленинградской области на которых алгоритм сбоил), что в пределах статистики ежедневных правок. Так что ошибка оказалась некритичной … Но всё равно, видите ошибки - пишите. Я слежу только за глобальной статистикой и о мелких штучных ошибках могу даже не знать.
Да, там Потлач.
Границы ломаются настолько регулярно что остаётся задаться вопросом - а почему элементарные проверки на валидность мультиполигонов должны делать сторонние валидаторы … Сервер не должен принимать разрушенные данные … 21 век, блин, транзакции, целостность данных …
http://atd.osm.rambler.ru/broken.html. Сейчас Мамай ОСМеры прошлись по Тверской и Новосибирской областям.
Аннексия городским поселением 
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 минут.