Динамическая статистика

[WhAle_15]

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

Это своего рода динамическая статистика. Согласен, звучит каламбурно Попытаюсь объяснить свою мысль подробнее.

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

Так вот. Предлагается ввести индекс текущей загруженности (например, что-то подобное есть у яндекса), расчёт которого зависит от количества активных датчиков и пробкоинфы, поступающих от них. Допустим, от 1 (свободно) до 10 (все встало). На его основании определяем общую загрузку в день (24 часа) и даём оценку этому дню, например, по пятибальной системе. Начинаем собирать суточную статистику таких дней, распределяя их по баллам загрузки. В итоге у нас получается средняя статистика для пяти дней (в зависимости от балла оценки):

* День оценен в 1 балл (самый свободный день) - имеем на него суточную статистику, которую можем применять

* День оценен в 2 балла -//-

* День оценен в 3 балла (средняя нагрузка) - так же имеем на него статистику, которую будем использовать

* День оценен в 4 баллов -//-

* День оценен в 5 баллов (максимально загруженный день) - аналогично

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

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

[niber]

Индекс Шпрото-Кита , короче рыбий индекс

[WhAle_15]

Изучил предложение Шпрота 

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

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

[kmvkmv]

Выглядит разумно! Молодец, Whale!kmvkmv2010-12-17 11:29:26

[Zvezdochet]

что-то в этом есть

[niber]

Ну, я там в первом отклике частично пошутил. ЧАСТИЧНО. На самом деле принцип дифференцированной статистики уже тоже предлагался. Правда, как помнится, дифференциация предлагалась по дням недели или т.п.. В этом смысле введение дополнительного индекса траффик джема (а-ля Яндекс) на первый взгляд выглядит гораздо разумнее, потому что понедельник понедельнику рознь, а в данном подходе этот индекс и сам динамический.

ЗЫ В общем, киты - разумные млекопитающие niber2010-12-18 00:11:19

[WhAle_15]

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

[YoGun]

Что-то мне это напоминает идею "Зависимые пробки" (было обсуждение на форуме, коротко: "если одна улица встала, то и другая тоже"). Мне же кажется, что если б Статистика не была зашита в карту, а обновлялась хотя бы раз в неделю, то уже было бы легче...

 

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

 

Однако, не стоит забывать, что даже сейчас, когда и в Москве датчиков уже прилично, а в Питере некрашенными остаются единичные улицы, СГ не может проложить действительно оптимальный маршрут (что показали уже несколько тестов). Без устранения уже существующих и выявленных проблем, я бы не трогал существующий алгоритм...

 

Тем более, что 3.9 обещают "кардинальные улучшения", а в 4.0 "новую платформу".

 

 

[WhAle_15]

напоминает идею "Зависимые пробки"

Костя' date=' прокомментируй. Что конкретно общего? Я так понимаю в том варианте именно алгоритм "предполагает" появление пробок на основании прилежащих скоростей. В предложенном мной варианте используются только статистические данные.

если б Статистика не была зашита в карту, а обновлялась хотя бы раз в неделю

С этим соглашусь. Гибкость и актуальность системы и данных возрастут.

Без устранения уже существующих и выявленных проблем' date=' я бы не трогал существующий алгоритм...

[/quote']

Согласен - для бранча 3.x.x

А вот тут уже можно было бы и попробовать

[YoGun]

Костя' date=' прокомментируй. Что конкретно общего? Я так понимаю в том варианте именно алгоритм "предполагает" появление пробок на основании прилежащих скоростей. В предложенном мной варианте используются только статистические данные.
[/quote']

 

Возможно мне показалось, что предлагается использовать схему "Если от всех поступают высокие скорости, а по направлению в область всё стоит, то считать этот день 1-м выходным и применить Статистику №1".

Но что в этом плохо, что программа у того, кто поедет первым в 5 или 6 утра, ещё не будет знать какую Статистику использовать, как вести через город или в объезд?

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

 

 

YoGun2010-12-18 18:03:49

[WhAle_15]

Но что в этом плохо' date=' что программа у того, кто поедет первым в 5 или 6 утра, ещё не будет знать какую Статистику использовать, как вести через город или в объезд?

[/quote']

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

В следующем посте приложу картинок, для подогрева мудрых мыслей

[WhAle_15]

Поскольку на сайте нашего СитиГида не публикуется аналитическая

информация, я в качестве иллюстрации приложу несколько картинок с

другого ресурса.

Как мы видим, пробочная активность в день проявляет себя в виде

определённого графика. От дня к дню заметны изменения, в основном,

аддитивной составляющей, на основании чего мы можем проводить сбор

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

стесняйтесь, предлагайте идеи!

[WhAle_15]

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

Точно так же моделируем наборы для выходного дня, предвыходного дня и

предбуднего дня. Итого получаем четыре набора по пять моделей.

Примерно так

[zyph]

Улучшенный индекс Шпрота. По-моему, стоящая вещь. Если уж со статистикой в СГ все крайне плохо, то хоть так.

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

PPS. А саму цифру индекса можно хоть у того же яндекса воровать. :D

Изменено 6 января, 2011 пользователем zyph

[timvetrov]

По-моему, стоящая вещь. Если уж со статистикой в СГ все крайне плохо, то хоть так.

У главного конкурента вообще никакой статистики нет. Если по дороге датчик не проехал, дорога пустая - тянет туда прямо в пробку.

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

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

Изменено 6 января, 2011 пользователем timvetrov

[alexeyT4]

Что-то заглохла темка.

А ведь и до учета времени доезда до пробки здесь недалеко;)

[Vodolazz]

Предлагаю сделать привязку к конкретному месяцу года и номеру дня недели в месяце. Тогда частично решаться проблемы по перенесенным рабочим дням на выходные.

[s35]

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

Изменено 13 сентября, 2011 пользователем s35

[Vodolazz]

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

Не думаю что отходит на второй план, так как для Москвы в часы пик ситуация меняется каждые 5 минут. 15 минут "жизни" данных от датчиков недостаточно. 15 минут было актуально для Москвы до 2005 года.

[borkas]

Кстати, сюда же.

Статистику нужно уметь обновлять отдельно от карт. Как минимум может быть трёхуровневая статистика: зашитая в карту, некий средний срез за последние 2 недели (возможно по дням недели, а может и не надо), текущие показания датчиков.

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

Что поможет решить - новообразующиеся пробки от ремонтов/закрытия/открытия дорог когда датчиков мало (Москва!!). Пример - ищут клад на пересечении Вернадского и Ломоносовского. Капитальный стояк из области на 3-4 км где-то со средней скоростью порядка 5 км/час.

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

[bushmen]

И так с очень многими вновь образовавшимися пробками - и что тут делать? Работать датчиком-камикадзе не тянет

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

[Vodolazz]

Эта пробка постоянная, но туда никто из "продвинутых" не лезет, поэтому текущих данных нет. Т.е. если я утром вдруг решаю посмотреть на СГ, то вижу либо зелёное, либо вообще пусто). И СГ пытается протащить меня через него. И так с очень многими вновьобразовавшимися пробками - и что тут делать? Работать датчиком-камикадзе не тянет

Что бы до конца понимать данную проблему нужна инфа как обрабатывается статистика для СГ в Москве, карта статистики. Может быть это секретная инфо.

СГ пришла из СПб где все улицы окрашены и там статистика адекватная. В Москве я считаю достаточная адекватная статистика в ЯдексПробки (сужу по центру и СевероВосток). Пока в Москве количество датчиков на милион человек не будет достигнуто до уровня СПб, нужно вшивать в прогу статистику с Яндекса для утра и вечера.

А без датчиков камиказде не обойтись, это же и есть главная идея данного продукта, борьба с пробками силами самих же пользователей, кто-то должен лезть в пробку что бы другой не поехал. Вот я уже целый день пытаюсь понять как же все таки собирается статистика, что бы понять как мой ежедневный маршрут дом - работа - дом укладывается в алгоритм программы. Когда будет понятно это можно и датчиком-камикадзе поработать для своего округа. :mellow:

[OlegCh]

Что-то темка заглохла. А для Москвы, где число датчиков явно недостаточно, правильная статистическая информация действительно имеет первостепенное значение! И идея с передачей индекса загруженности для динамической корректировки статистических скоростей - очень хорошая, на мой взгляд.

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

[IШIN]

У меня тут такая мысль родилась. Может, статистику вообще не надо в карту вшивать...

Например, сервер, составляя "пакет пробок" для карты СПб, берет скорости датчиков для всех ребер (для которых они есть, конечно). А для тех, где датчиков нет, берет среднюю скорость по статистике (из своей базы) за аналогичный период (то есть, например, текущая дата плюс-минус десять дней, но отфильтровав только будни, или выходные) за аналогичное время (плюс-минус полчаса). И в результате статистика отсылается в составе пробкопакета, и скорости эти показываются как скорости датчиков (хотя можно и не показывать, чтоб юзер видел, что эта дорога базируется на статистике).

Плюсы -

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

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

[Joss]

А если нет интернета?

Sent from my GT-P1000 using Tapatalk