Это (любая информация о дополнительных бонусах в дорожной сети) как раз конфиденциально и представляет интерес для конкурентов, поэтому клиенты нам не разрешат выдавать такие данные в общую базу.
Смотрю, пока не очень увязывается в голове…
Это я как раз понял…
Какие-то ошибки могут быть в любом общедоступном наборе данных (кроме КЛАДРа и ОСМ я правда ничего и не припомню 8) ) и они могут добавляться/меняться/убираться сами по себе…
Вандалы или новички могут попортить данные в базе.
Поэтому и хочется свои (для узкого применения) данные хранить у себя в каком-либо удобном для редактирования виде, и склеивать их с основной базой перед использованием в GraohHopper.
Видится два пути:
- Отдельный человек, с заданной периодичностью, вручную готовит модифицированный дамп OSM (добавляет к дампу свои данные), который потом пойдет в GraphHopper.
Каким именно инструментом это можно делать, пока не понятно. Вероятно, JOSM поможет. Я лично добавлял только несколько домов в базу через онлайн-редактор. - Автоматизировать как-то этот процесс. Т.е. иметь набор своих данных, которые можно редактировать и по необходимости склеивать свои данные с дампом.
Тут вообще даже просвета пока не видно, как это сделать. Ведь надо как-то синхронизировать два набора данных, один из которых может непредсказуемо меняться…
Какой-то сложный аналитический алгоритм нужен.
А что за данные то? Точнее как они организованы? Вам надо каким-то из ребер графа менять веса или исключать какие-то из ребер или добавлять свои?
С такими супер секретными данными вам проще взять один раз данные осм и дальше вести их самостоятельно и никогда не мержиться.
Вы поднимаете свой сервер, JOSM берёт геометрию с основного сервера ОСМ, дополнительные теги с вашего приватного сервера. После редактирования плагин фильтрует внесенные данные, ваши приватные теги он наружу не пропускает, а скидывает на ваш личный сервер.
Например на дороге или шлагбауме стоит access=private|no, а вы придумываете тег trincoru:access=yes, который будет храниться только на вашем сервере.
Там в комментариях был указан usecase - в HOT хранили данные о доходах по домовладениям.
Синхронизация происходит по id объекта.
Единственный вопрос, который у меня возникает - как делать большие выгрузки регионов, не через JOSM же…
PS: ещё бОльший вопрос для меня как разворачивать Ruby on Rails )) Но это решаемые технические вопросы.
Протухание данных можно решить следующим путем - обрабатывать дифы и мониторить по ним изменения в ОСМ объектов с вашей базы и сигнализировать об этом, что бы оперативно проверить и синхронизировать вашу базу с ОСМ.
Пока все только в голове, ничего конкретного.
Но вообще да - нужно исключать ребра и добавлять свои. А про веса - это другая тема совсем, пока не требуется, но может быть - понадобится.
Вот не проще. Суть OSM-ма в том, что это огромный саморазвивающийся бесплатный ресурс. Это просто находка! А вы говорите - отказаться от его обновлений?
Да и тем более по всей России вести самостоятельно изменения? Это перебор 
И как писали выше - если кто-то изменит дорогу или шлагбуам - то может изменится их id. А это уже утрата связи с данными со второго сервера, так ведь?
ID изменится если объект был полностью заменен на новый (что сообществом не поощеряется, однако, какой-нить новичек может запросто подобное проделать), или он был разбит на несколько сегментов, при этом, один сегмент останется со старым ID, остальные сегменты получат новые ID.
Мониторинг изменений интересующих вас объектов и проверка каждого изменения (инициированного не вами), пожалуй, будет единственным решением, которое позволит держать связки с вашей базой в актуальном состоянии.
Обычно безосновательное удаление у нас карается, правка откатывается (если за этим следить, конечно). Простое же редактирование данных не меняет id.
Если кто-то разделит дорогу - id сохранится у одного из отрезков, вам достаточно перенести теги на второй.
Если кто-то соединит дороги - тогда пропадет один из id.
В JOSM есть отличные фильтры и стили отрисовки, можете настроить на отображение своих тегов и сразу будет видно разрывы.
Ещё у TomTom-а есть открытый стандарт OpenLR на передачу пробкоданных (по сути можно прикрутить что угодно) с привязкой не к идентификаторам, а к “геометрии”, т.е. эти пробкоданные совмещаются с любой картой. Но это пипец сколько надо изучать и разрабатывать. (added: там оказывается уже лежат готовые библиотеки на Яве)
И чтобы поставить точки над i - если вы хотите рисовать собственную геометрию, утаивая её от конкурентов, то ОСМ вам вряд ли подойдет т.к. любой участник потом нарисует на том же месте дорогу и у вас будет дублирование.
Кстати - интересная мысль!
Но все же выглядит довольно рисковано, ведь по сути это будет своя ветка развития дампа, периодически обновляемая с основной (посуточно, например).
Сильно-связанная архитектура получается, которую сложно модифицировать в будущем и тяжело обслуживать.
Но пока это самая интересная версия!
Согласен с вами.
Только вот дамп России JOSM у меня час открывал, но так и не открыл… Вносить свои изменения в локальный дамп похоже станет проблемой…
С исключением - можно держать отдельным слоем области с запретом проезда, обрабатывать данные как обычно, после чего выкидывать ребра попадающие в эти области.
С добавлением несколько сложнее, но в принципе тоже можно реализовать. Просто основываться придется на геометрии, а не на id из осма.
Ну да, дамп весит что-то 40Гб в xml, сколько у вас оперативки?
Да сколько бы ни было - даже если памяти хватит, всё равно будет неюзабельно (типа по полминуты реакции на клик мышкой), JOSM не расчитан на такие объёмы.
Это точно!
Сижу, ковыряюсь в JOSM.
Что если все изменения хранить в отдельном слое?
А в JOSM потом подгружать актуальный участок, к нему догружать свой отдельный слой…
Потом сливать вместе слои, сцеплять ноды (пока не понял как сделать в JOSM), выгружать результат в OSM-файл.
Потом сливать его со свежезагруженным дампом России и отправлять в GraphHopper…
А они нужны? Если у вас ваши данные будут синхронизированы с ОСМ базой, то дамп смержить с вашей базой не составит труда без JOSM.
Пока так и не ясно, какого рода у вас данные будут. Если для ваших целей необходимо будет разбивать дорогу на сегменты, при этом без ваших данных эти сегменты по тегам не различимы, то в ОСМ их держать не хорошая идея. Любой мапер может их объединить ибо ничего не знает о внешнем применении этих сегментов и в ОСМ они тегами не отличаются, вам же нужно разделить, ну и понеслась… Решить подобную проблему уже несколько сложнее. Может, хранить у себя и правила замены сегментов? В ОСМ дорога из одного сегмента, вы ее из локального дампа грохаете и вместо нее вставляете свои 2 сегмента…