Перейти к содержанию
GPS навигатор СитиГИД

Рекомендуемые сообщения

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

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

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

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

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

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

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

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

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

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

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

  • Upvote 1
Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Ссылка на сообщение
Поделиться на другие сайты

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

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

Ссылка на сообщение
Поделиться на другие сайты

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

Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

 

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

 

 
Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

[/quote']

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

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

  • Upvote 1
Ссылка на сообщение
Поделиться на другие сайты


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

 

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

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

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

 

 
YoGun2010-12-18 18:03:49
Ссылка на сообщение
Поделиться на другие сайты

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

[/quote']

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

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

  • Upvote 1
Ссылка на сообщение
Поделиться на другие сайты

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

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

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

20101218_183658_analitic.JPG

20101218_183837_analitic_week.JPG20101218_183959_analitic_week.JPG

20101218_184158_analitic_year.JPG

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

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

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

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

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

  • Upvote 2
Ссылка на сообщение
Поделиться на другие сайты

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

20101219_013142_Budni_model.jpg

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

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

Примерно так Smile

  • Upvote 2
Ссылка на сообщение
Поделиться на другие сайты
  • 3 недели спустя...

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

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

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

Изменено пользователем zyph
Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

Изменено пользователем timvetrov
Ссылка на сообщение
Поделиться на другие сайты
  • 5 месяцев спустя...
  • 2 месяца спустя...

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

Ссылка на сообщение
Поделиться на другие сайты

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

Изменено пользователем s35
Ссылка на сообщение
Поделиться на другие сайты

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

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

Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

Ссылка на сообщение
Поделиться на другие сайты

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

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

Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

Ссылка на сообщение
Поделиться на другие сайты
  • 1 месяц спустя...

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

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

Ссылка на сообщение
Поделиться на другие сайты

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

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

Плюсы -

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

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

  • Upvote 1
Ссылка на сообщение
Поделиться на другие сайты
Гость
Эта тема закрыта для публикации ответов.
×
×
  • Создать...