Добрый день.
На данном форуме через поиск искал “–merge”/“conflictResolutionMethod=”,“Склейка файлов”, но ни чего кроме вскользь описанной ниже проблемы, мною, не нашел. Прошу подсказать, если кто знает точный ответ, является ли это нормой:
Может просто подскажите альтернативный вариант решения моей потребности.
Описание:
У меня есть старая БД OSM с правками картографов маленькой конторки. На ней у объектов, дорог, стоят теги с дополнительной информацией по этому участку дороги (запреты этой организации для водителей этой организации/какие то внутрении POI).
Теперь им требуется обновить дорожный граф.
Т.е. требуется обновить дороги и сверху наложить их запреты.
Какой я выбрал путь:
Я выгружу всю историю с параметром “readFullHistory”
Конвертирую ее в сущность “–convert-change-to-full-history”
Применю результат к файлу обновленного графа дорог
Ну маловероятно, но все же решил попробовать выполнить команду без этого параметра, часа через 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.
Собсно налицо ошибка проектирования системы, которая теперь вылезла. Ну обновите вы этот граф, с помощью лома и какой-то матери, а дальше что? Через полгода (или с какой периодичностью там планируется обновление) снова встанет та же проблема?
Чтобы обновление данных проходило безболезненно - не нужно эти запреты хранить у себя. Если запреты касаются всех (например запрет для грузовиков) - нужно просто добавить их в общую базу. Если они не для всех, но проставлены исходя из каких-то объективных признаков (габаритов, максимальной массы и т.п.) - надо проставить эти признаки и затем конвертировать в запреты при импорте. Если они проставлены через запретные области - храните эти области и опять же проставляйте запреты по попаданию в них.
Запреты непосредственно для водителей и запреты административного характера от руководителей компании т.е. они просто бесполезны для всех остальных.
POI - это места, где сами водители считают участок опасным и просят их предупреждать при выдаче маршрута другим водителям.
А обновление будет регулярным, если сейчас обновлюсь, то по этому сценарию будет еженедельное обновление.
Эти запреты на чём-то зиждятся. Вот хотелось бы узнать - на чём?
Весьма вероятно, что за этим стоит что-то объективное, из чего можно а) вытащить полезную информацию для OSM, и б) сильно упростить процедуру обновления.
Отдельные свои POI как раз не проблема, они не пересекаются с данными OSM, проблема в запретах, которые привязаны к дорогам.
Отпишусь, но пока результат не очень, получилось смержить, получилось данные засунуть в роутинг и он работает, но появилась проблема в работе JOSM, в другой ветке задал вопрос.
Качество мержа под вопросом, настрою работу JOSM - буду проверять.