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

Интернет восстановили, но не известно, на сколько - судя по всему кабель пал жертвой какой-то многолетней борьбы ЖЭКа с интернет-провайдерами. Война может перейти в горячую фазу в любой день. Это же Петербург!

Валидатор запустил, но на неделе было зачищено много тегов по разным объектам, в результате валидатор отправил кучу областей за границу. Восстановил и перезапущу всё снова вечером.

Валидатор обновился, перешёл на последнюю версию ОКТМО. Если с кабелями в подъезде не будет приключений то валидатор будет обновляться штатно как и раньше.

В январе ожидаются большие изменения в ОКТМО (Росстат отложил ряд изменений до января, конца переходного периода по некоторым изменениям).

Анализируя работу валидатора заметил что наиболее неэффективно время тратится при подготовке данных, поэтому возникла идея ускорить именно эту часть (максимум выигрыша за минимальное время).

Не подскажет ли кто-нибудь на основе своего опыта, какой Java библиотекой лучше пользоваться чтобы читать pbf файл напрямую? Поиск показал что есть варианты, но анализа что лучше/быстрее нет, многие посты 2-3 летней давности. По каким-то библиотекам было замечание что они не поддерживаются, т.е. потенциально могут перестать работать после каких-то очередных изменений (формата, Java и т.п.).

Требования к Java библиотеке такие: нужно читать pbf, запись не нужна, хотя наличие такой возможности может быть потенциально полезной. Нужно просто быстро читать pbf файл и анализировать теги всех записей. Работать нужно с pbf России, т.е. 2.5Гб файлом (т.е. не planet-OSM), т.е. работа в оперативке вполне устраивает.

Если у кого-то есть опыт - поделитесь, пожалуйста!

pbf-формат и не менялся, поэтому нет ничего плохого в библиотеках такой давности.
Да и кратный прирост можно достичь, только из-за блочности формата, когда его можно читать в несколько потоков.
Так же не вижу смысла ворочить 2.5Гб файл, когда его можно предварительно отфильтровать и там останется мегабайт 100.

Классификатор пересчитан в соответствии с последним обновлением ОКТМО.

Поскольку, муниципальные округа ещё в него не вошли, я их добавлю в ручном режиме немного позднее. Мне сначала нужно будет добавить поддержку муниципальных округов в принципе, поскольку этот тип муниципальных образований не предполагался последние 13 лет. Это определённы рефакторинг. А потом поменяю типы округов.

“Было-стало” не делал, поскольку информация по АТД в ОСМ достаточно полная, поэтому все расхождения довольно легко вычисляются.

Начал рефакторинг (вызванный появлением муниципальных округов) в конце новогодней недели, вышел на работу … и узнал что нет работы. “Спасибо, но Вы нам не нужны”. Пришлось бегать по собеседованиям, перечитывать тонны литературы/пересматривать километры видео. В итоге работа нашлась, но испытательный срок - время когда не получается расслабиться. В итоге только сегодня смог закончить рефакторинг так беспечно начатый сразу после Рождества.

Простые тесты прошли, на неделе попробую сделать прогон чтобы понять, не намудрил ли с чем-то.

А собственно мцниципальный округ чем он отличается от городского округа? Нет поселений и в том, и в другом.

У меня поехала иерархическая система кодов, так как в момент создания софта не предполагалось что будет что-то помимо городского округа (города регионального подчинения) и муниципального района. В результате многие записи сменили тип объекта что нужно было подхватить софте.

Специфика работы скриптовых языков с базами данных. Сейчас я заложил диапазоны, так что добавление новых типов классификации не потребует изменения ранее введённых :slight_smile:

Где-то пару месяцев назад заметил странное новшество - в обрезанный мною дамп России стали попадать изменения со всего мира. Т.е. изменения в Аргентине, Ирландии, США, Индонезии и т.п. Соответственно, после каждого прогона нужно вычищать весь этот мусор. Появилось это единомоментно и не исчезает. Также появилось ощущение что osmupdate стал работать ощутимо дольше. Тащатся только relation, размер дампа увеличился не сильно.

Никто с подобным не сталкивался? Я с таким сталкивался пару лет назад, по воспоминаниям произошла какая-то смена формата pbf и osmupdate устарел, помогло обновление на новую версию osmupdate (которую скорее всего присылал freeExec).

Хотя … на 1 февраля дамп России у меня 2726 Мб, на 8 марта - 2758 Мб. Т.е. прирост на 32 Мб чуть больше чем за месяц. Раньше дамп рос медленнее. Файл обрезки не менялся уже много лет.

osmconvert 0.8.8
osmupdate 0.4.4

Не припомню никаких смен pbf. А сам пользуюсь osmupdate от 2012 года. Впрочем она всего лишь обвёртка над osmconvert. Не могу утверждать, что у меня нет такого баг (в josm я его не открываю, чтобы такое увидеть), но при обработке не сталкивался с левыми деталями.
Свежие версии держу тут - https://frexosm.ru/about-tools.html

П.С. Дамп последние пол года растёт быстро из-за переписи.

Сталкивался. И мне кажется, что уже давно. Обрезка как-то не всегда срабатывает у osmupdate. Но раньше мне казалось это просто соседние регионы пролазил

Но теперь вот и пользователи замечать стали, причем такое вот далекое:
https://forum.openstreetmap.org/viewtopic.php?pid=777251#p777251

Алгорифм у меня такой:

  • osmupdate федеральный округ.pbf с обрезкой по округу
  • osmconvert из федерельного.pbf в регион.osm с обрезкой по региону.

Вот данные последнего прогона. В pbf России попали регионы, муниципалитеты из США, Аргентины и Филиппин:

Полигоны находятся в pbf, но линии/точки найти не удалось. Проверял не всё, несколько наугад.

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

Такое поведение заметил несколько месяцев назад (2-3 ?), хотя скрипты не менялись с 2018 года. Скрипт выглядит банально:

osmupdate.exe -v --day --hour -B=RUS.poly RU-latest.current.osm.pbf RU-latest.osm.pbf
osmupdate 0.4.4
Updates .osm, .o5m, .pbf files, downloads .osc, .o5c files.
To get detailed help, please enter: ./osmupdate -h

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

--max-merge=5

И для чистоты эксперимента только дневные обновления использую, но вряд ли в этом может быть проблема.
Указанных отношений не обнаружил.

Да, различия между запуском osmupdate не существенны. Похоже что разница не в этом.

Сейчас проверяю гипотезу что виноват не osmupdate а osmocnvert. Скачал с https://frexosm.ru/about-tools.html версию 0.8.10, тогда как у меня сейчас - 0.8.8

Update: Запустил обновление дампа и разница видна. Дамп России сделанный 0.8.8 весит 2766Мб, дамп сделанный 0.8.10 весит 2744Мб, т.е. разница - 22Мб pbf файла.

Вытащенные релейшены (xml ака osm) в 0.8.8 занимают 816Мб тогда как в 0.8.10 размер файла упал 464Мб. Размер веев и нод отличается на несколько мегабайт (запускал обновление с интервалом несколько часов).

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

Эта версия тоже не без греха, похоже, при работе с отношениями.
Вот у меня

<relation id="4215198" version="182" timestamp="2019-08-11T11:52:26Z" changeset="73239483" uid="237049" user="siberiano">

А в базе

<relation id="4215198" version="185" timestamp="2020-01-29T20:45:35Z" changeset="80278305" uid="499800" user="freeExec">

П.С. Нет, тут я сам виноват, после вырезания накатывал другие старые куски, где и была данная версия.

^^ Спасибо за предупреждение, буду здесь если что.

Перевёл валидатор на osmconvert 0.8.10 и обновился от дампа начала февраля - “заморские” муниципалитеты ушли, никаких новых артефактов не заметил. Размер файла отношений упал сильно (816 → 464 Мб), размер файла нод и веев чуть-чуть уменьшился, что несколько странно, но разбираться с этим сейчас не хочется - это доли процента (размер распакованного файла веев был 14972 Мб, стал 14970 Мб).

Переход от дампа за январь не получился - osmupdate вылетел по ошибке MergeError, возможно, обновление за 2+ месяца слишком требовательная по ресурсам операция.

В общем пару недель понаблюдаю и поделюсь тем что получается. Пока всё ОК.

Не, всё нормально, это я виноват.

Прогон валидатоа выдал такой список расхождений по сельским поселениям. На Северном Кавказе в 2020 году были небольшие изменения (изменение границ районов), т.е. ОКТМО устарел, остальные расхождения - поселение упразднено но пока есть в ОСМ. Т.е. нужно будет их удалить.

По Чечне ничего удалять не надо, я уже привёл к актуальному состоянию. ОКТМО отстаёт. Там переделали районы, часть поселений сменила район с 1 января 2020. Поэтому в валидаторе это выглядит как в некоторых районах есть отсутствующее и/или неверноприсутствующее ГП/СП.