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

все крупные города краснодар.края красные, что это значит?

Только не “имя”, и так путаница (и на карте, и в головах), где НП, а где административное образование с тем же названием.

Для полноты стоило бы ещё подумать, что делать с отдельно расположенными военными городками. В ОКАТО их в основном нет, но их перечни открыто опубликованы отдельно. Например, ФСО: http://www.zakonprost.ru/content/base/part/430476

А стоит ли из-за 10 штук особо парится, пусть так и висят на уровне района.

Это из-за “**МО город **Армавир”, мы это обсуждали в ветке про Краснодарский край. Поскольку обсуждение не закончилось (меня не переубедили, я не переубедил) то пока остаётся так.

В этом перечне только ФСО-шные. А бывают ещё (и гораздо больше) у МО, у МВД, у ФСБ и фиг знает ещё у кого

ЗЫ
Вот список побольше: http://voengor.ru/perechen_zakrytyh_voennyh_gorodkov.php

Что писать в name это вещь которая обсуждается. По-хорошему это “Мичуринское сельское поселение”. Вариант “Мичуринское СП” также распространён, но он нарушает принцип ОСМ do not abbreviate хотя и однозначно идентифицирует объект. Вариант “Мичуринское” требует чтобы поле official_status (или аналогичное, будем обсуждать) хранило бы в себе фразу “сельское поселение”, поскольку иначе парсерам непонятно, что это - городское поселение, сельское поселение или какая-то ошибка.

При этом надо не забывать что вариативность названий сельских поселений поддерживается и на официальном уровне. Например название “Сельское поселение Александровский сельсовет” является вполне типичным как и Сельское поселение Алексеевская волость. Кстати именно поэтому мне не нравится кривое использование тега official_status. Для сельского поселения Александровский сельсовет именно “сельское поселение” является статусом а “сельсовет” частью названия, хотя из описания official_status можно понять и так и так. Поэтому я по-прежнему активный противник кривого использования official_status.

Как раз статусы муниципальных образований сравнительно легко выпрямить валидатором. Они известны, поддержаны законодательством и действительно присваиваются официально. Это бы имело практическую пользу (в отличие от расстановки ё по псевдоэталонному списку).

Ну там по списку в 90% случаев адрес до НП. Если он геометрически не в НП, то по-идее addr:city/place=* должен помочь.

Кривой тег или кривое название тега ?

Zkir, перфекционизм не знает границ :slight_smile: И статусы поправим и с “ё” разбереёмся. Раз уж я взялся за это дело будем пилить пока золото не найдём :slight_smile:

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

Валидатор важный и нужный.
Но что-то он меня загнал в тупик:
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 не является проблемой. Код всё равно будет проверяться валидатором и в случае его смены (из-за смены а в АТД) будет отловлен валидатором.

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