Перейти к содержанию

Обсуждение Навител.Пробок


Plukh

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

предыстория - тут: http://forum.navitel...pic.php?t=17320

 

У меня такое смутное воспоминание, что длина дорожной сети в Москве - около 3000 км. Т.е., при 80 тыс. пользователей в день имеем в среднем ~ 1 пользователя на километр в час. Т.е., можно считать, что по участку в 1 км за час проезжает не более одного пользователя НН. Понятно, что в часы пик пользователей больше, понятно, что есть более и менее популярные направления - но мне лично оценка кажется весьма похожей на правду.

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

Имеется в виду именно активных пользователей сервиса Навител.Пробки, именно в день, и именно такое количество. В общем, имеется в виду то, что напечатано :)

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

Plukh:

У меня такое смутное воспоминание, что длина дорожной сети в Москве - около 3000 км. Т.е., при 80 тыс. пользователей в день имеем в среднем ~ 1 пользователя на километр в час. Т.е., можно считать, что по участку в 1 км за час проезжает не более одного пользователя НН. Понятно, что в часы пик пользователей больше, понятно, что есть более и менее популярные направления - но мне лично оценка кажется весьма похожей на правду.

Это вы слишком неправильно оценили. Реально, при хороших алгоритмах оценки скорости даже 100-200 пользователей в каждый момент покрывают Москву очень хорошо. Понятно что не все дороги получаются охвачены, но пробкокартина получается очень приличная для хорошей трассировки маршрута. Если же еще применять статданные, то отличная маршрутизация будет и при 100 пользователях в онлайн.
Я имею возмоожность сравнивать 5 программ с пробками и маршрутами, строящимися на основе этих данных, и у Навитела они неплохи. Но все-таки пока явно еще много над чем надо поработать. Реальная статистика показывает, что максимальное количество пользователей, присутствующих одновременно в онлайн в утренние час-пик, примерно соответствует в 8-10 раз большему количеству пользователей за сутки.
Ссылка на комментарий
Поделиться на другие сайты

nn4gps:

Имеется в виду именно активных пользователей сервиса Навител.Пробки, именно в день, и именно такое количество. В общем, имеется в виду то, что напечатано :)

Хм... То есть действительно в час-пик количество одновременно едущих по Москве и области пользователей достигает примерно десяти тысяч? :shock: :shock: :shock:
Ссылка на комментарий
Поделиться на другие сайты

staskuz:

nn4gps:

Имеется в виду именно активных пользователей сервиса Навител.Пробки, именно в день, и именно такое количество. В общем, имеется в виду то, что напечатано :)

Хм... То есть действительно в час-пик количество одновременно едущих по Москве и области пользователей достигает примерно десяти тысяч? :shock: :shock: :shock:

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

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

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

staskuz:

Это вы слишком неправильно оценили. Реально, при хороших алгоритмах оценки скорости даже 100-200 пользователей в каждый момент покрывают Москву очень хорошо.


Хмда. Даже отвечать не хочется, но попробую :-(. Ещё раз. При протяжённости дорожной сети в 3000 км и 100 пользователях в онлайне - на одного пользователя приходится 30 километров дороги. Если Вы считаете, что за приемлемое время это пользователь сумеет "нарисовать" наличие/отсутствие пробок на этих 30 км - дальнейший разговор действительно бессмысленнен.
Ссылка на комментарий
Поделиться на другие сайты

nn4gps:

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

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

Plukh:

staskuz:

Это вы слишком неправильно оценили. Реально, при хороших алгоритмах оценки скорости даже 100-200 пользователей в каждый момент покрывают Москву очень хорошо.


Хмда. Даже отвечать не хочется, но попробую :-( . Ещё раз. При протяжённости дорожной сети в 3000 км и 100 пользователях в онлайне - на одного пользователя приходится 30 километров дороги. Если Вы считаете, что за приемлемое время это пользователь сумеет "нарисовать" наличие/отсутствие пробок на этих 30 км - дальнейший разговор действительно бессмысленнен.

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

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

staskuz:

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


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

staskuz:

Простите, но вы в своем "расчете" не учитываете массы факторов...


Естественно, не учитываю. Беда только в том, что, как написал akmes, их учёт не улучшит, а ухудшит ситуацию с покрытием дорожной сети информацией о пробках. Грубо говоря - если по какой-то улице проедет два датчика - то больше информации у нас не станет, зато по какой-то другой при этом не проедет ни один.

Цитата

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


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

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

Plukh:

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

Я знаю, про какую программу идёт речь. Именно статистику она и использует.
Ссылка на комментарий
Поделиться на другие сайты

Happy Prince:

Plukh:

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

Я знаю, про какую программу идёт речь. Именно статистику она и использует.


ЧиТД.
Ссылка на комментарий
Поделиться на другие сайты

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

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

Happy Prince:

Plukh:

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

Я знаю, про какую программу идёт речь. Именно статистику она и использует.

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

Plukh:

Happy Prince:

Plukh:

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

Я знаю, про какую программу идёт речь. Именно статистику она и использует.


ЧиТД.

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

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

Так данные с пробками обновляются каждые 2 минуты. Никаких проблем с маршрутами длиной более 30 минут нет. Данные по статистики априоре хуже онлайн данных, и я считаю, что вводить их в Навител бессмысленнно. Почему - обсуждалось уже, есть несколько тем. Кратко: будущее непредсказуемо, и объезд свободной дороги из-за какой-то статистики вчера - большее зло, чем наоборот. Про предсказания времени проезда тоже обсуждалось совсем недавно.

 

Если эта программа настолько хороша, что 100% безошибочно строит идеальные маршруты, может, назовёте её? В тестировании от указанных журналов она участвовала?

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

akmes:

Так данные с пробками обновляются каждые 2 минуты. Никаких проблем с маршрутами длиной более 30 минут нет. Данные по статистики априоре хуже онлайн данных, и я считаю, что вводить их в Навител бессмысленнно. Почему - обсуждалось уже, есть несколько тем. Кратко: будущее непредсказуемо, и объезд свободной дороги из-за какой-то статистики вчера - большее зло, чем наоборот. Про предсказания времени проезда тоже обсуждалось совсем недавно.

Если эта программа настолько хороша, что 100% безошибочно строит идеальные маршруты, может, назовёте её? В тестировании от указанных журналов она участвовала?

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

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

 

Да и кто из нас знает - а может это уже претворяется в жизнь или присутствует в ближайших планах? :)

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

Набил длинный ответ, но Интернет его съел :-(. Так что во второй раз уже отвечу коротко. Тем более что мне особо нечего добавить к сказанному akmes'ом. Никакое "предсказание", на каких бы алгоритмах оно не основывлось, не поможет мне построить адекватный маршрут. Если надо выбирать один из двух маршрутов в начальной точке движения (классический вариант - "через город" или "через МКАД"), то мне не поможет знание того, что через час в каком-то наперёд заданном месте будет пробка - которой запросто может и не быть. В этом смысле вполне достаточная статистика - что утром стоят магистрали в центр, вечером - из центра, а МКАД - стоит и утром, и вечером.

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

Plukh:

Набил длинный ответ, но Интернет его съел :-( . Так что во второй раз уже отвечу коротко. Тем более что мне особо нечего добавить к сказанному akmes'ом. Никакое "предсказание", на каких бы алгоритмах оно не основывлось, не поможет мне построить адекватный маршрут. Если надо выбирать один из двух маршрутов в начальной точке движения (классический вариант - "через город" или "через МКАД"), то мне не поможет знание того, что через час в каком-то наперёд заданном месте будет пробка - которой запросто может и не быть. В этом смысле вполне достаточная статистика - что утром стоят магистрали в центр, вечером - из центра, а МКАД - стоит и утром, и вечером.

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

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

Ведь навигаторы как датчики скорости - кошмар для проектировщика системы управления.

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

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

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

А желание изобретать велосипед вместо использования давно отработанной математики похвально, но временно ;-)

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

Погрешность-то в датчиках откуда (я не про фильтры - нужны, спору нет)?

Да и работают они не когда хотят.

 

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

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

akmes:

Погрешность-то в датчиках откуда (я не про фильтры - нужны, спору нет)?
Да и работают они не когда хотят.

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

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

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

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

akmes:

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

Согласитесь, что проще судить о том, что будет по ТВ через час, взглянув на программу ТВ, нежели по тому, какая программа идет сейчас ;) . Хотя действительно есть вероятность, что программу ТВ поменяли в силу каких-то событий, и вы через час увидите не ту передачу, что вы "предсказали", глядя в программу ТВ. ;)
Ссылка на комментарий
Поделиться на другие сайты

Экий, однако, холивар разыгрался :)

Для Москвы с ее 17 датчиками на километр дорожной сети использование статистики средней скорости на ребрах (и ее достоверности), разумеется, не столь актуально, как для моего Екатеринбурга с его 1,25 датчика на километр - теория измерений подсказывает нам, что точность определения средней скорости на ребре в Москве будет раза в 4 выше. О плотности датчиков в деревне Гадюкино смолчу :)

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

Да и при любом количестве датчиков дооценивание вектора состояния будет точнее оценивания.

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

Ископаемое:

Экий, однако, холивар разыгрался :)
Для Москвы с ее 17 датчиками на километр дорожной сети использование статистики средней скорости на ребрах (и ее достоверности), разумеется, не столь актуально, как для моего Екатеринбурга с его 1,25 датчика на километр - теория измерений подсказывает нам, что точность определения средней скорости на ребре в Москве будет раза в 4 выше. О плотности датчиков в деревне Гадюкино смолчу :)
Я, кстати, не скрываю свой шкурный интерес - оффлайновые пробки для автонавиков, к примеру, за последнюю неделю ;-) Такая услуга возможна только на основании статистических данных.
Да и при любом количестве датчиков дооценивание вектора состояния будет точнее оценивания.

Мы сейчас обсуждаем два применения статистики.

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

staskuz:

Согласитесь, что проще судить о том, что будет по ТВ через час, взглянув на программу ТВ, нежели по тому, какая программа идет сейчас ;) .


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

akmes:

staskuz:

Согласитесь, что проще судить о том, что будет по ТВ через час, взглянув на программу ТВ, нежели по тому, какая программа идет сейчас ;) .


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

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

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

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

akmes:

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

Более близкие к реальности данные -- это то, что будет на дороге, когда вы до нее доедете, а не то, что есть на ней сейчас. Согласны?
Ссылка на комментарий
Поделиться на другие сайты

Статистика - слишком непостоянный и ненадежный аргумент касаемо пробок. На примере задачи.

 

Пусть на участке Можайское шоссе (от МКАД) - Кутузовский проспект (в Москве) утром каждый день пробка в центр, вечером - из центра. Все логично.

 

Пусть в такое-то число месяца Кутузовский вечером перекрыли для правительства, и вся Можайка встала в цетр.

 

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

 

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

 

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

 

Поэтому все не столь просто, сколь кажется изначально :) И Сервис Навител.Пробки не за одну ночь придуман и описан разработчиками )))

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

Кстати, прямое сравнение Навитела и сервиса, о котором упоминает staskuz, есть: http://mnovosti.ru/d...s/art/4020.html

В Москве Навител привычно победил - количество датчиков сделало свое дело :)

Но это ведь не говорит о том, что алгоритмы Навитела идеальны? ;-)

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

staskuz:

...Второе применение -- это прокладка маршрута с учетом развития ситуации по мере движения к пункту назначения...

Отличная задача, но, кмк, слишком сложная (для вычислительных ресурсов навигатора) и неопределенная получится модель :-(
Ссылка на комментарий
Поделиться на другие сайты

nn4gps:

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


+100 Абсолютно согласен - обязательно должна быть комбинация методов. Тем более, в центре обработки - на серверной стороне.
Ссылка на комментарий
Поделиться на другие сайты

Ископаемое:

Кстати, прямое сравнение Навитела и сервиса, о котором упоминает staskuz, есть: http://mnovosti.ru/d...s/art/4020.html
В Москве Навител привычно победил - количество датчиков сделало свое дело :)
Но это ведь не говорит о том, что алгоритмы Навитела идеальны? ;-)

Не корректное тестирование было. Там Навител сравнивали с Be-On-Road, на которую в тот момент из Пробковорота поступали данные не полностью и отображались из-за разных карт с основной программой пробковорота совсем по разному. В собственной программе пробковорота данных отображается в разы больше.
Ссылка на комментарий
Поделиться на другие сайты

Ископаемое:

staskuz:

...Второе применение -- это прокладка маршрута с учетом развития ситуации по мере движения к пункту назначения...

Отличная задача, но, кмк, слишком сложная (для вычислительных ресурсов навигатора) и неопределенная получится модель :-(

Ресурсы кпк используются при этом ровно на столько же как и в данный момент. Просто данные о пробках должны быть прогнозные на маршруте, а это сделать должен сервер. Вот сервера может не хватить, что б сделать каждому при запросе индивидуальную пробкосводку с учетом его местанахождения.
Приведу еще один пример: почему то все смотрят прогноз погоды с утра и стараются одеть одежду в соответствии с прогнозом, а не в соответствии с температурой на данный момент. Да, ругают метеорологов, если этот прогноз не совпадает, но на следующий день делают тоже самое.
Приведенные примеры nn4gps - это локальные возмущения в общем. Просто при сборе статистики нужно все эти факторы учитывать - и футбол вечером, и перекрытие с утра, дождь после обеда, и ночной гололед. И в соответствующие события подставлять эти модели к общей статистике. Да, это сложная работа, но ведь метеорологи предсказывают погоду :wink:
Ссылка на комментарий
Поделиться на другие сайты

nn4gps:

Статистика - слишком непостоянный и ненадежный аргумент касаемо пробок. На примере задачи.

Пусть на участке Можайское шоссе (от МКАД) - Кутузовский проспект (в Москве) утром каждый день пробка в центр, вечером - из центра. Все логично.

Пусть в такое-то число месяца Кутузовский вечером перекрыли для правительства, и вся Можайка встала в цетр.

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

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

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

Поэтому все не столь просто, сколь кажется изначально :) И Сервис Навител.Пробки не за одну ночь придуман и описан разработчиками )))

Разве я где-нибудь утверждал, что хорошее количество онлайн-датчиков не нужно? :shock: Это нужно, и это важно! Но... не достаточно! Именно это я и утверждаю: только комбинация онлайн-данных и статистики может дать лучший результат! Впрочем, вы и сами к этому уже пришли.
Ссылка на комментарий
Поделиться на другие сайты

garry654321:

Ископаемое:

Кстати, прямое сравнение Навитела и сервиса, о котором упоминает staskuz, есть: http://mnovosti.ru/d...s/art/4020.html
В Москве Навител привычно победил - количество датчиков сделало свое дело :)
Но это ведь не говорит о том, что алгоритмы Навитела идеальны? ;-)

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

Да, действительно, это сравнивали с программой Be-on-Road, а у нее, во-первых, с маршрутизацией большие проблемы, во-вторых, на момент тестирования, в нее давались не полные данные (по административным причинам). Полные данные видны на 77 точка ру.
Ссылка на комментарий
Поделиться на другие сайты

nn4gps:

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

Тут вступают в дело реальные он-лайн данные, которые должны иметь приоритет над статистикой.

Цитата

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

Так ведь никто не предлагает надеяться только на статистику. Это должен быть вспомогательный инструмент. Но ведь и отказываться от статистики, целиком полагаясь на датчики, не очень конструктивно.
Ссылка на комментарий
Поделиться на другие сайты

Happy Prince:

Тут вступают в дело реальные он-лайн данные, которые должны иметь приоритет над статистикой.


Зарекался поддерживать этот флуд, но не выдержал. Если маршрут строится по поргнозным данным - то "реальные он-лайн данные" никогда не будут использоваться. Вообще. Неужели это непонятно, блин? Потому что практически всегда точка принятия решения будет находиться достаточно далеко, чтобы для принятия решения о маршруте использовались не реальные, а предсказанные статистикой данные.

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

Если, как предлагает staskuz, анализировать именно динамику развития пробочной ситуации и делать выводы на основе этого анализа - тогда да, я вижу шанс для реального улучшения качества прогноза. Но вот беда - я не думаю, что чисто алгоритмически/вычислительно это будет возможно в ближайшие годы. Так что пока (пока!) не надо, пожалуйста, никаких "статистических" пробок, ни в будущем, ни в настоящем.
Ссылка на комментарий
Поделиться на другие сайты

Plukh:

Happy Prince:

Тут вступают в дело реальные он-лайн данные, которые должны иметь приоритет над статистикой.


Зарекался поддерживать этот флуд, но не выдержал. Если маршрут строится по поргнозным данным - то "реальные он-лайн данные" никогда не будут использоваться. Вообще. Неужели это непонятно, блин? Потому что практически всегда точка принятия решения будет находиться достаточно далеко, чтобы для принятия решения о маршруте использовались не реальные, а предсказанные статистикой данные.

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

Если, как предлагает staskuz, анализировать именно динамику развития пробочной ситуации и делать выводы на основе этого анализа - тогда да, я вижу шанс для реального улучшения качества прогноза. Но вот беда - я не думаю, что чисто алгоритмически/вычислительно это будет возможно в ближайшие годы. Так что пока (пока!) не надо, пожалуйста, никаких "статистических" пробок, ни в будущем, ни в настоящем.

Онлайн-данные очень и очень важны! И на ближайшие 15-30 минут маршрута, несомненно, использовать нужно только их.
Ссылка на комментарий
Поделиться на другие сайты

staskuz:

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


staskuz, ты хочешь предложить Навителу свои услуги математика-"модельера"? Или продать свою методику моделирования? Так так прямо и скажи...

Или что? :)
Ссылка на комментарий
Поделиться на другие сайты

У меня в инструкции к ВВК 3501 написано, что он поддерживает информацию о пробках, но GPRS нет, как мне можно получать на навигатор информацию о пробках?

Блютуса нет.

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

SHOKY_1:

У меня в инструкции к ВВК 3501 написано, что он поддерживает информацию о пробках, но GPRS нет, как мне можно получать на навигатор информацию о пробках?

У него блютуз есть? Он интернет через блютуз умеет?
Тогда очень просто: подружив его с сотовым телефоном по блютузу! Телефон будет служить ГПРС-модемом.
Ссылка на комментарий
Поделиться на другие сайты

staskuz:

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


Что-то вообще не понимаю, откуда такие зависимости. Если где-то в 2 раза меньше, то не факт что далее так же.
Ссылка на комментарий
Поделиться на другие сайты

akmes:

Что-то вообще не понимаю, откуда такие зависимости. Если где-то в 2 раза меньше, то не факт что далее так же.

Конечно не факт.
Ссылка на комментарий
Поделиться на другие сайты

Развели флуд про статистику везде, где можно, кроме нужной темы http://forum.navitel...pic.php?t=12380 :? Может быть, модераторы перенесут всю конструктивную часть раскиданных по форуму обсуждений в правильное место?

 

Предсказывание пробочной ситуации по статистическим данным в изложении сторонников этой методики у меня ассоциировалось с идеей прдсказания погоды на основании статистических данных за прошлые годы: последние 10 лет 17 октября температура по Москве была +5-+7, небольшой дождь (условно). Поэтому прогноз на 17 октября в этом году -- +5-+7, небольшой дождь. И такой прогноз будет передаваться до тех пор, пока мы не убедимся, что на самом деле будет +15 и солнце. Как только убедимся, начнем накапливать новую статистику.

 

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

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

Заархивировано

Эта тема находится в архиве и закрыта для дальнейших ответов.

×
×
  • Создать...