И снова про статистику

[niber]

<..>адекватные скоростные индексы поставить и корректировать - самое оно. И не надо специальных людей' date=' которые бы написали, что вот тут дорога плохая, а вот тут асфальт новый положили и светофоры убрали. Начали регулярно ездить под 120, значит и индекс у дороги не может быть 40 <...> Речь идёт об изменении скоростных индексов (которые "скорость потока").  <...> [/quote'] Как сказала команда СГ, индексы корректируются по полученным данным. А по поводу статистики с учетом времени суток и т.п. я не берусь полностью отрицать ее пользу (нет опыта применения и нет гигантского ума Кашпировского для предсказания последствий такого применения), но имею сомнения на этот счет. Едем мы "здесь и сейчас", а не вообще, и роль сиюминутных факторов в траффике, ИМХО, весьма велика. Статистика хороша тогда, когда имеем медленно меняющийся во времени и  по амплитуде процесс. Как известно, средняя температура по больнице совершенно не помогает выжить больному с Т=42С, несмотря на то, что у кого-то всего 36. "Дорога полна неожиданностей" (с), не детских. Если кто-нибудь имеет доказательные соображения ума, что статистика работает в плюс, прошу, поделитесь, готов принять разумные аргументы.

[alexeyT4]

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

А потом сравнить со скоростными индексами на карте.

По идее большинство(не я, мои знакомые) ездит 5 раз в неделю одним и тем же маршрутом и наблюдает одну и ту же картину.

 

Причем если происходит задержка выезда из дома, хотя бы на 10-15 мин., то человек уже попадает в пробкИ.

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

 

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

Чем не статистика? Ведь люди не по одному месяцу ездят, а бывает годами.

 

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

[plitkin]

Как сказала команда СГ' date=' индексы корректируются по полученным данным.[/quote']

Это утверждение настолько же верно, насколько верно утверждение "скорость автомобиля, стоящего перед перекрёстком, равна скорости автомобиля, этот перекрёсток покидающего"...

 

[plitkin]

 

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

Эта хаотичность - только в нашем восприятии. Всё поддаётся учёту.

[evgenyK]

...Если кто-нибудь имеет доказательные соображения ума' date=' что статистика работает в плюс, прошу, поделитесь, готов принять разумные аргументы.[/quote']

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

[baltica]

Если кто-нибудь имеет доказательные соображения ума' date=' что статистика работает в плюс, прошу, поделитесь, готов принять разумные аргументы.[/quote']

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

[YoGun]

[Rocas]

[Spectre]

Понижение текущих индексов с 40 до 30 ничего не исключит. А в большинстве случае скоростные индексы сейчас стоят именно 40.

 

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

 

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

[baltica]

 

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

Я просто привел это в качестве примера, т.к. спрашивали о реальных плюсах статистических данных.

Согласен с тем, что Вы написали на 100%

[lipskiy]

Если кто-нибудь имеет доказательные соображения ума' date=' что статистика работает в плюс, прошу, поделитесь, готов принять разумные аргументы.[/quote']Статистика должна работать в плюс тогда и только тогда, когда нет актуальных данных от реальных датчиков. В этих случаях средняя температура по больнице несет хоть какую-то информацию, нежели вообще отсутствие оной. Нынешние статичные индексы можно считать отсутствием информации, это можно сравнить со средней температурой по городу. Я полностью за динамическую статистику, разбитую по часам, дням, выходным/будням, временам года и так далее.

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

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

[dimdim]

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

[alexeyT4]

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

Или это какой-то слишком сложный процесс? Типа на каждое время переключать скоростные индексы - ой как заморочено.

[Rocas]

Понижение текущих индексов с 40 до 30 ничего не исключит. А в большинстве случае скоростные индексы сейчас стоят именно 40.

 

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

это ответ на мой пост? Тогда меня неправильно поняли. Во-первых, я, ессно, говорил про дифференцированные по времени индексы. Кроме того, цифры 30, 40 и 60 - только для примера. Речь о том, что нельзя статистикой снижать скорость потока радикально. Допустим, более, чем в 2 раза от исходной.

А снижения в 2 раза более, чем достаточно, чтобы исключить все лишнее.

[svgpro]

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

Или это какой-то слишком сложный процесс? Типа на каждое время переключать скоростные индексы - ой как заморочено.

А может просто нет ресурсов (в т.ч. и людских) для выполнения такой объемной работы???

[lipskiy]

Работа эта не объемна и не заморочна. Статистика копится в автоматическом режиме на серверной стороне. Варианты реализации на стороне клиента тоже не раз предлагали, никакого особого гемора нет. Главная проблема, кмк, разработчики не видят преимуществ в этой идее в принципе.

[Spectre]

Во-первых, я, ессно, говорил про дифференцированные по времени индексы. Кроме того, цифры 30, 40 и 60 - только для примера. Речь о том, что нельзя статистикой снижать скорость потока радикально. Допустим, более, чем в 2 раза от исходной.
А снижения в 2 раза более, чем достаточно, чтобы исключить все лишнее.

А как определить эти-самые исходные значения?

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

Просто покатался я тут вечером в час-пик по Москве. Ну СГ меня опять с медленно, но уверенно едущего Садового кольца упорно пытается увести на глухо стоящее бульварное.

 

[Naragoth]

А зачем хранить диффернецированные индексы, если можно хранить функцию с меньшим количеством параметров?

[plitkin]

На самом деле работа довольно объемна:

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

2) Необходимо продумать и реализовать схему передачи этих стат. индексов на устройства пользователей без излишних затрат траффика

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

[YoGun]

Ну СГ меня опять с медленно' date=' но уверенно едущего Садового кольца упорно пытается увести на глухо стоящее бульварное.[/quote']

 

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

(и возвращаясь к тестированию, вот будет смешно, если маршрут построится по Проектируемому пр-ду 5396, а далее через Люблинскую на Волгоградку - и там, и там можно потерять минут сорок на одном месте. Не сочтите меня не патриотом, но если СГ проиграет, то может быть разработчики задумаются. Есть такая надежда.)

 

[Spectre]

А зачем хранить диффернецированные индексы, если можно хранить функцию с меньшим количеством параметров?

Например?

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

Еще как надо. Я, конечно, не знаю точно как реализована структура графов и корректур сейчас, но подозреваю, что без переделки неободется.

[lipskiy]

На самом деле работа довольно объемна:

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

2) Необходимо продумать и реализовать схему передачи этих стат. индексов на устройства пользователей без излишних затрат траффика (как показывает пример ДПОИ - с этим у разработчиков СГ тоже есть серьезные проблемы).

3) Необходимо выделить сервер, настроить БД для сбора и обработки статистики. Это тоже не тривиальная задача.

4) Необходимо разработать алгоритмы обработки статистических данных.

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

Как программист, имеющий реально работающие публичные проекты (не навигационные, но тем не менее), не согласен.

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

2. Закачка сжатых файлов - задача тривиальная.

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

4. Это процесс поэтапный, для начала достаточно было бы простого усреднения, а оптимизировать можно не спеша по ходу.

5. Это вообще отдельная от статистики проблема глобального характера. А ребра, где статистика пока недостаточна, можно помечать скоростями из вшитых индексов.

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

[plitkin]

Еще как надо. Я' date=' конечно, не знаю точно как реализована структура графов и корректур сейчас, но подозреваю, что без переделки неободется.[/quote']

Я имел в виду рассылку файла корректур с измененными скоростными индексами несколько раз в сутки. Это можно хоть сегодня сделать, от пользователей и программы при этом не потребуется никаких дополнительных действий. Как самый простой вариант решения проблем №1 и 2.

[Spectre]

Как программист, имеющий реально работающие публичные проекты (не навигационные, но тем не менее), не согласен.
1. Доработки нужны, но это простая задача. Нет необходимости делить вшитые индексы и статистику по разным уровням, это данные одного уровня, вшитые - данные по умолчанию, подгружаемые - если они есть, то полностью заменяют собой вшитые.
2. Закачка сжатых файлов - задача тривиальная.
3. Насколько я знаю, сбор статистики на сервере давно реализован. А если это не так - задача совершенно тривиальная, ну нет тут ничего сверхъестественного для более-менее профессиональных людей.
4. Это процесс поэтапный, для начала достаточно было бы простого усреднения, а оптимизировать можно не спеша по ходу.
5. Это вообще отдельная от статистики проблема глобального характера. А ребра, где статистика пока недостаточна, можно помечать скоростями из вшитых индексов.

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

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

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

[Spectre]

Я имел в виду рассылку файла корректур с измененными скоростными индексами несколько раз в сутки. Это можно хоть сегодня сделать, от пользователей и программы при этом не потребуется никаких дополнительных действий. Как самый простой вариант решения проблем №1 и 2.

Корректировать скоростные индексы рассылкой корректур несколько раз в день? Это же надо корректуры на всю карту слать! Очень много получится.

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