[Нет связи с сервером.....(все перепробывал в настройках...все равно нет)]

Садишься в машину, пробки словил по wifi, а потом - вася: wifi нет, 3G не подключен...

[Конкуренты не дремлют!]

Почему нет прогноза?

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

 

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

 

Приведу пример.

Допустим, есть альтернатива из Пулково на Чайковского - Пулковское шоссе/Московский или КАД/Витебский.

В 8:00 Витебский еще свободен, пробки перед Лиговским нет, поэтому тащит на него. А потом, когда формируется пробка после Благодатной, тащит на Московский всякими Цветочными улицами, - вместо того, чтобы сразу вести по Московскому.

Так вот.

Если в 8:00 скачаются пробки на участке после Благодатной на Московском и на Витебском, и они будут в рамках текущей статистики, то программа применит статистику на время прибытия (8:35), по которой Московский предпочтительнее. И СГ сразу поведет правильно.

А если данные по Московскому пр. (после Благодатной) на 8:00 будут значимо хуже и статистики на 8:00, и статистической ситуации на Витебском на 8:35, то они будут учтены, и программа поведет на Витебский.

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

[ПДД-флуд]

Не нужно ничего отдавать муниципалам, ни в коем разе. Разметку, светофоры и знаки нужно отдавать только ГИБДДшникам. Сколько спорных моментов возникает при неправильном наказании автовладельцев? Вы объясняете, что неправильно висит знак (нанесена разметка) , а ГАИшник в ответ:- не мы ставили (рисовали) . Нужно создание специального подразделения ГИБДД отвечающего за всё вышесказанное. Тогда и можно будет им "кидать предъявы" за неубранные временные знаки, неработающие светофоры и коряво (неправильно) нарисованную разметку. Ну, как-то так...

Отправлено с ПИШУЩЕЙ МАШИНКИ через ТЕЛЕГРАФ

Вроде за это отвечает контора типа Организация дорожного движения. Т.е. все установки знаков и пр. должны быть согласованы с ней и с ГИБДД. Да, ГИБДД не ставило-рисовало, но оно согласовывало, как ставить и что рисовать, их подпись стоит. Так что вряд ли стоит надеяться, что они всё правильно будут делать.

 

Их обязанность следить за неправильно установленными знаками, в том числе и временными, и пр. В случае выявления нарушения они должны писать всякие бумаги, причем это довольно непросто. Им это надо? Заодно и кормушки себя лишать...

 

На мой взгляд, нужна отдельная контора,  основные функции которой и должны заключаться в соблюдении правильности установки, разметки, состояния... Тогда, если вас оштрафовали неправильно - иск именно к этой конторе, а не искать, кто установил этот знак коряво.  Контора не должна быть связана с ГИБДД - тогда ГИБДД в суде будет незаинтересованным лицом, да и суд, наверное будет получше - хорошие отношения с ГИБДД и самим судьям надо, а что с этой конторы взять?

[Конкуренты не дремлют!]

 

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

Слишком просто, чтобы работало  . Прогноза то нет!

 

Мы просто берем вариант по наихудшим скоростям на данный момент времени и строим неизвестно какой маршрут. Причем, не важно, что мы берем "будущую" статистику. Это всё равно, что при нынешнем алгоритме взять и заменить все зеленые улицы на желтые. Что мы получим? Этот маршрут будет еще чаще перестраиваться, т.к. кроме "локального" изменения пробочной информации, к пересчету будут приводить и замена статистики на пробочную информацию при подъезде к удаленному ребру. "Стратегически" этот маршрут будет более похож на прямую, чем нынешний, но совершенно не факт, что быстрее, т.к. изначально поведет "напролом", совсем не учитывая "повышенную" скорость на окраинах.

 

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

 

Если уж прогнозировать, то учитывая возможные причины пробок, например

1) слишком много транспорта развелось, неоптимальная работа светофора, ежедневный проезд кортежа по Петроградской в 8:50 и т.п.

2) Аварии, ремонты дорог, непериодический проезд слуга народа и т.п.

М.б. плюс к тому иметь модели нарастания/спада пробок, причем с разными параметрами для разных районов, например время приезда ГИБДД может отличаться в разы для разных улиц - на КАД 20 мин, в какой нибудь переулок - 4 часа.

 

Учет п.1 - это и есть статистика. Однако в голом виде ее тоже применять нельзя, т.е. нужна автокореляционная функция "статистики" во времени - степень зависимости средней скорости на ребре в момент времени X от средней скорости на этом же ребре в момент Y.

 

C авариями и пр. чуть сложнее - попал в пробку, делать нечего - такова судьба. Зато используя взаимокореляционные  функции скоростей на ребрах в пространстве и времени (степень зависимости скорости на ребре X в момент Y от скорости на ребре Z в момент W) можно предугадать нарастание/спад пробок на соседних с затором улицам. Например, если на КАД авария и пробка, то через 15 мин пробка уже на улицах около съезда, затем, если авария не устранена, она расползается далее по улицам. И наоборот, если пробка на улицах рядом со съездом уменьшается, значит и на КАД пробка рассасывается.

 

Но это уже слишком сложно, чтобы работало

[Время в пути(время прибытия) прогнозируемое и реальное.]

 А думали ли Вы над такой ситуацией (по скоростям): 10-50-10-50? 

"Кольцевая" - догадался Штирлиц,

"Издевается" - подумал Joss  

[ПДД-флуд]

 

Но сейчас, кажется, в ПДД добавили уже описание этой таблички, так что  - не катит.

 Вот из ПДД "8.24 "Работает эвакуатор". Указывает, что в зоне действия дорожных знаков 3.27 - 3.30 осуществляется задержание транспортного средства".

 

Если следовать этой логике, то если таблички нет, то только штраф.

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

Поэтому я и спрашиваю: "Нафига эта табличка?". 

[Время в пути(время прибытия) прогнозируемое и реальное.]

 Не такие это и длинные периоды.

 

Может быть, может быть...

Только вот я езжу именно в эти периоды

[Пожелания к разработчикам City Guide]

вот поэтому и хотелось бы, чтобы была возможность пробки не отключать, но строить маршрут без их учета.

в конце концов у нас тоже в области можно встрять, но печально когда из-за одного нечаянного следа маршрут строится в объезд по проселкам с крюком огромным

Чего то я не въезжаю...

 

Я пробкам не доверяю, поэтому маршрут нужен без пробок, но пробки я хочу видеть. 

А зачем их тогда видеть, если доверия нет?

И как стыкуется "можно встрять" и "из-за одного нечаянного..."? Я же, глядя на карту, не могу понять - это "нечаянный" след одного или так и есть? Да и программа тоже...

[ПДД-флуд]

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

Еще как!

Это плата за риск! 

Кого безопасней эвакуировать: матиз или гелендваген?

 

 

А вообще, зачем в ПДД ввели табличку "эвакуатор"? Её же отсутствие не гарантирует, что отделаешься только штрафом без эвакуации?

[Использование транспондера при оплате проезда по ЗСД]

Чем чек-бокс отличается от птички, она же галка, она же крыжик... ?

Я имел ввиду, что чек-бокс - это элемент "зашитого" интерфейса, т.е. у всех пользователей по всей стране будет строка "Использовать транспондер на ЗСД?" или "Использовать паромы через Волгу?". В этом случае, что такое ЗСД в Рязани никто не поймет, а паромы на Волге меня в ступор введут.

 

А птичка ставится в списке против конкретного файла ограничений. А этот список м.б. совершенно разным для разных областей и пользователей.

 

Как-то так...

[Время в пути(время прибытия) прогнозируемое и реальное.]

Дык, эта.... Что мы хотим от навигатора? Того и хотим - чтобы  он более-менее точно прогнозировал время в пути. Потому что уже стопицот раз говорилось - точность оценки времени в пути напрямую влияет на прокладку "оптимального" маршрута. А если ошибка в оценке времени в пути достигает 50% и более на часовом маршруте - о какой "оптимальности" маршрута можно рассуждать?

Ну, наверное, всё-таки наоборот: точность оценки времени не влияет, а определяется "оптимальностью" маршрута.

 

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

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

В условиях динамики пробок маршрут будет постоянным, если на каждом ребре скоростные индексы будут предсказаны точно. 

 

Осталось совсем маленько - научиться гадать предсказывать  , причем всем по-разному. 

[Использование транспондера при оплате проезда по ЗСД]

Хотя б так. И тогда добавить в программе возможность выбора из нескольких файлов ограничений, не исключая их одновременного использования

Sent from my GT-N7000 using Tapatalk 4

Тогда только не чекбоксами, а птичками, как при выборе карт... 

[Время в пути(время прибытия) прогнозируемое и реальное.]

Что вы от навигатора хотите . В самолете вам не говорят точное время прибытия . А в небе пока ни пробок  ни светофоров .

Да, точное не говорят, говорят: "расчетное". Ибо ветер у них, то в морду, то под хвост.

 

Ну, а что мы хотим от навигатора...

Вон, в Австралии аборигены без трусов ходят, и это не означает, что я должен не хотеть курить себе очередные штаны с блёстками

[Использование транспондера при оплате проезда по ЗСД]

Особенно классный вариант для всех остальных юзеров, которые не делают файл ограничений, а просто включают и едут.

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

 

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

Хочешь что-то изменить - заходишь в ЛК, меняешь птички "Имею транспондер", "Я грузовик" и т.п. - скачиваешь свой файл и ставишь в навигатор.

[Использование транспондера при оплате проезда по ЗСД]

В карте - отдельная полоса.

В личном кабинете поставил нужные галки - получил свой файл ограничений.

 

Вариант?

[Время в пути(время прибытия) прогнозируемое и реальное.]

Прогнозы - дело неблагодарное!

Получилось правильно - никто и не вспомнит, не похвалит, ведь так и надо.

Ну, а если ошибся - вспомнят всю родословную до пятого колена...

 

Мой маршрут "дом-работа" - "Север-Юг" города. Поездка через город - смело умножаю время СГ на 1.5 и не ошибаюсь.

Поездка по КАД-ЗСД, всякие дачи и пр. - беру чистое время и не ошибаюсь (даже с объездами заторов на КАД и на дачу).

Поездки в своём районе - смотря тоже где: где прибавляю, где нет.

 

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

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

 

Вопрос расчета времени прибытия - есть вопрос прогноза на будущее. Допустим есть алгоритм, который может прогнозировать нарастание-спад пробок. Тогда для расчета времени прибытия маршрут должен строиться с учетом этого прогноза. Причем прогноз всех ребер должен обновляться каждые те же 3 мин и индивидуально для каждого - Вася приедет на ребро №1 в 15:00, Петя в 15:20, а Гена - в 17:43. Возложить эту задачу на WinCE - нереально, на сервер - тогда и маршруты должны строится там, не передавать же каждому "индивидуальную" таблицу скоростей.

 

Как идея, может быть такой вариант:

Разбить весь город на "разумное" количество "квадратов". И для каждого квадрата передавать некие усредненные числа, полученные из статистики, характеризующие ухудшение-улучшение дорожной обстановки в течение ближайших 30 мин, 1 часа, 1.5 часов... Тогда навигатор, построив маршрут, и вычислив первоначальное время, анализирует, через какие "квадраты" проложен маршрут и корректирует время, согласно полученным данным для этих "квадратов" (может быть и для ближайших квадратов).

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

 

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

[Конкуренты не дремлют!]

Все это хорошо для тех программ, которые используют только статистику и не используют живые пробкоданные.

А вот как использовать статистку и расчетные данные при наличии живых пробкоданных - это ИМХО очень большой вопрос.

 

 

Как я уже говорил в теме про пожелания разработчикам, если убрать всякие матрицы, то "на пальцах"одного ребра и одного проехавшего датчика поправку к скорости на ребре можно вычислять с учетом "доверия" к предыдущим данным и датчику как:

Здесь По и Пд - соответственно погрешности скорости на ребре до проезда датчика и погрешность датчика, Vo и Vд - скорость на ребре до проезда датчика и скорость датчика.

Погрешность скорости на ребре после проезда датчика можно определить как:

 

Т.е. степенью "доверия" выступают погрешности - чем больше погрешность, тем менее можно доверять.

 

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

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

Если погрешности одинаковы, то новая скорость - среднее арифметическое, а погрешность (точнее дисперсия) уменьшается в два раза.

 

Т.е. новая скорость и погрешность определяются в зависимости от степеней доверия и статистика здесь фактически - точка отсчета, "генетическая память".

 

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

 

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

[Конкуренты не дремлют!]

Про статистику и анализ данных

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

[Оптимальный проезд через несколько точек.]

А где эту ИГУ можно скачать, которая сама кратчайший маршрут между точками строит? Я бы её вместо СГлайт использовал на начальной стадии, чтобы хотяб понимать, с какого района начать объезд и каким заканчивать.

У меня на ВинЦэ стояла какая-то, я особо не пользовался и этой функции не видел.

Отправлено с моего GT-P3100 через Tapatalk

 

Ну м.б. этот сервис подойдет?   http://www.fsector.ru/

[Время в пути(время прибытия) прогнозируемое и реальное.]

 Единственное, что для того, чтобы уложиться в график программы моих 115 лошадиных сил маловато, приходится малость насиловать машину.

 

???

 

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

[Оптимальный проезд через несколько точек.]

 В результате поездок у меня создалось впечатление, что СГ строит маршру с учетом пробок только на текущем участке пути. При этом на всех прочих участках маршрут строится без учета пробочной ситуации.

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

[Оптимальный проезд через несколько точек.]

Не согласен. Далеко не всегда "порядок не важен". 

Тут давно кото-то приводил красивейший пример с Васей, который едет к Маше, а по дороге ему надо заехать в банкомат за деньгами и в магазин за цветами.

И заезжать в магазин без денег ему так же бесполезно, как заезжать к Маше без цветов.

 

Может тогда, ну её, эту Машу с цветами?

 

В этом варианте последовательность уже жестко задана.

Я лично в подобной ситуации не ввожу промежуточные точки, а строю последовательные маршруты.

Единственное, когда они мне нужны, и то в количестве одной штуки - это построить маршрут с учетом именно заезда, в определенную точку, или чтобы не забыть. Например, выкинуть коллег у метро, заехать на АЗС и т.п.

Т.е., если предполагается выйти из машины, закрыть её, то это у меня - конец маршрута.

 

Мне так удобнее, привычнее

[Оптимальный проезд через несколько точек.]

 

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

 

Вокруг Земли...

За 80 дней...

[Оптимальный проезд через несколько точек.]

Я думаю, об этом даже никто не мечтает, тем более такой пересчет на перекрестке может потрепать нервы.

Мне кажется, что коммивояжерский расчет должен производиться только один раз (ну, или исключительно по ручному запросу).

То есть задал 5 точек, сказал "оптимизировать", они построились в порядке 3,1,4,2,5. И зафиксировались. Едем. 

Дальше мое дело - либо по такому маршруту и еду (например, прикинув этот маршрут, я товар в газель загрузил с учетом порядка выгрузки).

Либо, если хочу, достигнув точки 3 и разгрузившись, нажимаю снова "Оптимизировать" - и оставшиеся 4 точки снова перестраиваются, с учетом изменившейся обстановки.

Насчет количества обсчитываемых вариантов - наверное не все страшно, поскольку например последовательность 1-2-3 можно рассчитать только один раз, а полученную цифру использовать в 6 разных сочетаниях. При этом она в свою очередь использует маршруты 1-2 и 2-3, которые тоже не надо пересчитывать N раз. Но, конечно, не знаю - насколько это реализуемо на ВинСЕ с 128 МБ.

раз в 3 мин.

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

И n! как я понимаю не для набора точек, а для набора рёбер по пути к каждой точки.

Именно для набора точек.

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

[Оптимальный проезд через несколько точек.]

Решение задачи коммивояжера достаточно сложное, насколько я понимаю.

Сложность, я думаю заключается не в построении маршрута, а в неизбежных "стонах пользователей".

 

Если решать задачу "в лоб" методом перебора маршрутов, то нужно будет выбирать из n! вариантов (т.е. если три точки, то количество вариантов будет 1х2х3=6, а если пять точек, то - 1х2х3х4х5=120 и т.д.).

В принципе задача решаемая, тем более на "быстрых" устройствах, да и варианты оптимизации, наверняка, существуют.

 

А вот всякие возможные "зигзагобразные" маршруты (например, есть две точки, куда надо ехать, примерно в одном направлении и примерно на одинаковом расстоянии. Едем вначале к точке 1, хлоп, дорожная обстановка изменилась - теперь едем к точке 2, опять изменилась - едем к точке 1 и т.п.) обеспечат головной болью разработчиков от стонов. 

 

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