Коллеги, позволю себе напомнить про предложение использовать тег oktmo:user для явного указания значения ОКТМО. Это позволит: а) устранить проблему расположенных рядом одноимённых населённых пунктов, б) сокращений (СП <-> сельское поселение), в) вариативных форм записи (“город Старая Русса” <-> Старорусское городское поселение), г) поселений со специфическим статусом (посёлок при станции).
У меня к сожалению до этого пока руки не дошли, но в отличие от разработчика прежнего валидатора я лоялен к простой простановке кода ОКТМО, т.е. oktmo=xxxxx вместо oktmo:user=xxxxx. Аргументация почему oktmo плохо а oktmo:user хорошо для меня является слабой.
Сокращения “СП” и “ГП” валидатор вполне понимает и отрабатывает, но более честным конечно является ведение official_status или аналога где хранить статус и не засорять им name.
Вариативность форм записи будет пониматься на двух уровнях. С одной стороны я у себя в БД храню поле “альтернативное название” если оно довольно официальное. С другой стороны, я планирую использовать alt_name в ОСМ.
Поселения со сложным префиксом будут хранить значения в поле типа name:prefix (вот только не нужно утверждать что “посёлок” и “посёлок при станции” это разные статусы населённых пунктов!) - это будем обсуждать.
Подводя итог: хочется минимизировать использование oktmo:user, хотя его использование валидно. Пользователь ОСМа из Германии должен просто распарсить выгрузку не обращаясь к каким-то внешним данным. Но наличие oktmo не является проблемой. Код всё равно будет проверяться валидатором и в случае его смены (из-за смены а в АТД) будет отловлен валидатором.
Т.е. одна из главных идей валидатора - вся информация должна браться из тегов и геометрии. Ничего более, но теги будут иметь более высокий приоритет над геометрией так как ошибочно испортить геометрию гораздо проще чем случайно изменить теги точки.
Просто потому что эти теги массово расставлялись для прошлого валидатора и являются де-факто стандартом. Не нужно, пожалуйста, плодить третьей схемы (вспомним cladr:code).
Ну так у меня жёсткий аврал на работе, мне некогда вести длинные споры. А спорить можно практически за каждую строку алгоритмов. Всё будет и всему своё время. Я выложил бету но нигде не сказал что это окончательный продукт. По-понемногу будет всё и скоро придёт в норму. А пока просто общие мысли - что будет критично а что нет. В конце концов споры и нужны чтобы оттачивать решения. Ну не торопите события, пожалуйста!
Не умерла ещё и самая первая схема. Схемы не умирают. Есть десятки тысяч тегов в прежней схеме, не одну сотню проставил я сам. Делать всю эту работу заново неохота. Зачем засорять базу? А её засоряют не обычные мапперы, а вот такие программисты — которым просто лень через правку двух-трёх строк сохранить преемственность.
А что у нас является объектами admin_level=9? Я попробовал обработать объекты admin_level=9 среди которых районы городов (в частности Ульяновска) и поймал огромный список suburb. Куча объектов типа такого:
Если такого рода объекты валидны (т.е. что городские районы что suburb являются admin_level=9) то тогда я буду просто отбрасывать place = suburb не глядя на admin_level.
Правильно, таких названий быть не должно. Но вот place=locality должен подхватывать (его нужно использовать для исчезнувших деревень, ещё числящихся официально и isolated_dwelling, разумеется, тоже.
я понимаю, что name для нп должен быть без приставок вроде “(нежилой)” или “руины”. но с другой стороны можно рассуждать так: place применяется ещё для обозначения “именнованного места”. и когда мы видим пустырь или руины, урочище. ближе к этому оказывается широкое значение place, т.е. именованное место, а не НП. (это совсем не похоже на НП. это именно руины, возможно, заросший фундамент) и когда мы это трактуем как “именованное место” то у нас нет ограничений на название, какое бы мы имели в случае трактовки в качестве НП без населения.
На мой взгляд это явно должно быть где-то в name - alt_name, например. (нежилой) это помета а не часть имени, но для ориентирования на картах может быть полезным.
ок. а если это просто пустырь и даже фундамента не осталось ? всё так же называть это хутором ? или может быть селом ? учитывая принцип - что на местности, то и на карте, нельзя же пустырь или холмик хутором назвать, как и развалины старой церкви нельзя церковью назвать.
Нет, alt_name это то же самое что name, для случая когда бывают разночтения названия, и также не допускает приписок.
Если даже фундамента не осталось, place меняется на locality, название же никто не менял. По сути, и некому.
Ещё я тут подумал насчёт okato/okato:user, и очень прошу отказаться от его использования в валидаторе вообще. Наша цель - создать качественный набор данных, который можно использовать самостоятельно, соответственно нужно обеспечить полноту информации и иметь возможность различать НП с одинаковыми названиями по объективным свойствам - для начала по статусной части. Возможность заткнуть валидатор, показывающий реальную ошибку - неразличимость НП в данных либо неправильное название, проставив okato:user - это очень и очень плохо. Случаи где без кода (сейчас) реально не обойтись нужно собрать и подумать что с ними делать. В самом крайнем случае это будет явный список, только для НП из которого допустимо использовать коды.
В данном случае я нигде не нашёл, что городской округ делится на административные районы. Так что это чья-то фантазия и теги admin_level = 9 и boundary = administrative лишние.
По сути если должно быть 2 НП с одни названием и в осм мы имеем 2 НП с одни названием, то стоит предположить что это они и есть. Если их 1 или 3, то значит все 1/3 неправильные.
Валидатор обновился на утренний дамп. Принципиальных изменений нет, просто прогон на новых данных. Из нового - попробовал перейти на pbf → osmconvert → osm. Всё вроде нормально, но получилась ерунда с кавычками, нужно разбираться на каком этапе это происходит.