OSMOSIS. Результат применения параметра "--merge"

Добрый день.
На данном форуме через поиск искал “–merge”/“conflictResolutionMethod=”,“Склейка файлов”, но ни чего кроме вскользь описанной ниже проблемы, мною, не нашел. Прошу подсказать, если кто знает точный ответ, является ли это нормой:

Проблема:
Выполняют склейку 2-х файлов. При склейке 2х файлов *.osm.pbf, по примеру команды:
/Osmosis-0.47/bin/osmosis
–read-pbf-fast file=“/data/eurasia.osm.pbf”
–read-xml file=“/data/users_change.osm”
–merge
conflictResolutionMethod=“timestamp”
omitmetadata=true
–write-pbf file=“/data/total_file.osm.pbf”

Я получаю файл “total_file.osm.pbf” размером 18Гб, хотя:
файл “eurasia.osm.pbf” = 23Гб
файл “users_change.osm” = 64Кб
т.е. теряется почти 5Гб.

Думаю из-за этого

omitmetadata=true

Может просто подскажите альтернативный вариант решения моей потребности.
Описание:
У меня есть старая БД OSM с правками картографов маленькой конторки. На ней у объектов, дорог, стоят теги с дополнительной информацией по этому участку дороги (запреты этой организации для водителей этой организации/какие то внутрении POI).
Теперь им требуется обновить дорожный граф.
Т.е. требуется обновить дороги и сверху наложить их запреты.
Какой я выбрал путь:

  1. Я выгружу всю историю с параметром “readFullHistory”
  2. Конвертирую ее в сущность “–convert-change-to-full-history”
  3. Применю результат к файлу обновленного графа дорог
  4. Результат залью в БД postgres

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

Почему маловероятно т.к. тут описано: “https://help.openstreetmap.org/questions/17651/osmosis-warning-data-being-output-lacks-metadata
Цитата лучшего ответа: "
The cause of this warning is that some of your input data lacks metadata, and therefore the output data does, too. A clearer, but rather long, warning message would probably be: “WARNING! Some of your input data lacks metadata but you haven’t specified omitmetadata=true which means that I am creating output partly with and partly without metadata! If you specified omitmetadata=true then at least my output would be consistent in not having any metadata.”

The reason that some of your input data lacks metadata is likely that you’re using a planet file and there are still a couple objects in there that have last been edited by an anonymous user and therefore lack user information."

У вас в исходных данных есть метаданные, в результате не будет, вопрос - должен ли уменьшиться размер?

Ваш кейс сложен и вам ещё предстоит пройтись по множеству грабель. Вся система ОСМ построена на том, чтобы не хранить данные локально.
И в большинстве случает проще окажется мержить данные через пересечение геометрий в двух базах, нежели разруливать конфликты на уровне сырых данных ОСМ, тем более со стратегией timestamp.

РЕШЕНО.
“freeExec” спасибо тебе большое, да, убрав “omitmetadata=true” получил файл нужного объема.

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

Собсно налицо ошибка проектирования системы, которая теперь вылезла. Ну обновите вы этот граф, с помощью лома и какой-то матери, а дальше что? Через полгода (или с какой периодичностью там планируется обновление) снова встанет та же проблема?
Чтобы обновление данных проходило безболезненно - не нужно эти запреты хранить у себя. Если запреты касаются всех (например запрет для грузовиков) - нужно просто добавить их в общую базу. Если они не для всех, но проставлены исходя из каких-то объективных признаков (габаритов, максимальной массы и т.п.) - надо проставить эти признаки и затем конвертировать в запреты при импорте. Если они проставлены через запретные области - храните эти области и опять же проставляйте запреты по попаданию в них.

Запреты непосредственно для водителей и запреты административного характера от руководителей компании т.е. они просто бесполезны для всех остальных.
POI - это места, где сами водители считают участок опасным и просят их предупреждать при выдаче маршрута другим водителям.
А обновление будет регулярным, если сейчас обновлюсь, то по этому сценарию будет еженедельное обновление.

Отпишитесь о результатах, вдруг вы счастливчик у кого это получится автоматизировать.

Эти запреты на чём-то зиждятся. Вот хотелось бы узнать - на чём?
Весьма вероятно, что за этим стоит что-то объективное, из чего можно а) вытащить полезную информацию для OSM, и б) сильно упростить процедуру обновления.

Отдельные свои POI как раз не проблема, они не пересекаются с данными OSM, проблема в запретах, которые привязаны к дорогам.

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