Анализируя работу валидатора заметил что наиболее неэффективно время тратится при подготовке данных, поэтому возникла идея ускорить именно эту часть (максимум выигрыша за минимальное время).
Не подскажет ли кто-нибудь на основе своего опыта, какой Java библиотекой лучше пользоваться чтобы читать pbf файл напрямую? Поиск показал что есть варианты, но анализа что лучше/быстрее нет, многие посты 2-3 летней давности. По каким-то библиотекам было замечание что они не поддерживаются, т.е. потенциально могут перестать работать после каких-то очередных изменений (формата, Java и т.п.).
Требования к Java библиотеке такие: нужно читать pbf, запись не нужна, хотя наличие такой возможности может быть потенциально полезной. Нужно просто быстро читать pbf файл и анализировать теги всех записей. Работать нужно с pbf России, т.е. 2.5Гб файлом (т.е. не planet-OSM), т.е. работа в оперативке вполне устраивает.
Если у кого-то есть опыт - поделитесь, пожалуйста!
pbf-формат и не менялся, поэтому нет ничего плохого в библиотеках такой давности.
Да и кратный прирост можно достичь, только из-за блочности формата, когда его можно читать в несколько потоков.
Так же не вижу смысла ворочить 2.5Гб файл, когда его можно предварительно отфильтровать и там останется мегабайт 100.
Классификатор пересчитан в соответствии с последним обновлением ОКТМО.
Поскольку, муниципальные округа ещё в него не вошли, я их добавлю в ручном режиме немного позднее. Мне сначала нужно будет добавить поддержку муниципальных округов в принципе, поскольку этот тип муниципальных образований не предполагался последние 13 лет. Это определённы рефакторинг. А потом поменяю типы округов.
“Было-стало” не делал, поскольку информация по АТД в ОСМ достаточно полная, поэтому все расхождения довольно легко вычисляются.
Начал рефакторинг (вызванный появлением муниципальных округов) в конце новогодней недели, вышел на работу … и узнал что нет работы. “Спасибо, но Вы нам не нужны”. Пришлось бегать по собеседованиям, перечитывать тонны литературы/пересматривать километры видео. В итоге работа нашлась, но испытательный срок - время когда не получается расслабиться. В итоге только сегодня смог закончить рефакторинг так беспечно начатый сразу после Рождества.
Простые тесты прошли, на неделе попробую сделать прогон чтобы понять, не намудрил ли с чем-то.
У меня поехала иерархическая система кодов, так как в момент создания софта не предполагалось что будет что-то помимо городского округа (города регионального подчинения) и муниципального района. В результате многие записи сменили тип объекта что нужно было подхватить софте.
Специфика работы скриптовых языков с базами данных. Сейчас я заложил диапазоны, так что добавление новых типов классификации не потребует изменения ранее введённых
Где-то пару месяцев назад заметил странное новшество - в обрезанный мною дамп России стали попадать изменения со всего мира. Т.е. изменения в Аргентине, Ирландии, США, Индонезии и т.п. Соответственно, после каждого прогона нужно вычищать весь этот мусор. Появилось это единомоментно и не исчезает. Также появилось ощущение что osmupdate стал работать ощутимо дольше. Тащатся только relation, размер дампа увеличился не сильно.
Никто с подобным не сталкивался? Я с таким сталкивался пару лет назад, по воспоминаниям произошла какая-то смена формата pbf и osmupdate устарел, помогло обновление на новую версию osmupdate (которую скорее всего присылал freeExec).
Хотя … на 1 февраля дамп России у меня 2726 Мб, на 8 марта - 2758 Мб. Т.е. прирост на 32 Мб чуть больше чем за месяц. Раньше дамп рос медленнее. Файл обрезки не менялся уже много лет.
Не припомню никаких смен pbf. А сам пользуюсь osmupdate от 2012 года. Впрочем она всего лишь обвёртка над osmconvert. Не могу утверждать, что у меня нет такого баг (в josm я его не открываю, чтобы такое увидеть), но при обработке не сталкивался с левыми деталями.
Свежие версии держу тут - https://frexosm.ru/about-tools.html
П.С. Дамп последние пол года растёт быстро из-за переписи.
Сталкивался. И мне кажется, что уже давно. Обрезка как-то не всегда срабатывает у osmupdate. Но раньше мне казалось это просто соседние регионы пролазил
Полигоны находятся в pbf, но линии/точки найти не удалось. Проверял не всё, несколько наугад.
Выглядит как бага: кто-то поменял отношение, но ни одна из линий не попадает в дамп, поскольку все точки не попадают в зону обрезки (были обрезано в самом начале). Но алгоритм считает что не хорошо - терять отношения и добавляет его “на всякий случай”.
Такое поведение заметил несколько месяцев назад (2-3 ?), хотя скрипты не менялись с 2018 года. Скрипт выглядит банально:
Насколько я знаю, при обрезке всё что не имеет координат выкидывается.
У меня стоит дополнительный ключ, не помню уже всей истории, но при большем количестве что-то делалось криво, выдавал какие-то варнинги.
--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 некорректно отрабатывает релейшены у которых все члены не попадают в обрезку. Сегодня попробую провести полный цикл валидатора и посмотреть - стало лучше или нет.
^^ Спасибо за предупреждение, буду здесь если что.
Перевёл валидатор на osmconvert 0.8.10 и обновился от дампа начала февраля - “заморские” муниципалитеты ушли, никаких новых артефактов не заметил. Размер файла отношений упал сильно (816 → 464 Мб), размер файла нод и веев чуть-чуть уменьшился, что несколько странно, но разбираться с этим сейчас не хочется - это доли процента (размер распакованного файла веев был 14972 Мб, стал 14970 Мб).
Переход от дампа за январь не получился - osmupdate вылетел по ошибке MergeError, возможно, обновление за 2+ месяца слишком требовательная по ресурсам операция.
В общем пару недель понаблюдаю и поделюсь тем что получается. Пока всё ОК.
Прогон валидатоа выдал такой список расхождений по сельским поселениям. На Северном Кавказе в 2020 году были небольшие изменения (изменение границ районов), т.е. ОКТМО устарел, остальные расхождения - поселение упразднено но пока есть в ОСМ. Т.е. нужно будет их удалить.
По Чечне ничего удалять не надо, я уже привёл к актуальному состоянию. ОКТМО отстаёт. Там переделали районы, часть поселений сменила район с 1 января 2020. Поэтому в валидаторе это выглядит как в некоторых районах есть отсутствующее и/или неверноприсутствующее ГП/СП.
^^ По идее, нет больших проблем чтобы “подправить” это в валидаторе. Единственно что для меня важно, так это то что преобразования должны быть прошлого года - я использую ОКТМО для других проектов и не хочу получить проблем с целостностью данных (поселение в разных районах). Это изменение от 1 января 2020, поэтому скорее всего это должно быть относительно безопасной ситуацией для меня. Поэтому подожду следующего обновления ОКТМО - может они включат, тогда всё изменится автоматически, ну или я “ручками” исправлю.
Кстати, к выходным постараюсь “подправить” недавно созданные муниципальные и городские округа, которые пока не вошли в ОКТМО. Проверил (локально), что все нововведения в Московской области (например, Лотошинский городской округ), которые есть в ОСМ (но нет в последней версии ОКТМО) корректно отрабатываются у меня. Отпишусь как обновлю валидатор.
^^ Не стал ждать выходных, перезапустил валидацию сегодня. 99.3% сельских НП опознано.
Комментарий наверное для Jake Strine - я использую ОКТМО + могу вносить мелкие правки. Я прошёлся по тому что сейчас в ОСМ и исправил у себя (например, включил последние изменения по Московской области). Поэтому если отмечены какие-то последние изменения, то я могу их применить вручную, дайте мне знать.
Часть изменений для меня простые:
муниципальный район → муниципальный округ
сельское поселение вошло в состав другого поселения
Часть изменений не такие безопасные, могу притормозить с обновлениями
городское поселение → сельское поселение (и наоборот)
Часть изменений не очень хорошо ложатся на мою базу данных, с ними спешить не буду:
муниципальный район → городской округ
муниципальный район объединяется с городским округом