Пока locality трогать не буду. Как известно, им в СПб и кладбища отмечают, там нужно штучно разбираться. По логике нужно к locality добавить что-нибудь типа was:locality=hamlet чтобы отличать абстрактное locality от останков населённого пункта.
Про Ё я уже ответил - на выходных.
Да, спасибо, пойдёт Когда будет следующая выгрузка (завтра или послезавтра - ведь у нас же БД сейчас на ТО) жёлтым будут отмечаться НП которые не попали в правильные сельские/городские поселения, но попали в правильный район. Т.е. в отчётах будет преобладать жёлтый а не красный
А потом нужно будет пиктограммки на разные типы ошибок заводить. В общем валидатор ещё пилить и пилить.
Обработка статусных частей это следующий этап. Я более-менее подготовил технический алгоритм, но что и как писать в ОСМе - это вопрос который требует некоторого обсуждения и следовательно времени. Думаю через пару недель этим займусь - раньше у меня совсем запары будут …
А слово “посёлок” валидатор кстати не требует - “посёлок” пишется в городских поселениях (хотя и там он не требуется). Проблема в другом - в результате муниципальной реформы были придуманы городские поселения, в которые могут входить как сами пгт так и другие населённые пункты. Но “пгт Петрово” и “городское поселение Петрово” суть разные объекты. “пгт Петрово” это place=village (скорее всего) с тегом official_status=ru:пгт а “городское поселение Петрово” это admin_level=8, official_status=ru:городское_поселение. Это две близких но разных сущности. В ОСМ они по привычке смешаны. Про это и wowik говорил.
А расскажи подробнее про алгоритм для статусных частей. На самом деле на границах нужно требовать явного указания полного названия со статусной частью - так для сверки нужно всего два сравнения: ==“<статусная часть> <название>” и ==“<название> <статусная часть>”. На place, понятно, в name только название, одинаковые названия различаются по official_status и/или full_name. Не думаю что послабления в этой схеме допустимы.
Кстати, откуда всё-таки эталонная база? Я вот заметил следующую штуку (к вопросу о опечатках): часто есть деревни с разночтением названий (Спас vs. Спасс, Большое Софроново vs. Большое Сафроново, Маковицы vs. Маковницы), при этом в большинстве карт используется название (условно) A, но в кадастре - название B. Так вот в валидаторе также используется B, и возможно есть основания доверять ему больше чем <большинству карт>. Под большинством карт здесь подразумевается подложка росреестра, яндекс, навител и гармин, под кадастром - информация о кадастровых участках с того же росреестра. Хотелось бы на эту тему услышать комментарии Zkir и Sergey Astakhov.
Я думаю он всё-таки не с потолка их вносит и данные у него наиболее приближенные к администрации. Уж точно не к говнокартам, если уж кадастр с ними не совпадает.
Всё, отработал новый прогон и первый анализ говорит что результаты стали лучше. К сожалению, выложить я пока не могу, т.к. выяснилось что на работе заблокированы как ftp так и ssh наружу, т.е. результаты станут доступны поздно вечером когда я это сделаю из дома.
Из новшеств:
Был запущен был оптимизированный а не стандартный алгоритм, в результате чего самая долгая часть его работы ускорилась на 2 часа, а это существенный прирост производительности. Теперь всё время работы валидатора стало строго меньше чем рабочий день, т.е. проблем с его регулярным обновлением быть не должно (за исключением того что нет ftp или ssh). Ошибок не было обнаружено.
Были найдены недостающие муниципальные районы и сельские поселения (раньше часть из них отсутствовала). Осталось только несколько НП находящихся в межселенных территориях - ими займусь позже
Добавился жёлтый статус, т.е. НП распозналось на уровне района а не на уровне поселения. Красным цветом выделены НП которые не удалось сопоставить (включая правда и НП с одним названием - это ещё нужно обрабатывать). И да, цвета теперь используется предложенные zetx16
Немного подкрутил сопоставление поселений
По сравнению со вчерашним прогоном сопоставилось на 600 НП больше.
Нет, это связано с тем что точки и полигоны обрабатываются разными алгоритмами Я вчера не хотел лезть в алгоритм с точками так как разбирался с оптимизационным алгоритмом и не хотел лишних изменений.
Потому что это валидатор полноты АТД в ОСМ. То есть наличие сельских/городских поселений является обязательным. С сегодняшней версии сопоставляются (выделяются жёлтым) и просто НП, без поселений, но в статистику “совпало” не попадают. Добавьте поселения и процент сразу резко вырастет.
Происхождение базы сложное, но для простоты можно считать что это ОКТМО, хотя и допиленный руками. Ранее это был ОКАТО, но допил был более серьёзный.
Процедуру устранения разночтения названий я вижу так. Если название в эталонной БД неверное (обычно это опечатки) то я исправляю у себя сам. Если название имеет вариации, то нужно использовать alt_name (пока не обрабатывается но в ближайших планах). Аналогичное поле заведено и у меня в БД, но в этом случае потребуется моё участие. Второе название можно будет отображать рядом с первым (для справки). Но такого рода вещи лучше обсудить, чтобы понять какое решение более разумное.