Ещё одна идея касательно веса пробок

[Alligator.]

На днях мне в голову пришла следующая мысль, которая ещё ни разу не встречалась мне в форуме.

Еду я к примеру с работы домой вечером в час пик. После того, как выпал снег, дорога занимает около двух часов.
При прокладке маршрута большую роль играет наличие или отсутствие пробки на МКАД около дома.
Но за те полтора часа, что я буду до неё ехать, она вполне может как рассосаться (если она есть), так и возникнуть (если её нет).

Другими словами, связь между наличием или отсутствием пробки в данный момент и в интересующий меня момент (когда я туда доеду) весьма слабая (имхо).

Мне кажется была бы полезна (в таких ситуациях) функция перевзвешивания пробок по ходу маршрута.
Т.е. чем дальше пробка от начала маршрута (желательно по времени движения), тем меньше её вес.

[ASPEED]

чик... чик...

Но за те полтора часа, что я буду до неё ехать, она вполне может как рассосаться (если она есть), так и возникнуть (если её нет).


чик.... чик...
.

Для того чтобы этого не случалась я включаю две опции:
регулярное обновление пробок
перепрокладывать маршрут после обновления пробок

А рассосется или нет пробка, это даже гидрометцентр не сможет предположить

[Alligator.]

Для того чтобы этого не случалась я включаю две опции:
регулярное обновление пробок
перепрокладывать маршрут после обновления пробок

А рассосется или нет пробка, это даже гидрометцентр не сможет предположить

Естественно, у меня тоже обновляются пробки и перепрокладывается маршрут. Но вопрос не в этом.

Мой конкретный случай: я еду от м.Проспект Мира до м.Планерная.
Возможно несколько вариантов, например, можно выбраться по проспекту Мира, Алтуфьевскому шоссе и/или ул.Декабристов и т.д. на МКАД и доехать по МКАД до ул.Свободы.
А можно ехать по Ленинградке-Волоколамке-Свободы.

Если на МКАД нарисована пробку в районе Ленинградки, то вместо первого маршрута предлагается второй. Но на самом деле если выезд на МКАД по первому варианту без больших пробок, то это может быть и быстрее.
А когда я ушёл на Ленинградский проспект, то даже если пробки обновятся, уже поздно что-либо менять ...

[Chuk_I_Gek]

Если на МКАД нарисована пробку в районе Ленинградки, то вместо первого маршрута предлагается второй. Но на самом деле если выезд на МКАД по первому варианту без больших пробок, то это может быть и быстрее.
А когда я ушёл на Ленинградский проспект, то даже если пробки обновятся, уже поздно что-либо менять ...

А вот для этого требуется голова. Ее, в отличие от GPS не в коем случае отключать нельзя )

[Alligator.]

А вот для этого требуется голова. Ее, в отличие от GPS не в коем случае отключать нельзя )

Если все вопросы, связанные с выбором маршрута и навигацией, решать своей головой, то PocketGPS не нужен.

[VctOs]

Т.е. чем дальше пробка от начала маршрута (желательно по времени движения), тем меньше её вес.

Допустим, это технически реализуемо.
Но почему вес затора с течением времени должен обязательно уменьшаться?
А если в текущий момент времени затор только образуется и через полтора часа там будет полная остановка движения?
Т.е. по уму нужна коррекция не тупо вниз, а в соответствии с прогнозом развития ситуации.
С одной стороны построить прогностическую модель заторов, вероятно, возможно, с другой априорно известно, что ни 100% ни 90%точности никакая модель предсказания зависящих в т.ч. от ДТП заторов не обеспечит: погоду на сутки вперед предсказывать проще.

[Alligator.]

Какая бы не была модель прогнозирования, чем больше период времени, на который мы прогнозируем, тем меньше вероятность исполнения прогноза.
Именно поэтому я и предлагаю уменьшать вес пробок пропорционально тому времени, через которое я до этой пробки доберусь.
В качестве модели прогнозирования развития пробки я предлагаю взять метод naive forecast - через минуту (час, день) будет также как сейчас. Меня учили, что использование более сложных методов прогнозирования осмысленно только тогда, когда они дают результат лучше, чем naive forecast.

[Alligator.]

А ещё иногда хочется пробкам на карте присвоить отрицательный вес, потому что создается ощущение, что в тех местах, где на карте нарисована пробка, вероятность её встретить меньше, чем там, где пробки не нарисовано.

[VctOs]

Какая бы не была модель прогнозирования, чем больше период времени, на который мы прогнозируем, тем меньше вероятность исполнения прогноза.

Разумная идея.

Именно поэтому я и предлагаю уменьшать вес пробок пропорционально тому времени, через которое я до этой пробки доберусь.

Вес затора для меня это показатель степени затруднения дорожного движения. В конечном итоге - показатель увеличения затрат на преодоление помеченой затором дуги.
Снижение веса, соответственно - это улучшение дорожной обстановки.

В качестве модели прогнозирования развития пробки я предлагаю взять метод naive forecast - через минуту (час, день) будет также как сейчас. Меня учили, что использование более сложных методов прогнозирования осмысленно только тогда, когда они дают результат лучше, чем naive forecast.

Меня naive forecast'у не учили, но то, насколько я этот метод понимаю, если сегодня температура воздуха 20 градусов, разумно в первом приближении принять гипотезу о том, что и завтра температура будет 20 градусов. Т.е., применительно к затору - то, что он через минуту, час, день останется таким, каким он есть сейчас. Так?
Сейчас у затора вес, допустим = 3, значит по naive forecast через час он будет столько же, т.е. матожидание та же трешка, но с большим доверительным интервалом, например от 1 до 5. Так-же, как и предсказывают температуру на завтра: от 23 до 26 градусов.
Никто ведь, насколько я понимаю, не отталкивается от идеи того, что по методу naive forecast из-за снижения вероятности прогноза температуры мы должны понижать величину матожидания этой самой температуры в зависимости от величины времени, на которое делается прогноз?

[VctOs]

А ещё иногда хочется пробкам на карте присвоить отрицательный вес, потому что создается ощущение, что в тех местах, где на карте нарисована пробка, вероятность её встретить меньше, чем там, где пробки не нарисовано.

Отрицательный вес как уменьшение времени проезда по дуге относительно заложенной в графе оценки? Я об этом недавно думал в связи с появивляющимися на 77 "зелеными" стрелками для мест, по которым есть информация о том, что проезжая часть относительно свободна. Но пока это на стадии курьез-идеи.

В текущей версии ядра поддерживаются 8 градаций заторов (+ запрет проезда как девятая градация), а также возможность назначения независимого времени жизни каждого затора. Т.е. если оператору (имеется ввиду оператор 77.RU, о Вессолинке у меня информации нет) известно, что затор минут через пятнадцать рассосется, он может установить время жизни затора 15 минут и через 15 минут (с момента ввода оператором) этот затор будет удален в клиентском приложении.

Так-же ядро допускает возможность вызовом соответствующей процедуры "убивать" или изменять вес для отдельно взятой пробки.

Но все это, конечно, не совсем то, что предлагаете Вы.
Затор на МКАД с временем жизни 40 минут удалится тогда, когда Вы уже будете ехать по Алтуфьевскому. Т.е. деться уже будет некуда.

[Alligator.]

В том то и дело. Для меня затор - это не только (и не столько) показатель того, за сколько времени я проеду данную дугу графа. Для меня затор - это прежде всего некоторая дополнительная информация, с помощью которой программа предлагает мне оптимальный (по времени) путь от точки а до точки в.

Суть моей идеи в том, что если есть две дуги, скажем б и г.
В данный момент на б есть пробка, на г нет пробки.
Но я доеду до дуги б или г только через час.
В таком случае меня не интересует наличие/отсутствие пробки сейчас, меня интересует наличие/отсутствие пробки через час.

В настоящий момент программа "предполагает" что через час пробки будут такие же как и сейчас.
Другая, оппозиционная точка зрения - несмотря на то, что сейчас на б - пробка, а на г - нет пробки, вероятность того, что через час будет пробка на б или г одинакова (тогда существующую информацию о пробке на дуге б вообще не надо использовать при прокладке маршрута).

Я считаю, что как обычно, истина где-то между ...

[Alligator.]

Ну а идеальным вариантом конечно была бы продвинутая система прогнозирования пробок на основе накопленной статистики.

Т.е. по существующей фактической информации за последний, скажем, месяц, можно для каждого участка карты посчитать, в какие дни и в какое время тут бывает пробка, и если это повторяется регулярно, то можно считать, что и в ближайем будующем оно будет также, и это можно учитывать при прокладке маршрута ...

[Chuk_I_Gek]

Ну так в чем проблема. Пишите алгоритм и вперед за Нобелевкой

[Alligator.]

Ну, по-моему особых проблем с алгоритмом нет.
Я думаю, что каждый третий выпускник физ-мат школы за пятерку по программированию его напишет более-менее приемлемым способом.

Вопрос в том, что нужен нормальный сервер, который будет стастистику по пробкам обрабатывать, и самое главное, передавать PocketGPS (вместе с информацией по пробкам), который в свою очередь будет эту информацию учитывать для более релевантной прокладки маршрута.

[VctOs]

Вопрос в том, что нужен нормальный сервер, который будет стастистику по пробкам обрабатывать, и самое главное, передавать PocketGPS (вместе с информацией по пробкам), который в свою очередь будет эту информацию учитывать для более релевантной прокладки маршрута.

Сервер есть. Главный вопрос в том, где взять такую статистику: она должна основываться по возможности на надежных данных, полученных инструментальными методами. Городу ежегодное обследование условий дорожного движения стоит несколько сотен тысяч долларов, но за эти деньги едва удается установить параметры в отдельно взятых местах в конкретно определенные дни.
http://www.77.ru/forum/viewtopic.php?t=467