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

Когда обновление данных ?

Валидатор важный и нужный.
Но что-то он меня загнал в тупик:
http://atd.osm.rambler.ru/r405899.html
Малоярославецкий район красный весь. Ошибка валидатора?

Опять же, НП (place=*) где есть только полигональная граница - это ошибка или ОК? А точка без границы?

И то, и другое ошибка.

Для данного валидатора важна полная иерархия АТД. А в данном случае отсутствуют все сельские поселения:

В ОСМ есть только городское поселение.

Не все крупные города, а практически все НП Краснодарского края не учитываются этим валидатором из-за того, что у нас отсутствуют границы поселений.
Валидатор CupIvan’а данный момент не учитывает, так как валидирует именно точечные центры НП по данным википедии.

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

Поскольку сейчас бета то главный интерес к доводке самого валидатора нежели к регулярности обновления. Я постоянно чего-то там правлю в результате валидатор иногда “ломается”. Поэтому обновления будут относительно регулярными. Я постараюсь обновлять раз в 2 дня, но говорить что будет работать как часы не могу - валидатор может сломаться в неожиданном месте.

Кстати сейчас я загрузил ночную выгрузку с ГИС-Лаба, так что сегодня вечером (тьфу-тьфу-тьфу) должен обновиться. Если будет всё нормально то потом обновлю в воскресенье. Если делать чаще то мне это будет мешать допиливанию валидатора.

Коллеги, позволю себе напомнить про предложение использовать тег oktmo:user для явного указания значения ОКТМО. Это позволит: а) устранить проблему расположенных рядом одноимённых населённых пунктов, б) сокращений (СП <-> сельское поселение), в) вариативных форм записи (“город Старая Русса” <-> Старорусское городское поселение), г) поселений со специфическим статусом (посёлок при станции).

Это уже в следующих версиях :slight_smile: Тут с поселениями бы разобраться …

У меня к сожалению до этого пока руки не дошли, но в отличие от разработчика прежнего валидатора я лоялен к простой простановке кода ОКТМО, т.е. oktmo=xxxxx вместо oktmo:user=xxxxx. Аргументация почему oktmo плохо а oktmo:user хорошо для меня является слабой.

Сокращения “СП” и “ГП” валидатор вполне понимает и отрабатывает, но более честным конечно является ведение official_status или аналога где хранить статус и не засорять им name.

Вариативность форм записи будет пониматься на двух уровнях. С одной стороны я у себя в БД храню поле “альтернативное название” если оно довольно официальное. С другой стороны, я планирую использовать alt_name в ОСМ.

Поселения со сложным префиксом будут хранить значения в поле типа name:prefix (вот только не нужно утверждать что “посёлок” и “посёлок при станции” это разные статусы населённых пунктов!) - это будем обсуждать.

Подводя итог: хочется минимизировать использование oktmo:user, хотя его использование валидно. Пользователь ОСМа из Германии должен просто распарсить выгрузку не обращаясь к каким-то внешним данным. Но наличие oktmo не является проблемой. Код всё равно будет проверяться валидатором и в случае его смены (из-за смены а в АТД) будет отловлен валидатором.

Т.е. одна из главных идей валидатора - вся информация должна браться из тегов и геометрии. Ничего более, но теги будут иметь более высокий приоритет над геометрией так как ошибочно испортить геометрию гораздо проще чем случайно изменить теги точки.

oktmo:user
okato:user
kladr:user

Просто потому что эти теги массово расставлялись для прошлого валидатора и являются де-факто стандартом. Не нужно, пожалуйста, плодить третьей схемы (вспомним cladr:code).

Они устарели и теперь другие. Прежняя схема умерла.

Вы в свою очередь вовсе не представляете аргументов для введения новой схемы.

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

Не умерла ещё и самая первая схема. Схемы не умирают. Есть десятки тысяч тегов в прежней схеме, не одну сотню проставил я сам. Делать всю эту работу заново неохота. Зачем засорять базу? А её засоряют не обычные мапперы, а вот такие программисты — которым просто лень через правку двух-трёх строк сохранить преемственность.

А что у нас является объектами admin_level=9? Я попробовал обработать объекты admin_level=9 среди которых районы городов (в частности Ульяновска) и поймал огромный список suburb. Куча объектов типа такого:

Если такого рода объекты валидны (т.е. что городские районы что suburb являются admin_level=9) то тогда я буду просто отбрасывать place = suburb не глядя на admin_level.

Данные для валидатора обновились … Только вот файерволы не дают мне выложить результат. Выложу позднее вечером из дома.

не подхватывает isolated_dwelling и place (н.п. с population=0) с названиями вроде “хутор Заросший (нежилой)” или “руины хутора Пустой”

http://atd.osm.rambler.ru/r2588411.html
http://www.openstreetmap.org/browse/node/1580986363

так же везде использовал okato:user.

Правильно, таких названий быть не должно. Но вот place=locality должен подхватывать (его нужно использовать для исчезнувших деревень, ещё числящихся официально и isolated_dwelling, разумеется, тоже.

Да, isolated_dwelling не включён в фильтр, поправлю. Когда перепроверял результаты то смотрел в тех местах где их не было.

Upd: слово (нежилой) нужно будет отбрасывать на этапе сопоставления.