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

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

Пробный прогон прошёл успешно, на сайте валидатора выложу при следующем прогоне - может на следующих выходных а может и в какой-нибудь рабочий день. Отпишусь как новый отчёт будет готов.

А можно ссылочку, с которой скачивается успешно. А то в связи с этой чехардой те ссылки, что у меня были не работают теперь.
Нашел только в виде .DOCX тут https://www.gks.ru/classification, а где же .CSV?

Место известное, но они всё забили результатами сельскохозяйственной переписи 2016 года.

Прямая ссылка - https://www.gks.ru/opendata/7708234640-oktmo2

Там важный комментарий:

Т.е. в январе скорее всего будет довольно большой апдейт.

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

Буду искать какое-то временное решение.

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

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

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

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

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

Не подскажет ли кто-нибудь на основе своего опыта, какой 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">

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