Достаточно вашего желания выложить код, а древний он или нет уже сообщество решит. Пропадете вы, пропадет и валидатор, так же как в истории, которую вы рассказали. Оставите после себя вклад?
2 Likes
Почти всегда проще начинать глядя на что-то. Там наверняка учтены какие-то неочевидные моменты, которые в новом валидаторе не факт, что будут замечены.
Крымов в ОСМ аж три штуки:
Как банки и сотовые операторы, то есть никак? С очень большой вероятностью получим войну правок и откатов.
Украина Крым
60199 Граница Украины admin_level2
72639 Автономная республика Крым admin_level4
1574364 Севастополь admin_level4
1574578 Ялтинский городской совет admin_level6
1581042 Евпаторийский городской совет admin_level6
1754551 Алуштинский городской совет admin_level6
1754563 Судакский городской совет admin_level6
1754565 Феодосийский городской совет admin_level6
2521179 Яны Капу admin_level6
2865044 Керченский городской совет admin_level6
2865835 Джанкойский городской совет admin_level6
2865940 Армянский городской совет admin_level6
2866057 Симферопольский городской совет admin_level6
2866058 Сакский городской совет admin_level6
Россия Крым Relation: Republic of Crimea (3795586) | OpenStreetMap
60189 Россия
3795586 Республика Крым admin_level4 RU
3788485 Севастополь admin_level4 RU
3826844 городской округ Алушта admin_level6 RU
3826845 городской округ Армянск admin_level6 RU
3826847 городской округ Джанкой admin_level6 RU
3826848 городской округ Евпатория admin_level6 RU
3826851 городской округ Керчь admin_level6 RU
3826854 городской округ Красноперекопск admin_level6 RU
3826856 городской округ Саки admin_level6 RU
3826860 городской округ Симферополь admin_level6 RU
3826864 городской округ Судак admin_level6 RU
3826882 городской округ Феодосия admin_level6 RU
3826900 городской округ Ялта admin_level6 RU
1 Like
Я про это и писал. Городские округа имеют addr:country=RU, потому что этого типа данных нет в UA. Там другая схема АТД. А вот районы все сплошь addr:country=UA поскольку имеют смысл в UA. В результате получаем: Республика Крым - валидатор НП и АТД (ОСМ)
Нет районов в Крыму в валидаторе!
Так проще прочитать алгоритм а не код. Я напишу алгоритм после того как наведётся порядок в валидаторе с Крымом. Валидатор использует закрытую БД, принцип которой очень отличается от PostGIS. Поэтому смотреть код будет запутывать а не упрощать. А алгоритм будет описывать действия, которые нужно делать, что в нынешней системе, что в PostGIS.
Явный вандализм, мой алгоритм также ругается. Раньше в Крыму было 2 вида объектов:
- “Общие” объекты (которые входили в обе “структуры”), в этом случае адресных тегов (
addr:country=*,is_in:country=*,is_in:country_code=*) не было, при этом основное названиеname=*было на русском языке. - Отдельные объекты для русского и для украинского языков (там, где отличается название, теги или состав отношений). В этом случае каждый использовал тот объект, который ему нужен.
Внезапно Mazda05 делает значительные изменения, при этом без какого либо обсуждения портя данные российских пользователей:
- Исключает все “общие” объекты из Республики Крым (см. снимок экрана ниже), которые посчитал “неправильными”, не стал восстанавливать российский Крым, при этом делает вымышленные изменения, которые не подтверждаются “на земле” (потребители данных потеряли те данные, которые нужны для нормальной работы своих систем, считаю это вандализмом).
- Все “общие” объекты (которые ранее входили в оба отношения), исключённые из российской Республики Крым, ставит адресные теги (
addr:country=UA,is_in:country=Ukraine,is_in:country_code=UA), что является нарушением Протокола заседания рабочей группы/DWG 2014-06-05 Специальный выпуск по Крыму, пункт 2. - Меняет названия на украинские (нарушение пункта 3).
- Комментарии к наборам правок также однотипные, что является нарушением пункта 4.
Исходя из этого прошу DWG отменить все эти правки как вандальные.
2 Likes
Согласен. Ждём тогда ответа.
Это проблема, как я понимаю, займёт какое-то время, тогда я напишу про валидатор.
Как написан валидатор
Он написан 12 лет назад и с тех пор почти не изменялся. А тогда данные были другие. Поэтому если будете писать новый валидатор, вполне возможно будет использовать более узкий массив информации.
ОКТМО
Сначала мы использовали классификатор ОКАТО, но к моменту создания валидатора ОКТМО стал более-менее качественным. В 2016 году он приобрёл нынешнюю удобную форму. Он обновляется 12 раз в году, его можно скачать с сайта Росстата. Он идёт к формате CSV, на первый взгляд он выглядит туманно, но поработав с ним вы привыкнете.
К ОКТМО относятся 2 таблицы: ОКТМО которые содержат населённые пункты и сами населённые пункты.
В таблице ОКТМО перечислены, например, все районы и сельские поселения. Там поля код ОКТМО, название, родительский ОКТМО, центр, название в файле. Названия в файле порой приведены в странном виде, название ОКТМО часто правится, поэтому важно иметь два поля с названием и названии в файле.
Поле название сортировка. В ОКТМО честно говоря данные забиты как попало, поэтому сортируются с использованием этого поля. Название 2 - на случай расхождения названия в ОКТМО и ОСМ.
ОКТМО часто включает изменения с запозданием. Если в ОСМ он изменён, а в ОКТМО нет, используется код ОКТМО новый. Подавляющее большинство изменений - объединение. Значит в упразднённый ОКТМО пишем здесь код объединённого.
Типы ОКТМО
В этой таблице перечислены все типы ОКТМО - районы, сельские поселения и т.п. Это сделано для удобства, но вы можете использовать это.
1 Like
ОКТМО НП
Перечислены все населённые пункты.
Код ОКТМО родительский - в составе какого ОКТМО он включён. Код ОКТМО - какой код ОКТМО у НП, название, тип (город, деревня), название в файле (аналогично таблицы ОКТМО на случай неправильности имени), название 2 (аналогично таблицы ОКТМО).
Упразднён - на случай если НП был упразднён но болтается в ОКТМО.
Код ОКАТО родительский - про это напишу позже. Это скорее историческое поле, сейчас ого исползуется только для городских районов.
1 Like
ОКАТО и ОКАТО НП
В момент создания валидатора был очень важным источником данных. Но с 2016 года почти не используется. Берутся только регионы и городские районы/округа. И прописываются в таблице ОКТМО НП.
Регионы можно хранить в ОКТМО, а городские районы/округа выбросить. Это на ваше усмотрение.
Также состоит из 2 таблиц: ОКАТО и ОКАТО НП. Поля очень похожие на ОКТМО, поэтому приводить не буду.
Раз в месяц прилетает новый обновлённый ОКТМО, ОКАТО меняется немного реже. Я скачиваю данные в таблицу ИМПОРТ и вношу изменения сначала в ОКАТО, потом в ОКТМО. Всё зависит от месяца. Иногда импорт занимает час времени, иногда несколько суток.
Федеральные округа
Они меняются очень редко. Можно вообще не использовать, но это часть ОСМ. Код округа, название, центр.
Код федерального округа проставляется в таблице ОКАТО, поскольку информация о регионах берётся из этой таблицы.
АТД
Я описал таблицы, которые используются для поддержке и правки. Но для валидатора слишком много таблиц. Вместо этого автоматически генерится супер-таблица, которая содержит всю требуемую информацию.
Используется admin_level. 2 = Россия, 3 = федеральные округа, 4 = регионы и т.п. Населённые пункты не используют admin_level, поэтому я проставил код которого точно нет в ОСМ - 98.
Эта таблица и используется валидатором, но руками никогда не правиться.
Языки
Эта информация не обязательна. Я просто вывожу название объекта на разных языках (максимум 12), используя name:язык на русском.
ОКТМО население
Уже 5 лет я показываю численность населения городов и сельских поселений. Но это очень ручная работа. Мне эта информация интересна, но поддержание её в составе валидатора требуется 13 раз году и довольно большой объем ручных работ. Вряд ли вас это заинтересует.
Таблицы из ОСМ
Используются таблицы Отношения, Отношения-члены, Линии, Линии-контуры, Узлы, Свойства которые формируются из xml-ки RU-*.osm. Я работал с простой БД, поэтому импортировал pbf/osm файл. В случае PostGIS этого делать не надо. Для PostGIS используется другая схема.
Итак, таблицы рассмотрены. Как работает алгоритм?
Изменений поступает довольно много, я пытался подтаскивать только изменения. Но застрял в ошибках. Поэтому я вкачиваю osm файл с нуля. И это самая главная нагрузка. 5-30 минут требуется на скачку файла, 30 минут на конвертацию pbf → osm, 1.5 часа на загрузку в БД. В PostGIS всё будет проще и быстрее.
После того как закачена БД, происходит её зачистка. Это ускоряет процесс работы. Сначала бегу по релейшенам. Удаляю те, которые не относятся к границам/НП. Потом линии. Удаляются те, что не относятся к задаче + не принадлежат релейшенам. Потом точки.
База становится существенно меньше.
Подготовка
Далее идёт наиболее критичный алгоритм. Как он работает - не знаю и не хочу смотреть. На его создание ушёл день или два и там самое важное - скорость.
Анализируется база данных и на выходе получаются удобные для работы границ линии. То есть не важно, линия это или релейшен. На выходе список линий, в которые включены точки в обычном порядке. Заодно находятся ошибки в контурах.
В PostGIS это не нужно. При вкачке данных всё будет импортировано в линии. В PostGIS просто проверить ошибки линий.