В чем это его свобода? Производители карт отстегивают за участие в этом мероприятии.
Напомнить куда Навиком с TMС на тесте уехал? 
И вообще, при чем тут ТМС? Это же технология а не конкретный сервис?
И эта технология как раз требует совпадения ID дуг в сводке и в карте.
KekcuHa, я ни разу не хвалил TMC 
Но к конкретной карте (или графу) он всё-таки не привязан - я там специально привёл полную цитату, чтобы не спутать, что именно понималось под “открытым” сервисом. Требует он совпадения своих кодов, а не дуг.
Собственно, OpenLR как раз и разрабатывали, чтобы избавиться от недостатков TMC. И он тоже технология, а не сервис.
Если я правильно понял то идея то следующая.
Есть некий набор первичных стат. данных - треки.
Есть граф дорожной сети
Есть индексы ребер графа дорожной сети рассчитываемые на основе первичных стат. данных.
Если происходит изменение в графе дорожной сети - то необходимо пересчитать индексы для изменившегося участка, для этого надо сопоставить первичные данные и новую версию графа - это долго но это происходит на сервере, не на клиенте.
У клиента есть некоторая версия графа, клиент запрашивает индексы для набора ребер той версии графа дорожной сети которая у него установлена. Чтобы карта на сервере и на клиенте условно говоря, совпадали, на сервере необходимо хранить некоторую ретроспективу графа дорожной сети и индексов.
Вроде все жизнеспособно.
Поясню на примере:
В 0 часов 0 минут дня x вованиум коммитит перерисованную из двухвейки в одновейку Молодогвардейскую
были путь id1 путь id2 стало путь id3
на следующий день водитель А скачивает карту с обновленной Молодогвардейской
водитель Б не столь расторопен и катается со старой версией
Навигатор водителя А привязывает его к обновленной Молодогвардейской id3
Навигатор водителя Б привязывает его к старой Молодогвардейской id1 (точнее к одному из веев которые раньше составляли Молодогвардейскую)
Таким образом на сервере надо хранить индексы для веев 1 2 3. (Для веев 2 и 3 не вечно, а месяца 2-3 (от вычислительных мощностей зависит))
и пересчитывать за разумный промежуток времени (за промежуток между релизами версий карты) индексы для различных версий карты.
Помоему ничего невозможного нет.
А путь не редактирования чего-либо потому что пробки сломаются тупиковый. Даже если вы нарисуете отдельный стандартизованый граф специально для пробок (кто бы еще взялся делать двойную работу) в него всеравно переодически придется вносить корективы.
Бага рутера на скрине, и действительно, отношения к сопоставлению графов или пробкам она вообще не имеет. КексиНа про другое писал.
А покетгис с пробковоротом закрытые?
Не нашел на сайте лицензии.
Намеков на исходники тоже не нашел - так что видимо бесплатная но закрытая.
Закрытые. Бесплатные, но закрытые.
//Бага рутера на скрине, и действительно, отношения к сопоставлению графов или пробкам она вообще не имеет. КексиНа про другое писал.
Ничего не понял.
Zkir, Кексина не про рутер вообще писал.
А скрин и правда не в тему - там на МКАДе односторонне не в ту сторону проставлено )))
Это-то и плохо.
Кексина [как Зкир его понял] писал о том что если дорожные графы на сервере и в клиенте не будут совпадать, это приведет к тому что (а) пробки на близкорасположенных параллельных дугах перепутаются и зачем-то при этом упомянул (б) микрообъезды по дворам и заправкам.
На это Зкир возразил, что (б) система не должна предлагать объезды по дворам и заправкам ни в каком случае. То, что некоторые навигационные программы предлагают ехать дворами, если им кажется что так быстрее, чем через улицы (а так с ними случается и без всякого сопоставления, на своем родном дорожном графе), есть чистая бага рутинга этих программ. (Сквозной проезд по дворам и заправкам запрещен ПДД и порицается многими участниками дорожного движения) и (а) При сопоставлении двух дорожных графов близкорасположенные параллельные ребра в самом деле могут перепутаться, но для пробочного сервиса эти ребра и так плохоразличимы или даже вообще не различимы, так что сильно хуже от этого стать не должно.
То есть ты хочешь сказать, что пробкосервис технически не имеет возможности отличить движение по дублеру от движения по основному профилю?
Ezhick
если дублёр находится в пределах погрешности навигатора - то, конечно, не имеет. А что?
PS: Говорят, Waze умудряется создавать одну дорогу по разным трекам пользователей.
Если маршрутизация включена и ведёт, например, по дублёру, то вероятнее всего трек тоже к дублёру относится.
А с помощью OpenLR нельзя ли сделать обработку существующих треков для определения статистического скоростного индекса дорог?
Я бы ещё добавил что в пробке на заправку свернуть легко, а вывернуть с неё совсем нет, поэтому алгоритм такого объезда плохой, негодный.
А если данные о пробках привязывать не к графу, а к квадратам на местности?
Скажем 5х5 метров. Клиент будет получать информацию о скорости в квадратах и считать, что по всем дорогам, которые идут по этим квадратам в этом месте скорость движения вот такая.
Чтобы разделить информацию о разных направлениях и на перекрёстках, можно сделать 2-4 значения для каждого квадрата - скорость движения в некотором секторе скоростей. Направление и скорость берётся по данным с датчиков.
Если о квадрате никаких данных нету (лес/поле/дома) - ничего о нём не передавать. Разреженная матрица и т.п.
Ну дык это проблема навигатора, а не пробкосервиса.
Получится ОГРОМНЫЙ объем информации. Это “битмап” вместо “вектора”
Растр. Да, огромный. Но разреженный, а значит - хорошо упаковываемый.
Алгоритмов упаковки растра уже море, а алгоритм совмещения графов ещё изобретать придётся.
И вообще, умные люди от программирования говорят, что сначала нужно рабочий алгоритм сделать, а потом уже его оптимизировать.
Это я к тому, что даже если дороги расположены близко, отличить, к какой дороге относится трек, можно в автоматическом режиме (естественно, навигатор должен сообщить пробкосервису об этой связи).