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

Это уже в следующих версиях :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: слово (нежилой) нужно будет отбрасывать на этапе сопоставления.

я понимаю, что name для нп должен быть без приставок вроде “(нежилой)” или “руины”. но с другой стороны можно рассуждать так: place применяется ещё для обозначения “именнованного места”. и когда мы видим пустырь или руины, урочище. ближе к этому оказывается широкое значение place, т.е. именованное место, а не НП. (это совсем не похоже на НП. это именно руины, возможно, заросший фундамент) и когда мы это трактуем как “именованное место” то у нас нет ограничений на название, какое бы мы имели в случае трактовки в качестве НП без населения.

но это тема для другой ветки.

Вне зависимости от интерпретации, именованое место - “хутор Заросший”. Остальное - его свойства, которые почему-то добавляются к названию.

На мой взгляд это явно должно быть где-то в name - alt_name, например. (нежилой) это помета а не часть имени, но для ориентирования на картах может быть полезным.

ок. а если это просто пустырь и даже фундамента не осталось ? всё так же называть это хутором ? или может быть селом ? учитывая принцип - что на местности, то и на карте, нельзя же пустырь или холмик хутором назвать, как и развалины старой церкви нельзя церковью назвать.

церковь:
http://www.pravoslavie.ru/sas/image/100280/28054.b.jpg

хутор:
http://4.bp.blogspot.com/_PM0oZANy5eE/SnFXkNqodJI/AAAAAAAAAkA/6Sq99e6EDsM/s1600/IMG_4349.jpg

в том и дело, что это уже не церковь и не хутор. а руины или местность с названием. а то, что было раньше - это свойство.

Нет, alt_name это то же самое что name, для случая когда бывают разночтения названия, и также не допускает приписок.

Если даже фундамента не осталось, place меняется на locality, название же никто не менял. По сути, и некому.

Ещё я тут подумал насчёт okato/okato:user, и очень прошу отказаться от его использования в валидаторе вообще. Наша цель - создать качественный набор данных, который можно использовать самостоятельно, соответственно нужно обеспечить полноту информации и иметь возможность различать НП с одинаковыми названиями по объективным свойствам - для начала по статусной части. Возможность заткнуть валидатор, показывающий реальную ошибку - неразличимость НП в данных либо неправильное название, проставив okato:user - это очень и очень плохо. Случаи где без кода (сейчас) реально не обойтись нужно собрать и подумать что с ними делать. В самом крайнем случае это будет явный список, только для НП из которого допустимо использовать коды.

В данном случае я нигде не нашёл, что городской округ делится на административные районы. Так что это чья-то фантазия и теги admin_level = 9 и boundary = administrative лишние.

По сути если должно быть 2 НП с одни названием и в осм мы имеем 2 НП с одни названием, то стоит предположить что это они и есть. Если их 1 или 3, то значит все 1/3 неправильные.

Валидатор обновился на утренний дамп. Принципиальных изменений нет, просто прогон на новых данных. Из нового - попробовал перейти на pbf → osmconvert → osm. Всё вроде нормально, но получилась ерунда с кавычками, нужно разбираться на каком этапе это происходит.

Из добавленного вчера не опознались два СП:

Уницкое тут: http://atd.osm.rambler.ru/r570637.html
Отрадновское тут: http://atd.osm.rambler.ru/r959859.html

в данных на вид всё нормально, остальные СП добавленные одновременно с этими нормально обработались.