Средняя скорость для ребер в определенный час

[tilorn]

По моему Шпрот предложил отличный алгоритм. Абсолютно очевидно' date=' что он улучшит программу. Ни одного логичного довода против я не увидел. Ну а разработчикам, очевидно, пофиг. 

[/quote']

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

1. Утром и вечером весь город стоит в пробках. Утром я могу легко доехать из центра на окраину, а вечером с окраины в центр. Алгоритм Шпрота никак не учитывает эту ситуацию, никак вообще.

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

[tilorn]

Приведите' date=' пожалуйста, пример, когда весь город стоит, а вы лихо проскакиваете по маленьким улочкам и дворовым территориям.[/quote']

привожу пример, чем здесь поможет скоростной индекс.

утро, СПб, весь город стоит, стоит к центру.

я из центра за 10 минут доезжаю на работу на пр. Просвещения (самый север города), по известным мне быстрым ребрам. Часто программа ведет меня по заведомо более медленным в _это_ время ребрам.

что будем делать?

[tilorn]

Вы же сами по кругу ходите: я вам уже кучу примеров привел' date=' что это не так. На магистралях, в самых пробочных местах очень часто НЕТ инфы. Вообще. Москва.[/quote']

Подтверждаю на 100%. Раз в неделю-две бываю в Москве. Для СПб эта проблема тем не менее тоже очень и очень актуальна. Причем даже, если как предлагалось тупо будем увеличивать количество пробкодатчиков - то новые опять быстро научатся эти пробкоместа объезжать. Замкнутый круг.

[Шпрот]

 Часто программа ведет меня по заведомо более медленным в _это_ время ребрам.

что будем делать?

 

Да я разве когда-нибудь говорил, что против статистики?

Наоборот, за.

 

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

Ещё в идеале - сделать зависимые пробки, если глухо стоит Московский, избегать улицы Бассейной, Кузнецовской и пр.

 

Будет это кто-то делать?

 

Теперь по поводу вашего примера.

Текущая ситуация кардинально не изменится, т.к. коэффициент понизит скорость на всех неизведанных дорогах на Х процентов.

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

 

Вы же не будете спорить:

В час пик (Питер), если программа объезжает пробку через непроверенное ребро - вероятность попасть в полную Ж составляет процентов 70!

 

Цель этого индекса - при низкой скорости передвижения по городу отдавать предпочтение проверенным скоростям!

 

[Simfo]

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

1. Утром и вечером весь город стоит в пробках. Утром я могу легко доехать из центра на окраину, а вечером с окраины в центр. Алгоритм Шпрота никак не учитывает эту ситуацию, никак вообще.

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

Эти доводы не логичны. Они просто справедливы. Вот для примера тоже справедливые  высказывания:

1. Волга впадает в Каспийское море.

2. Весной у шизофреников обострения случаются чаще.

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

Обсуждаемый алгоритм про степень доверия к скоростям намертво вшитым в карту. Чем загруженней город, тем доверия меньше.  ТОЛЬКО про это. Сейчас это вообще никак не учитывается.

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

[shooo]

Обсуждаемый алгоритм про степень доверия к скоростям намертво вшитым в карту. Чем загруженней город' date=' тем доверия меньше.  ТОЛЬКО про это. Сейчас это вообще никак не учитывается. Динамическая информация для каждого ребра, учитывающая направление, время и день недели конечно лучше. И намного лучше. Никто с этим не спорит. Но в реализации это гораздо сложнее.[/quote']

+1

[Spectre]

По моему Шпрот предложил отличный алгоритм. Абсолютно очевидно' date=' что он улучшит программу. Ни одного логичного довода против я не увидел. Ну а разработчикам, очевидно, пофиг.  [/quote']

Или не хотели увидеть.

Прочитайте еще раз мои доводы про математику.

А по данному предложению скажу: прокладка маршрутов от применения такого алгоритма ухудшится, судя по всему, везде, кроме Питера.

 

Максимальную загрузку дорог можно сделать еще одним фактором при сборе статистики.

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

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

[Spectre]

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

Ещё в идеале - сделать зависимые пробки, если глухо стоит Московский, избегать улицы Бассейной, Кузнецовской и пр.

 

Будет это кто-то делать?

 

НИКТО! Это должно делаться автоматически. В полностью автоматизированном режиме.

 

Как это не изменится?! Как раз изменится!

Если в этот день, в это время, по этому ребру, в этом направлении в 70% случаев некая скорость получается от датчиков, значит через некоторое время скорость на этом ребре, если оно не разведано, будет именно такой, какой ВЫ ее себе представляете и какой она будет с наибольшей вероятностью.

[Spectre]

Эти доводы не логичны. Они просто справедливы. Вот для примера тоже справедливые  высказывания:
1. Волга впадает в Каспийское море.
2. Весной у шизофреников обострения случаются чаще.
Никакого отношения к обсуждаемому алгоритму эти высказывания не имеют. 
Обсуждаемый алгоритм про степень доверия к скоростям намертво вшитым в карту. Чем загруженней город' date=' тем доверия меньше.  ТОЛЬКО про это. Сейчас это вообще никак не учитывается.

Динамическая информация для каждого ребра, учитывающая направление, время и день недели конечно лучше. И намного лучше. Никто с этим не спорит. Но в реализации это гораздо сложнее.
[/quote']

В чем сложность реализации? Может расскажете?

[shooo]

Максимальную загрузку дорог можно сделать еще одним фактором при сборе статистики.

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

[Шпрот]

shooo

Согласен!

 

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

 

Тем не менее, если бы это было так, то вшитые значения имели бы вид "33", "47", а не "50" и "60".

 

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

 

Да и сейчас такие места есть - дорога на Ивангород со смешным предупреждением дорожных служб: "Ямочность 5 километров".

На карте вшитая скорость - 90.

Я сообщал про этот участок - подправили корректурой, с выходом новой карты всё стало как было.

 

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

 

А Spectre говорит про сбор подробной статистики...

Автоматически, мол, собираться будет.

В чём лично я - сильно сомневаюсь.

[TOnOP]

угу' date=' так оно и есть. в центре еще можно поманеврировать (на Васильевском или петроградке), но вот там как раз полагаться на непроверенные скорости - себе дороже: если актуальных скоростей нет - то 90% - пробка. Поэтому алгоритм Шпрота вызывает у питерцев такой энтузиазм - ибо сейчас ровно по этому же алгоримту и ездишь: смотришь, если кругом все "красное", а СГ ведет по непроверенной улице - то включаешь голову и туда не едешь: понимаешь, что не может такого быть. Ну и выбираешь улицу пусть красноватую, но зато проверенную [/quote']

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

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

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

[Spectre]

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

Не те объемы, чтобы железо не успевало справляться...

Проблемы с выпаданием ребер - проблемы позиционирования, карт и программной обработки на стороне клиента, но никак не проблема обработки пробочной информации.

 

shooo

Согласен!

 

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

 

Тем не менее, если бы это было так, то вшитые значения имели бы вид "33", "47", а не "50" и "60".

 

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

 

Да и сейчас такие места есть - дорога на Ивангород со смешным предупреждением дорожных служб: "Ямочность 5 километров".

На карте вшитая скорость - 90.

Я сообщал про этот участок - подправили корректурой, с выходом новой карты всё стало как было.

 

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

 

А Spectre говорит про сбор подробной статистики...

Автоматически, мол, собираться будет.

В чём лично я - сильно сомневаюсь.

То что статистика собирается (об этом mail.ru и СГ на встрече говорили), совсем не значит что она используется для формирования скоростных индексов в картах.

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

[shooo]

Не те объемы' date=' чтобы железо не успевало справляться...[/quote']

Для задач в реальном времени особых объемов не надо, чтобы возникли проблемы, если нет сервера очередей. Столько выпадать инфы стало после того, как подключилась не маленькая группа товарищей с пробки.мэйл - раньше такого не было, я смотрел. Или второй вариант, глюки версии 3.2. На мой взгляд она нестабильнее работает с точки зрения определения координат ЖПС и привязки к дорогам.

[Spectre]

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

 

Не такие уж и нереальные мощности для этого нужны.

[shooo]

В любом случае' date=' у некоторых других сервисов пробкодатчиков по России в целом побольше будет, чем у СГ,

 

Не такие уж и нереальные мощности для этого нужны.

[/quote']

А это у кого побольше?

Мощности и впрямь не нужны, нужна правльная архитектура

[demalina]

выход из этой ситуации один - не надо пытаться ехать по идеальному маршруту. И не надо требовать от программы составления того самого идеального маршрута

[qrot]

Статистика зло! Пример: Допустим у вас образовалась пробка на магистрали в 17.00 и в нее влетел датчик чем ее отметил. Прога в течении 30мин в эту пробку никого не поведет, а потом хрюшка исчезает, а пробка то реально есть, но туда никто не едет поскольку статистика в голове. Для проги статистика будет только первые 30мин, а дальше неизвестность и как ей работать только так как работает она сейчас (по зашитым скоростным индексам). От чего ушли к тому и пришли.

Надо искать другие решения.

[iys__]

Мне кажется, что копья ломать тут бесполезно. Как я понял суть дискуссии (пусть меня поправят, если не так), обсуждается способ как бы сделать так, чтобы СитиГид не прокладывал маршрут по улицам, по которым нет достоверной информации. НО ЭТО ЖЕ НЕВОЗМОЖНО! СитиГид устроен так, что ОН ОБЯЗАТЕЛЬНО поведет пользователя туда, где ему ничего не известно. Чтобы и по этим улицам была информация, хоть для текущей пробочной картины, хоть для статистики. Конечно, скорее всего, если на прямой дороге (магистрали) пробка, то и на объездном пути тоже пробка, и СитиГид вас туда ВСЕНЕПРЕМЕННО заведёт. Ничего с этим не поделать.

[shooo]

Мне кажется' date=' что копья ломать тут бесполезно. Как я понял суть дискуссии (пусть меня поправят, если не так), обсуждается способ как бы сделать так, чтобы СитиГид не прокладывал маршрут по улицам, по которым нет достоверной информации.

[/quote']

Чтоб он оценивал доверие к вшитым индексам скорости в зависимости от общего состояния с пробками в городе

[Spectre]

Статистика зло! Пример: Допустим у вас образовалась пробка на магистрали в 17.00 и в нее влетел датчик чем ее отметил. Прога в течении 30мин в эту пробку никого не поведет, а потом хрюшка исчезает, а пробка то реально есть, но туда никто не едет поскольку статистика в голове. Для проги статистика будет только первые 30мин, а дальше неизвестность и как ей работать только так как работает она сейчас (по зашитым скоростным индексам). От чего ушли к тому и пришли.

Надо искать другие решения.

Вы не уловили суть.

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

 

Мне кажется' date=' что копья ломать тут бесполезно. Как я понял суть дискуссии (пусть меня поправят, если не так), обсуждается способ как бы сделать так, чтобы СитиГид не прокладывал маршрут по улицам, по которым нет достоверной информации. НО ЭТО ЖЕ НЕВОЗМОЖНО! СитиГид устроен так, что ОН ОБЯЗАТЕЛЬНО поведет пользователя туда, где ему ничего не известно. Чтобы и по этим улицам была информация, хоть для текущей пробочной картины, хоть для статистики. Конечно, скорее всего, если на прямой дороге (магистрали) пробка, то и на объездном пути тоже пробка, и СитиГид вас туда ВСЕНЕПРЕМЕННО заведёт. Ничего с этим не поделать. [/quote']

Это не так. Есть возможность заметно уменьшить вероятность ввода пользователя в неразведанную пробку. И если этой возможностью не воспользуется СитиГид, ей воспользуется кто-то другой. Только и всего. Вернее, уже пользуется, но пока нормальные продукты этой фичи не имеют.

 

Прочитайте название темы. Здесь обсуждается другое.

 

PS. Еще раз: программа не умеет доверять или недоверять. Она умеет только складывать и вычитать числа.

[Spectre]

выход из этой ситуации один - не надо пытаться ехать по идеальному маршруту. И не надо требовать от программы составления того самого идеального маршрута

А зачем тогда эта программа нужна?

[Шпрот]

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

По-идее, это должно быть зашито в карту.

Узкая улочка - вшитая скорость 40.

Широкая - 50.

Магистраль - 60.

 

Ну, или что-то вроде.

 

Тогда коэффициент, хоть и затронет все дороги, но сохранит приоритет при выборе маршрута по неуточнённым дорогам.

 

Эту проблему - доверия-недоверия можно прописать в алгоритме.

И тогда программа, считая, будет либо доверять, либо не доверять.

 

[shooo]

[

Прочитайте название темы. Здесь обсуждается другое.

 

PS. Еще раз: программа не умеет доверять или недоверять. Она умеет только складывать и вычитать числа.

тут уже давно слилось в едино обсуждение алгоритмов тилрона и шпрота...

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

PS: кстати, наблюдал тут за хрюшками на КПК -у них срок жизни явно не 30 минут, скорее 15 минут.

[YoGun]

 <...> кстати' date=' наблюдал тут за хрюшками на КПК -у них срок жизни явно не 30 минут, скорее 15 минут.[/quote']

 

Это значит разработчики взялись за актуальность "хрюшек". Честно говоря, я бы предпочёл бы возможность настройки времени "протухания хрюшек". При нынешнем кол-ве "датчиков" иногда и 30 минут было мало...