Ezhick, посмотри внимательно пост №10. Пробочный граф, положенный в основу открытого пробочного сервиса, должен быть независим от веев в osm. Именно потому что веи в osm меняются каждый день, а карта в клиентском устройстве - нет.
P.S.
Оcтаюсь при убеждении: одна проезжая часть - один веей. 
Zkir, если в двух словах - кодируются и передаются данные для коротких однозначных маршрутов.
Дальше эти маршруты на навигаторе геометрически привязываются к конкретной карте.
Боюсь даже представить сколько времени средний навигатор будет тратить на наложение пробок на граф дорожного движения в, например, Москве… А если переложить это на сервер то обновлять карту на навике и сервере необходимо будет одновременно.
Я коммент давал к посту номер 5. Про стабильность графа. Отдельный граф для пробок считаю утопией. То, что нет работающих систем с таким подходом и все ведущие производители пробочных сервисов привязывают пробки к графу ДД, тому подтверждение.
Ezhick, если статистику зашивать в карты, а не держать на сервере, то особо ничего накладывать не придётся - только пару случайных аварий и ремонтов
Рекомендации лучших собаководов:
Если карты на сервере и на клиенте не будут совпадать, то на клиента маршруты будут строится с “прелестями” типа микро-объездов через заправки, дворы, дублеры и по прочим близко расположенным параллельным дугам.
Ezhick
KekcuHa
liosha ответил более точно, видимо то что я написал - всего лишь частный случай сопоставления “коротких однозначных маршрутов”. Если форма такого маршрута не совпадет с тем что передан с сервера (т.е. в карте навигатора нет каких-то участков), сопоставления не произойдет.
liosha, в неделе 7 дней, из них два выходных, а в сутках 24 часа, которые все очень разные, кроме 8 часов ночью, когда большинство спит. Итого мы имеем минимум 100 временных отрезков для которых нужно зашить данные в карту, это если брать минимальный отрезок в час и все дни в неделе делить на будни и выхи. Ты все это в карту зашьешь? Ну-ну, флаг тебе в руки.
Это чисто пгисные проблемы, не надо думать, что они есть у всех 
Сам метод OpenLR при грамотном использовании их не порождает
Ты действительно думаешь, что делить неделю на часы, и вбивать данные за каждый час - это единственно возможная статистическая модель??
Проблем нет у тех, кто ничего не делает. Давай продолжим спор тогда, когда будет связка из навигационной софтины и пробок на базе предлагаемых вами алгоритмов
Нет, делить надо на гораздо меньшие промежутки с учетом гораздо большего количества факторов. Но карта тогда станет неподъемная. И это не решает проблемы несовпадения графа и карты пробок.
Хоть по минутная речь была не о том
Не вопрос, вариантов много. Просто я считаю зашивку статистики в карту без онлайн-обновления ее для всей карты, а не только для аварий и ремонтов - тупиковой идее.
Их кагбэ томтом предлагает, а не мы 
Правильно, не надо валить всё в кучу.
Проблему несовпадения графов OpenLR решить может.
А проблема большого трафика решается грамотным зашиванием статистики в карту.
Не вопрос, флаг вам в руки.
Сквозная навигация через дворы и заправки - это просто бага рутера. Никакого отношения к сопоставлению графов или пробкам она вообще не имеет.
Дублеры - серьезная проблема, но имхо не разрешимая. Даже с точки зрения получения пробкоданных от датчиков. Если есть две близких параллельных дуги, то по gps-треку (при нынешней точности gps) нельзя определить по какой именно проехал датчик. Так что на дублерах пробки так или иначе перемешаны.
Покажи мне хоть один открытый пробочный сервис с таким подходом. Если пробкосервис работает по принципу - вот вам карта (граф ДД), ее юзайте для навигации, в чем тогда его открытость? 
Ошибочное утверждение. В следующее воскресенье это будет не так.
Покажи мне хоть один работающий открытый пробкосервис…
TMC