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