Если подобных приватных данных немного, то оптимальнее всего идти по простой схеме предложенной ранее, т.е. ваши клиенты привязывают свои приватные данные к OSM’овским ID, и вы уже потом своими силами в полуавтматическом режиме мониторите их изменения и обновляете привязку в случае необходимости. Т.е. например при создании дампа или на постоянной основе сканиируете не было ли изменений с айдишниками к которым привязались ваши клиенты, в случае чего обновляя привязку. (ну и как побочный эффект будете отслеживать потенциальных вандалов на интересующей вас местности)
trincoru, GraphHopper можно использовать как свою собственную библиотеку в составе своего приожения. Просто найдите нужные вам ребра графа и поменяйте им веса в зависимости от нужд клиента. Это можно делать без ручного редактирования.
Сейчас ваш план подразумевает поднятие своей реплики osm api, объединение кусков осм, разрешение конфликтов вручную при обновлении. Разрулить конфликты сложнее чем сделать с нуля. Зачем вам весь этот ужас?
Немного не так. Мы реплики делать не собираемся. Пока план такой:
- Если нужно просто внести быстрые не секретные изменения, то правим через JOSM, сохраняем на ОСМ-сервер, сохраняем отредактированный кусок в файл и сшиваем его с основным дампом. Дальше в Графхоппер.
- Если есть что-то секретное, то делаем тоже самое, но не сохраняем на ОСМ-сервер.
И конечно, мы используем Графхоппер не как самостоятельное приложение, а как библиотеку, на которой основе которой строится наше приложение.
Ага… Вот и первый камень…
osmosis --rx _dumps/RU.osm --rx _dumps/2015-01-19-001.osm --merge --wx _dumps/ru1.osm
Если попытаться объединить два OSM файла, один - скачанный дамп, второй - свой файл, сохраненный из JOSM на диск, но не сохраненный на сервер OSM, то получим ошибку:
“does not have a version attribute as OSM 0.6 are required to have. Is this a 0.5 file?”
- Так я тоже делаю иногда, но вот удаленные объекты так не удаляются. JOSM их в файле никак не отражает
- Новые объекты JOSM, если он их не грузил на сервер, в файле сохраняет в искусственными ID (<0).
-
Это и без таскания JOSM файликов будет работать, через osmupdate например или osmosis.
С джосмом без реплики АПИ начнутся конфликты и грабли когда у вас версия которую вы используете как основную на этапе мерджа осмосисом не совпадет с версией которая правилась из джосма. -
Мердж таких файликов превратится в ад. Особенно когда надо будет смерджить открытые данные поверх секретных.
Тоесть пометили вы дорожку тегами с данными клиента и наррисовали рядом секретную тропу (пока все ок)
Теперь вы хотите добавить в паблик несекретную дорожку как-либо взаимодействующую с секретной (допустим публичный проезд до ворот территории и секретный внутри).
Допустим вы смерджили даже эти данные, как вы будете следить что данные клиента не утекли? Тоесть например что теги с клиентской инфой из такого франкенштейна не утекли, если глазами, то сразу исходите из предположения что данные будут переодически утекать в паблик (Ничего не подписывайте 
).
Все верно, поэтому пока мы просто сделали видеоинструкцию для клиентов, о том как вносить публичные данные в базу OSM и тут же получать обновленный дамп путем слияния “прошло-суточного” скачанного дампа и их последних изменений.
Про “секретные” данные пока забыли, может быть в дальнейшем что-то изменится и появится гениальная мысль…
Возможно, не так понял это утверждение, ибо, удаляемые объекты JOSM в файле помечает. А как иначе? Нужно же знать, что грохнуть при аплоаде.
По собственному опыту говорю.
Беру дамп, добавляю сохраненные JOSM отредактированные данные и объединяю osmconvert’ом. Удаленные объекты остаются в результирующем файле.
Возможно все дело в волшебных пузырьках osmconvert. Может другие как-то по другому объединяют.
P.S. проделал эксперимент - создал в JOSM точку, выгрузил на сервер, убил JOSM точку, выгрузил на сервер.
Теперь сохраняю .osm - JOSM говорит, что пустой документ. Не верю!
Сохраняю и вижу
<node id='3320492472' action='delete' visible='true' version='1' changeset='28502029' lat='55.18175182096' lon='44.06464718761' />
То JOSM есть сохраняет, а дальше всё зависит, как конкретная программка объединяет файлы
Ну да, JOSM же для себя сохраняет, должен же он знать, что делать с объектами при загрузке на сервер. А вот, osmconverter и аналогичные ему, action, по всей видимости, просто игнорируют, рассчитывая лишь на работу с дампами, в которых нет никаких action. Т.е. для них такая запись будет означать существование данного объекта, а не наоборот. Ни о каких удалениях и редактированиях они знать не знают. Все что есть в *.osm файле - это существующие объекты и их стейт на момент создания сего “дампа”.
Для объединения дампа с кастомным, содержащим изменения, *.osm нужно на дамп дифф накатывать, формируя дифф из этого самого кастомного *.osm. Только, я тут, похоже, не помогу 