Ну можно и не дифы мониторить, а держать некие контрольные суммы для интересуемых ОСМовских объектов, задействованных в сопоставлении с внутренними данными.
Тогда при очередном слиянии с ОСМ достаточно удостоверится, что ничего в этом объекте не изменилось.
С учетом вашего поста поменял схему работы:
- Гружу в JOSM кусок карты, на которую мне надо внести свое локальное изменение
- Сохраняю этот кусок в файле OSM (my_place.osm)
- Вношу на него свои правки. Снова сохраняю. У меня есть заготовка для слияния в дальнейшем.
- Спустя какое-то время мне понадобилось обновить дамп для GraphHopper.
- Загружаю последний дамп России с http://gis-lab.info/projects/osm_dump/ в виде OSM файла. (RU.osm)
- Запускаю JOSM. Подгружаю свежий кусок интересующего места с облака OSM.
- Подгружаю в JOSM свой сохраненный модифицированный дамп OSM этого участка (my_place.osm). Склеиваю слои. Где way id не поменялись - там все само прикрутится как надо, где поменялись - там ручками подкрутить…
- Выгружаю результат в OSM файл (my_place_diff.osm)
- Мержу дифф с дампом RU.osm.
- Скармливаю его в GraphHopper.
Как считаете - прокатит? 
Вышеупомянутый плагин и открытость OSM натолкнули меня на следующую, довольно удобную в использовании, однако, требующую серьезных разработок, идею.
Поднять свою OSM базу с API. Доработать базу до:
• выпиливание из нее не интересующих вас данных (проверка попадания данных в нужный вам регион)
• возможности отдельного хранения своих данных
• различные тригеры для определения по тегам с вашими ли данными имеет дело база и раскидыванию получаемых объектов по таблицам с вашими данными и данными для заливки в OSM (но не в саму вашу версию ОСМ)
• сборщик ваших OSM изменений в вашей базе заливает эти изменения в общую базу
• мониторинговые системы несоответсвий между вашей версией ОСМ и вашими внутренними данными
• натравливаете JOSM на вашу базу и работаете как с обычной OSM базой. Все ваши изменений пойдут либо в базу со внутреними объектами, либо в общую базу OSM (но в вашу версию ОСМ не попадают)
• настроить достаточно частое накатывание дифов на вашу OSM версию
Ну и дампы берете из своей OSM базы с такой частотой, как хотите и уже с вашими внутринними данными.
Вполне, пока ваши данные или данные ОСМ по вашим объектам не часто изменяемы и их не так много.
Не прокатит, будут конфликты, много конфликтов, если на сервере ОСМ версия объекта такая же или новее чем у вас.
Тогда так (добавил пункт 7.1):
- Гружу в JOSM кусок карты, на которую мне надо внести свое локальное изменение
- Сохраняю этот кусок в файле OSM (my_place.osm)
- Вношу на него свои правки. Снова сохраняю. У меня есть заготовка для слияния в дальнейшем.
- Спустя какое-то время мне понадобилось обновить дамп для GraphHopper.
- Загружаю последний дамп России с http://gis-lab.info/projects/osm_dump/ в виде OSM файла. (RU.osm)
- Запускаю JOSM. Подгружаю свежий кусок интересующего места с облака OSM.
- Подгружаю в JOSM свой сохраненный модифицированный дамп OSM этого участка (my_place.osm). Склеиваю слои. Где way id не поменялись - там все само прикрутится как надо, где поменялись - там ручками подкрутить…
7.1. Сохраняю только что откорректированный файл OSM (my_place_2015-01-16.osm), чтобы в дальнейшем использовать уже его. - Выгружаю результат в OSM файл (my_place_diff.osm)
- Мержу дифф с дампом RU.osm.
- Скармливаю его в GraphHopper.
chnav на другое указывал, хотя 7.1 тоже нужен. Вы на 7-м пункте споткнетесь даже если ID не поменялся, но объект претерпел изменения, ибо ваш объект будет версии x, а из базы вы получите версию x + n. JOSM ругнется, что версии не совпадают и вам придется их сравнивать и сводить их в новую версию. Но, в принципе, это ведь вам и нужно, отследить изменения нужных объектов. Только править конфликты в JOSM та еще задачка…
Та еще задачка… Но решаемая, надеюсь.
Кстати - а чем можно мержить основной дамп и добавочные OSM-файлы?
osmosis-ом
Вот так (отсюда http://wiki.openstreetmap.org/wiki/Osmosis )?
osmosis --rx 1.osm --rx 2.osm --rx 3.osm --merge --merge --wx merged.osm
osmconvert’ом
А osm с pbf он умеет?
Вот на счет 2-х файлов я не уверен, поэтому и подтер. Там в хелпе что-то по поводу не возможности обработки веев и нод за раз пишут.
Памяти только жрать будет дофига . Если особо не парит можно вообще башем
cat 1.osm | grep -v "\<\/osm\>" > merged.osm
cat 2.osm | grep -v "\<osm" | grep -v "\<bound" >> merged.osm
Не рекомендую - но если лениво парится с osmosis то можно
Да вроде не должно дофига жрать. Не больше обычного…
Osmosis вроде разбирает сначала дампы на составляющие в виде отдельных файлов, потом делает с ними что вы просили и потом собирает результат обратно в формат который просили. Кажется - так…
Возможно уровень абстракций который вы хотите использовать (way) недостаточно выразителен. Вам нужны не только правила (коэффициенты ваших клиентов, access из приватной базы данных), но ещё гео-координаты. Вам привели пример с раздвоением 1 way на 2 или 3. Гео-координаты изменятся если дорогу разрежут посередине на два way.
Альтернатива этому использовать более высокие абстракции. Результаты работы OSRM (или GraphHopper), такие:
Если этот путь сегодня занимает 3 way, завтра 10 - то так и должно быть.
Если завтра его порвут в OSM - значит так и должно быть. (ремонт дороги, объезды на 3-6 часов).
Абстракция здесь не way (это не целая дорога, а только сегмент дороги), а две точки A, B (их гео-координаты).
Если ваши клиенты знают о ремонте дорожной сети, то эта информация не секретная и ей место в OSM. Другое дело согласятся ли они вносить их
Идея как это использовать на практике
Если вчера роутер OSRM по запросу A-B выдавал один way, а после обновления России он стал выдавать 10 way то вам нужно проверить данные напрямую с главного сервера OSM и исправить ошибку (если у вас более актуальные данные). Если ошибки нет, то бизнес-правило ваших клиентов будет применяться не к 1 way, а к 10. Запрограммировать такое будет трудновато, если вы сталкиваетесь с этим в первый раз.
Немного проблемно для вас, зато позволяет быть вам и вашим клиентам одними из сотен контрибьюторов OSM. Это не громкие слова. Мой регион постоянно улучшают инженеры Mapbox своим инструментом http://osmlab.github.io/to-fix/ который они постоянно рекламируют везде.
В Москве никто просто так разрезать не будет. Там дорогу нарисовать - вандализм, все дороги уже отмечены. Задумайтесь об этом. Получится ли у вас или ваших клиентов такого добиться если будете пытаться параллельную базу дорог вести? Часть этой работы могут выполнить другие участники OSM, так почему не помочь и сэкономить себе ресурсы?
Для ваших клиентов есть конкуренция. Для меня (участника OSM) её нет, я нарисую абсолютно все дороги и порву их если будет нужно.
Конечно.
Там всё проще и сложнее на самом деле.
Osmosis - это многопоточная программа на Java, которая позволяет делать любые манипуляции с данными OSM.
Входные данные разбираются на составляющие объекты (точки, линии, отношения), затем эти объекты в виде потока данных пропускаются через указанные задачи обработки и в конце результат записывается в указанный формат.
Объекты эти существуют в памяти в виде объектов Java + могут записываться во временные хранилища (для сложных задач, которые манипулируют наборами данных).
Есть куча готовых задач по манипулированию данных + есть возможность написать свой собственный плагин с необходимым обработчиком.
OSM - это бесплатный набор данных, который можно использовать. Но эта бесплатность не означает, что вам ничего не понадобиться делать. Если вы хотите иметь возможность иметь специфические правила проезда - придётся поработать.
Проще всего было бы формализовать эту специфику в виде набора общих правил, которые можно было бы применять на этапе конвертирования (при помощи того же osmosis). Тогда ручной работы остаётся минимум.
Произвольные же правки графа требуют уже намного больших затрат. Текущая модель OSM к подобным вещам плохо приспособлена, придётся придумать довольно сложный механизм хранения и применения этих правок (например, с использованием того же OpenLR, который тут упоминали).
Наличие требования неформализованной гибкости (задавать правила как левая пятка захочет) - обычно это признак самой плохой ситуации в разработке, когда пытаются сделать “автоматизацию бардака”, т.е. автоматизировать текущие процессы без попытки их структуризации и упорядочивания. Опыт показывает, что при попытке автоматизации бардака получается просто автоматизированный бардак, и ничего более (т.е. с бардаком так справится не получится).
Даже и в мыслях не было отказываться от общедоступной базы OSM и городить свою ветку развития. Картина примерно такая: бОльшая часть модификаций наших клиентов будет конечно на основном сервере OSM, т.к. никакой секретности там нет. Но есть еще небольшой ряд изменений, который нельзя показывать никому. Вот эти изменения клиенты хотят обрабатывать только на своей стороне, тем или иным способом. Дополнительно, нужно чтобы клиент, внесший изменения в общую базу OSM - мог сразу получить обновленные данные и загрузить их в GraphHopper.
Кстати, забыл поблагодарить за ссылку на OpenLR - думаю очень нам пригодится в будущем.
Про автоматизацию бардака - Вы абсолютно правы и я с вами согласен. У нас правда не совсем бардак, мы в некотором роде “в поиске решения” с параллельным анализом возможных “хотелок” клиентов. Т.е. четко сформулированной задачи еще нет, есть образно, на словах вынесенные пожелания. Вот я и пытаюсь еще параллельно разобраться во всех тонкостях OSM по-максимуму.