АНАЛИЗ ПЕРВОГО НЕЗАВИСИМОГО ТЕСТИРОВАНИЯ ОНЛАЙН СЕРВИСОВ «ПРОБКИ» В МОСКВЕ.

28.10.2010

АНАЛИЗ ПЕРВОГО НЕЗАВИСИМОГО ТЕСТИРОВАНИЯ ОНЛАЙН СЕРВИСОВ «ПРОБКИ» В МОСКВЕ.

23 декабря 2009 года интернет-сообщество «GPS-клуб» (https://gps-club.ru) совместно с компанией «M2M Телематика» и Ассоциацией «ГЛОНАСС/ГНСС Форум» организовали первое в России независимое тестирование всех on-line сервисов «пробки», используемых в персональных автомобильных навигаторах PND и коммуникаторах для Московского региона.

Основной целью ставилась задача проверки существующих сейчас систем навигации в отношении их эффективности для проезда по Москве с учетом дорожной обстановки. Тестирование проводилось с прямой трансляцией перемещений участников через интернет-систему мониторинга, поэтому любой желающий мог наблюдать за процессом тестирования через сайт M2M Телематики (www.m2m-t.ru). Помимо этого, по-окончании тестирования на том же сайте были доступны логи перемещений каждого участника, что позволило провести более детальный анализ результатов уже после тестирования. Был выбран следующий способ тестирования. Из одной точки в черте города, в одно время стартуют одновременно все машины с командами, состоящими водителей, представителей компаний тестируемых навигационных программ и наблюдателей от других компаний, журналистов и представителей форумов.

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

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

В качестве стартовой точки было выбрано место недалеко от 14-го километра МКАДа рядом с торговым центром «МЕГА Белая Дача» (N55°39'22", E37°50'45"). Это же место являлось и точкой финиша. В качестве 2 промежуточной точки назначения была выбрана Шереметьевская улица в районе дома 32 (т.к. на большинстве карт такого пока нет, в качестве альтернативы использовался дом 9 корпус 2).

В тестировании приняли участие следующие программы:

• Сити Гид (City Guide) (сервис Probki.net)
• Автоспутник (сервис Яндекс.Пробки)
• Навител (сервис Навител.Пробки)
• Навиком (эксклюзивный дистрибьютор Garmin в России)
• PocketGis (сервис "Пробковорот")
• TomTom (без on-line сервиса «пробки»)
• ПроГород (без on-line сервиса «пробки»)

Наиболее известными участниками рынка навигационных систем с учетом пробок в Москве являются Автоспутник, Ситигид и Навител. Менее известна система PocketGIS, т.к. она не поступает в коммерческую продажу, однако на ней запущен свой пробкосервис по времени ранее других участников рынка навигационных систем в Москве.

Автоспутник. Система, давно существующая на Московском рынке. Сейчас получает данные с широко известного сервиса Яндекс.Пробки, а также является одним из поставщиков информации о передвижении пользователей программы для сервиса Яндекс.Пробки СитиГид. Система, изначально развивавшаяся в Питере, теперь работает и в Москве. Имеет свой пробкосервис, основанный на обработке информации о перемещении ее же пользователей. Информация от системы также показывается на сайтах probki.net и mail.ru

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

Навиком. Использует навигаторы Garmin. Данные о пробках поставляются с сервера probki.net, являющего сервисом СигиГида, далее информация о пробках через RDS-TMC транслируется в навигационные устройства Garmin.

PocketGIS. Использует специально разработанный сервис Пробковорот. Сервис получает информацию о перемещении, прежде всего, пользователей программы PocketGIS, используя ее как для построения «онлайн»-картины дорожной обстановки, так и для накопления статистических данных. Для построения картины дорожной обстановки одновременно используются и свежие «онлайн»-данные от пользователей в пути, и данные от статистического анализа истории перемещений пользователей в аналогичное время аналогичных дней. В дополнение к этому используются данные от диспетчера. В тестировании принимали участие две команды от PocketGIS в связи с тем, что система Пробковорот поддерживает две карты от разных поставщиков: от Геоцентр-Консалтинг и от проекта бесплатных карт Open Street Map (openstreetmap.org). Команда с именем «PocketGIS» использовала карту от Open Street Map со стратегией «Компромисс» (стратегия, по возможности избегающая длинных маршрутов), команда с именем «PocketGIS-2» использовала карту от Геоцентр-Консалтинг со стратегией «Быстрее» (стратегия, наиболее склонная к экономии времени). Различные стратегии использовались для снижения вероятности получения одинаковых маршрутов для обеих команд.

TomTom. Известнейшая в мире навигационная система. В Москве пробки не поддерживаются. Фирменная система IQ Routes в Москве пока не действует. Поэтому маршруты, предлагаемые программой в Москве, учитывают лишь скорости дорог, прописанные в картах Tele Atlas.

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

РЕЗУЛЬТАТЫ ЗАЕЗДА

Старт тестирования произошел примерно в 14 часов 40 минут. Результаты заезда для всех команд приведены в таблице:

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

ПЕРВЫЕ МЕСТА: POCKETGIS-2, POCKETGIS, TOMTOM, ПРОГОРОД.

Точка старта/финиша находилась в районе юго-восточной части МКАД, промежуточная точка – в  районе северной части ТТК. Как и ожидалось, маршруты команд «TomTom» и «Прогород» двигались наиболее очевидными маршрутами, т.к. эти программы не использовали пробкосервис. Начало маршрута обе программы направили по МКАД в северном направлении, затем по радиальным проспектам к ТТК: TomTom повел по Волгоградскому проспекту, а Прогород – по почти параллельному Рязанскому проспекту.

Далее, на ТТК маршруты опять совпали, пройдя по ТТК в северном направлении к съезду на Шереметьевскую улицу, где расположена промежуточная точка. После ее проезда обе программы направили свои маршруты до разворота на Шереметьевской улице, после чего повели обратно к точке старта теми же путями, аналогичными своим маршрутам от старта к промежуточной точке. При этом выбор маршрута через Волгоградский проспект, сделанный TomTom, оказался более правильным, нежели выбор ПроГорода, т.к. общее время движения к промежуточной точке и возврата назад для TomTom составило, соответственно, 1:32 и 1:20, а Прогород – 1:43 и 1:53. Таким образом, разница составила 12 минут в первой части маршрута и 33 минуты во второй части маршрута (итого 44 минуты).  

В сравнении с «безпробковыми» системами интересным выглядит результат команды «PocketGIS», ехавшей по карте OSM со стратегией «Компромисс». Система избрала маршрут похожий на маршруты TomTom и Прогород, однако при движении к промежуточной точке, он пролегал через Рязанский проспект, совпав с маршрутом Прогорода, а при возвращении – через Волгоградский проспект, совпав с обратным маршрутом TomTom. При этом команда «PocketGIS» проехала первую часть за 1:29, вторую часть – за 1:16.

Примечательно, что команда PocketGIS преодолела первую половину маршрута быстрее Прогорода на 14 минут, несмотря на то, что маршруты практически совпадали. Возможно, сыграло роль то, что команда PocketGIS, стартовав на 7 минут позже других (по техническим причинам – из-за опоздания наблюдателя), догнала команду Прогорода благодаря более удачному моменту проезда светофоров, а также выбирая более правильные ряды для движения на загруженных участках. Также не исключается и возможная положительная динамика изменения ситуации на каком-либо загруженном участке маршрута или даже нескольких участках.

Однако наиболее впечатляющий результат показала команда «PocketGIS-2», преодолев и первую, и вторую половины пути за существенно меньшее время, нежели все остальные участники тестирования. Первая половина пути была преодолена за 1:09, вторая – за 1:16. Примечательно, что длина общая длина маршрута была максимальной относительно маршрутов других участников. Данная команда использовала «самую быструю» стратегию маршрута (ее название «Быстрее»), поэтому маршрут оптимизировался программой именно с позиции минимизации времени ценой любого увеличения длины маршрута. С точки зрения целей тестирования это более «правильная» стратегия маршрута, нежели стратегия «Компромисс», выбранная первой группок «PocketGIS», использующей карту OSM. Ключевым преимуществом основной части маршрута к промежуточной точке явился выбор маршрута через МКАД и Ярославское шоссе. Несмотря на большую протяженность такого участка, команда проехала его быстро и без проблем, что и обеспечило главный выигрыш во времени по сравнению с другими участниками теста.

Таким образом, система нашла действительно эффективный по времени маршрут. Помимо этого, маршрут увел команду с Ярославского шоссе к ВВЦ, выведя ее на Шереметьевскую улицу через 1-ю Останкинскую и Новомосковскую улицы. По отзывам наблюдателей, такой маршрут совсем неочевиден для обычного водителя: как путь через Ярославку, так и остальной маршрут до промежуточной точки, т.к. более логичными кажутся варианты пути через Звездный бульвар или улицу Академика Королева. Это наглядно показало как антипробковые системы могут предлагать неожиданно интересные и эффективные маршруты в реальных дорожных условиях.

Обратный путь команды «PocketGIS-2» был не менее интересен. Рассмотрим его подробно. Начало пути назад было классическим: команда, проехав промежуточную точку, доехала по Шереметьевской улице до ТТК, повернув далее на внутреннюю сторону ТТК. Таким же образом поступили и многие другие программы, проведя «свои» команды по ТТК до Рязанского или Волгоградского проспектов. Маршрут команды «PocketGIS-2» также вел на Рязанский проспект (как и обратные маршруты команд «Навиком» и «Прогород»), однако выезд на Рязанский проспект был очень нестандартным. Маршрут «съехал» с ТТК не над Нижегородской улицей (которая затем «перетекает» в Рязанский проспект), а над шоссе Энтузиастов, тем самым приведя команду на Старообрядческую улицу, идущую практически параллельно ТТК. Она перетекает в улицу Рогожский Поселок, которая, в свою очередь, имеет боковой выезд прямо на Нижегородскую улицу, но… в сторону центра города! Собственно, объезд был «спровоцирован» пробкой на съезд на Нижегородскую улицу в сторону Рязанского проспекта и пробкой на самой ТТК. Однако, попав на Нижегородскую улицу, необходимо найти где и как развернуться, чтобы очутиться на правильном направлении. При этом нужно наиболее быстро преодолеть пробку, связанную со слиянием 4-х потоков: потоком по Рязанскому проспекту из центра, двумя съездами с ТТК (один – с внутренней, другой – с внешней стороны) и одним выездом из прилегающего микрорайона. Программа выбрала оригинальный способ сложного «разворота» целым рядом маневров, многие из которых неочевидны. В месте развязки ТТК с Нижегородской улицей, программа предложила ехать не по Нижегородской улице до первого разворота на ней, а заехать на «петлю» на дорогу, выводящую на внешнюю сторону ТТК, затем предложив съехать с этой дороги в микрорайон (до ее соединения с ТТК). Проделав еще одну «петлю» по нескольким небольшим улицам того микрорайона, команда оказалась на специальном выезде из микрорайона на Нижегородскую улицу. Этот выезд загружен меньше альтернативных выездов той развязки, т.к. он недоступен основным потокам автомобилей, выезжающих с ТТК.  

Итак, оказавшись на Нижегородской улице в нужном направлении, и преодолев наиболее проблемную пробку на участке от выезда на Нижегородскую улицу до проезда всех съездов с ТТК, обнаружилось, что маршрут предложил еще один серьезный объезд пробки, протянувшейся до конца Нижегородской улицы. Это объезд через Новохохловскую улицу и часть Газгольдерной улицы за торговым комплексом Ашан. Далее, маршрут вернулся на Рязанский проспект, вплоть пересечения с улицей Академика Скрябина, после чего по этой улице маршрут вывел на Болгоградский проспект. Программа выбрала этот путь, посчитав проезд до МКАД по Академика Скрябина, затем по участку Волгоградского проспекта более быстрым по времени, нежели «классический» маршрут по 7 Рязанскому проспекту до МКАД и далее по МКАД. Это сэкономило время на проезд образовавшейся пробки на МКАД, «избавив» команду от проезда участка пробки на МКАД между Рязанским и Волгоградским проспектами. Далее, маршрут прошел стандартно до точки назначения.

Несмотря на победу, следует отметить, что выбранный день тестирования для команд PocketGIS был далеко не самым удачным, т.к. опасения вызывали следующие факторы:

• Карта Геоцентр-Консалтинг (в дальнейшем, для краткости, «ГЦ») являлась старой – на тот момент ей «исполнилось» 2 года. Связано это с тем, что сотрудничество между ГЦ и автором систем PocketGIS и Пробковорот было прекращено примерно в то время. Однако даже такая старая карта во многом не теряет актуальность благодаря возможности через сервер Пробковорота устанавливать запреты на запрещенные после издания карты маневры и проезды.  
• Карта OSM стала поддерживаться Пробковоротом и программой PocketGIS лишь за месяц до проведения соревнования. В момент запуска Пробковорота на картах OSM для Москвы те содержали массу недочетов и ошибок, однако запуск PocketGIS и Пробковорота с картами OSM привлек массу тестеров, которые стали оперативно исправлять ошибки и недочеты карты. Таким образом, к моменту соревнования состояние карты несколько улучшилось, но лишь частично – настолько, насколько тестеры смогли заметить и исправить ошибки за месяц с момента запуска поддержки карт OSM. Поэтому были сомнения, насколько адекватна будет маршрутизация по такой, еще «сырой», карте.  
• В связи с частыми изменениями в OSM из-за ее постоянного редактирования пользователями, некоторые дороги карты могли не обслуживаться сервером Пробковорота по причине того что они могли поменять свой идентификатор относительно идентификаторов дорог карты, использующейся сервером Пробковорота.  
• Пробковорот активно использует статистические данные, накопленные от участников за прошлые периоды, дополняя ими свежие онлайн-данные. 23 декабря – это предновогодняя пора. Соответственно, статистика для этого периода может достаточно сильно отличаться от статистики других дней зимы. В связи с небольшим числом онлайн-участников, ехавших по городу во время проведения соревнования (в течение времени заезда PocketGIS это количество было на уровне лишь 20-30 человек), были определенные сомнения, что данные статистики будут адекватными реальной обстановке, что потенциально может привести к выбору неоптимального маршрута.

Кроме того, не обошлось и без казусов, связанных со «старостью» карты от ГЦ. Наиболее заметной была проблема выезда на МКАД в самом начале соревнования: карта ГЦ «не знала» о съезде на внешнюю сторону МКАД с дороги, идущей от ТЦ «МЕГА Белая Дача», что заставило команду «PocketGIS-2» сделать три петли на развязке, прежде чем попасть на нужное направление МКАД. Это связано со «старостью» карты, т.к. ее релиз пришелся на момент, когда прямой съезд на МКАД там еще не был открыт.  

Однако, несмотря на все перечисленные выше неблагоприятные факторы, практика показала, что во время тестирования Пробковорот с картой ГЦ повел себя более чем адекватно, показав результат не только не хуже, а существенно лучше результатов всех других команд, уверенно выведя команду «PocketGIS-2» на первое место. А Пробковорот с экспериментальной на то время картой OSM и не «самой быстрой» стратегией «Компромисс» показал также хорошие результаты, оказавшись на 2-м месте.

ОСТАЛЬНЫЕ МЕСТА: НАВИТЕЛ, СИТИГИД, GARMIN, АВТОСПУТНИК

Теперь поговорим о результатах участников тестирования, от которых большинство ожидало наиболее адекватных результатов. Это компании Навител, Ситигид, Автоспутник и Навиком (Garmin).К разочарованию многих, ни один из этих программных комплексов не показал хороших результатов. Более того, команды «Навител», «СитиГид», «Автоспутник» «Навиком» добрались до промежуточной точки и вернулись назад не только заметно дольше победителей тестирования, но и отстали от программ, работающих без пробкосервиса! Если команды PocketGIS проехали весь маршрут за 2:25 («PocketGIS-2» с картой ГЦ) и 2:45 («PocketGIS» с картой OSM), а TomTom (без пробкосервиса) – за 2:52, то Навител и СитиГид добрались до финиша существенно позже: Навител за 3:41, а СитиГид – за 3:47, это более чем в полтора раза дольше победителя тестирования. Результаты же команд Навикома (Garmin) и Автоспутника еще более «внушительны»: команда Навиком к финишу приехала за 5:37, а Автоспутник – за 6:21, что на 3-4 часа дольше победителей! Следует вспомнить, что Автоспутник использует сервис Яндекс.Пробки, а Навиком – пробкосервис СитиГида (probki.net).

К сожалению, в соревновании не принимала участия команда Be-on-road, предварительно заявлявшая о своей готовности принимать участие, но не явившаяся по причине отсутствия на момент соревнования стабильной версии программы. Примерно за год до соревнования разработчики Be-on-road активно сотрудничали с автором Пробковорота, и использовали пробкосервис именно от Пробковорота, однако по некоторым причинам это сотрудничество было прекращено, и теперь Be-on-road использует сервис Яндекс.Пробки. Было бы очень интересно посмотреть на результаты Be-on-road, т.к. это было бы испытанием не только программы, но и еще одним испытанием сервиса Яндекс.Пробки (помимо Автоспутника). Рассмотрим маршруты каждой из этих команд, попытавшись выявить основные причины получившихся результатов.

Первой серьезной задержкой СитиГида, Навикома и Автоспутника на пути к промежуточной точке был выезд на Волгоградский проспект через Люблинскую улицу. Этот выезд – одно из самых проблемных мест в Москве. Именно перед этим выездом перечисленные выше команды потратили десятки минут на преодоление пробки. При этом, если Ситигид и Навиком, использующие одного и того же «провайдера пробок», проехали от старта до этого выезда одним и тем же маршрутом через Братеево, то Автоспутник поехал через Капотню, притом не напрямую через улицу Верхние Поля, а обогнув часть улицы Верхние Поля по периметру Капотни.  

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

1) недостаточным покрытием информацией критически важных дорог из-за относительно небольшого количества пользователей-датчиков. 

2) недооценкой степени серьезности пробки вследствие слишком грубой ее оценки.

3) принципиальной особенностью чисто онлайновых антипробковых систем, периодически порождающих так называемые «белые пятна» в местах серьезных пробок.

«ВРЕМЯ ЖИЗНИ» И «БЕЛЫЕ ПЯТНА»

Остановимся на 3-м пункте, рассмотрев эту проблему подробно. «Чисто онлайновыми» здесь называются системы, использующие только свежие («онлайн») данные от пользователей, и не применяющие статистические данные. Таким системам необходимо периодически обновлять данные о пробках, ограничивая «время жизни» полученных онлайн-данных некоторым пороговым временем. Ограничение «времени жизни» данных связано с проблемой трудности делать какие-либо выводы о ситуации на дороге, если по ней долгое время не проезжал никто из «датчиков». Если оставить «время жизни» бесконечным или очень большим, то информация о серьезной пробке может продержаться много больше времени, нежели пробка есть в реальности, потому что маршруты пользователей будут всячески избегать дороги, на которой пробка была зафиксирована. Поэтому, если за «время жизни» онлайн-данных никто их не обновил, проехав по той же дороге в течение этого времени, то старая информация снимается, и дорога приобретает статус дороги с «неизвестной дорожной обстановкой», что трактуется большинством навигационных систем как дорога со стандартной средней скоростью, заложенной в карте. В зависимости от используемой карты это может быть скоростью «свободной дороги», либо усредненной скоростью дороги, также заложенной в карте (она может быть рассчитана поставщиками карт по накопленной статистике GPS-треков).

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

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

Таким образом, в чисто онлайновых системах, для дорог, где серьезные пробки не рассасываются в течение длительного времени, периодически образуются «белые пятна» в информации о пробке. Длительность каждого такого «белого пятна» может составлять от нескольких минут до нескольких десятков минут. Фактически, это время состоит из нескольких слагаемых: интервал времени с момента устаревания онлайн-данных до попадания в эту пробку нового пользователя, плюс некоторое время пребывания пользователя в пробке, необходимое для определения ее степени, а также для отправки накопленной информации на сервер. Величина времени таких «белых пятен» уменьшается с увеличением числа пользователей, однако для серьезных пробок, имеющих альтернативные объезды, даже большое число пользователей не позволяет полностью избавиться от таких «белых пятен». Справедливости ради, следует отметить, что информацию о пробке могут обновлять пользователи, для которых маршрут через эту пробку является безальтернативным, либо ее объезд для них еще дольше. Появление такого пользователя отодвигает момент возникновения «белого пятна», а если такие пользователи появляются периодически, то «белые 10 пятна» могут не появиться до тех пор, пока такие пользователи обновляют информацию своими проездами через пробку. Однако такое случается далеко не всегда, и далеко не для каждой пробки: зачастую существуют альтернативные варианты объезда, благодаря которым практически все пользователи могут избегать этой пробки.  

Проблема образования «белых пятен» является одной из причин «метания» маршрута пользователей, что заметно снижает эффективность системы. Это происходит так. Когда где-либо образуется «белое пятно», маршруты некоторых пользователей могут резко измениться, предложив проехать через это «белое пятно» как через свободную дорогу (если, с точки зрения расчета, такой вариант получается быстрее, нежели исходный вариант маршрута). Однако, когда «белое пятно» закрывается новыми данными от пользователей, попавших на ту дорогу ранее других, маршруты тех, кто туда еще не доехал, снова резко меняются: появляется какой-либо еще альтернативный вариант маршрута, либо даже предлагается вернуться на старый маршрут, который был проложен до появления «белого пятна». Впрочем, иногда бывает уже поздно, и маршрут может не измениться, проходя через ту самую дорогу, где недавно образовывалось «белое пятно»; это происходит, если вернуться на альтернативные варианты невозможно из-за отсутствия вариантов возврата, либо это еще хуже по времени, нежели проезд через пробку.

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

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

Рассмотрим один из наиболее интересных и наглядных случаев подобного влияния «белых пятен» на маршрут, приводящего к существенному удлинению маршрута пользователя, как по времени, так и по расстоянию. Выглядит это так. Некоторое время, пока данные о серьезной пробке присутствуют на сервере, маршрут пользователя, который при отсутствии пробки проходил бы через эту дорогу, строится через альтернативные проезды. Пользователь некоторое время едет по правильному маршруту, избегая упомянутой пробки. Затем, пока пользователь все еще едет по объездному маршруту, наступает момент «устаревания» данных о пробке. Сервер убирает информацию об этой пробке, и в новой порции данных от сервера, пользовательская программа получает информацию о том, что на упомянутой дороге пробка якобы исчезла. В результате, программа пользователя, пересчитав маршрут, может вычислить, что теперь быстрее будет проехать через эту дорогу, где пробка «исчезла». В таком случае маршрут пользователя резко изменяется, даже если он уже уехал достаточно далеко от той пробки по объездному маршруту, и возвращение к якобы свободному проезду будет, своего рода, «крюком». Однако, если программа, взвесив варианты маршрута, посчитала, что «так будет быстрее», она невозмутимо предложит сделать этот «крюк». Таким образом, если пользователь послушается нового маршрута, он приедет к той самой пробке, по которой информация устарела, став поневоле ее очередным «разведчиком». Потери времени от такого изменения маршрута могут быть очень существенными. Во-первых, пользователь мог уже некоторое время потратить на попытку объезда упомянутой пробки, когда информация о ней еще выдавалась сервером. Во-вторых, некоторое дополнительное время тратится на возврат к той дороге, где данные образовалось «белое пятно» (заметьте, если бы данные о пробке устарели ранее, то маршрут к этой дороге мог бы быть более прямым). И, наконец, в-третьих, пользователь системы тратит время на проезд той серьезной пробки, которую он объезжал в начале, и куда он вернулся из-за устаревания данных о ней.

Описанный выше «сценарий» может приводить даже к появлению разворота на маршруте и возврату по тем дорогам, которые пользователь недавно проехал в противоположную сторону. Обычно такое поведение программы раздражает пользователей, тем более что далеко не всегда такие «возвраты» объективно оправданы изменением дорожной обстановки – они действительно бывают вызваны упомянутым эффектом «белых пятен». В особо «выдающихся» случаях, маршрут может даже зацикливаться на некоторое время, последовательно предлагая пользователю несколько раз проехать по одним и тем же местам. Подобную проблему наглядно продемонстрировал маршрут команды «Автоспутник» во время обсуждаемого тестирования. Однако об этом позже, а сейчас, рассмотрим проблему влияния «белых пятен» в более наглядном виде на графическом примере.  

ГРАФИЧЕСКИЙ ПРИМЕР ВЛИЯНИЯ «БЕЛЫХ ПЯТЕН» НА МАРШРУТ  

Точками с цифрами обозначены некоторые ключевые перекрестки, встречающиеся по нашему маршруту. Цветной «подсветкой» изображены пробки: красным – очень серьезная пробка, оранжевым цветом – менее серьезная. Мы едем из точки 1 в точку 7. Будем считать, что если бы на пути между точками 5 и 6 не было пробки, то наиболее быстро было бы проехать по маршруту 1-5-6-7. Однако, до нас кто-то проехал по участку 5-6, разведав, что там серьезная пробка. Сервер передал это в наш навигатор, и он построил нам маршрут 1-2-3-8-7, обогнув участок 5-6.  

Мы проехали участок 1-2, и едем по участку 2-3. Допустим, что пока мы едем по участку 2-3 информация о пробке на участке 5-6 устарела, и сервер убрал информацию о пробке на том участке. Итак, наш навигатор получил очередную порцию данных, в которой пробка на участке 5-6 отсутствует, а на участке 3-8 все еще присутствует (на участке 3-8 пробка не «глухая», и информация о ней поддерживается периодически проезжающими там пользователями). Мы все еще едем по участку 2-3, и наш навигатор вычисляет, что к пункту назначения теперь быстрее проехать по маршруту 3-4-5-6-7, объехав пробку на участке 3-8, полагая, что участок 5-6 теперь свободен. Мы направляемся по новому варианту маршрута по пути 3-4-5, заезжаем на участок 5-6 и… становимся новым «разведчиком» той самой серьезной пробки, которая никуда не делась!

Проанализируем потери времени, которые принесло не вовремя возникшее «белое пятно». Итак, мы проехали маршрут 1-2-3-4-5-6-7, потратив гораздо больше времени, нежели это было необходимо, потратив время на объезд пробки 5-6 по участку 1-2-3, на возврат к ней по 3-4-5 и на ее проезд по 5-6. Если бы «белое пятно» не появилось до того как мы доехали до точки 3, то мы бы поехали по участку 3-8, т.е. самым правильным маршрутом, который изначально и предлагался программой: 1-2-3-8-7. Это заняло бы минимальное время в данном случае.  

Другой вариант развития событий. Если бы «белое пятно» образовалось еще до нашего выезда из точки 1, то мы поехали бы по участку 1-5. Затем, если за это время «белое пятно» участка 5-6 не «закрыл» кто-то еще (проехав там до нас), мы стали бы тем «разведчиком», кто закроет белое пятно, однако при этом мы потратили бы меньше времени, чем в описанной в предыдущих абзацах ситуации: потому что путь 1-5 короче и быстрее пути 1-2-3-4-5. Аналогично,  если бы «пятно» образовалось, пока мы ехали по участку 1-2, то мы поехали бы маршрутом 1-2-4-5-6-7, т.е. «сэкономили» бы на пути 2-3-4, «срезав» по 2-4.  

Теперь еще более интересный вариант развития событий. Как и в основном примере, будем считать, что «белое пятно» появилось, пока мы ехали по участку 2-3. Остаток нашего маршрута изменился на 3-4-5-6-7. Однако пока мы возвращались к участку 5-6 по маршруту 3-4-5, кто-то другой попал в «белое пятно» раньше нас, обновив информацию о состоянии участка 5-6. В результате, сервер опять выставил там серьезную пробку, скажем, в то время пока мы ехали по участку 4-5. Теперь наш навигатор, снова оценив потери времени на пробку 5-6, делает вывод, что быстрее будет вернуться, поехав по маршруту 5-4-2-3-8-7, развернувшись в точке 5. В результате, наша поездка превратилась в маршрут 1-2-3-4-5-4-2-3-8-7. Как видно, из-за временного появления «белого пятна», мы сделали своеобразную «петлю», зря проехав существенную часть маршрута (3-4-5-4-2-3). Несмотря на то, что проезд даже такого странного маршрута потенциально может занять меньше времени маршрута 1-2-3-4-5-6-7 (из-за очень серьезной пробки на участке 5-6), в такой «экономии» утешения мало, ведь мы два раза проехали участок 2-3, да еще и совершили большую «петлю» с разворотом: 3-4-5-4-2.  

Если развивать мысль дальше, усложняя пример, описанные возвраты назад могут завести нас и в другие неразведанные пробки или даже в другие «белые пятна». К примеру, представьте, что на участке 4-2 оказалась неизвестная ранее серьезная пробка, где мы проведем много времени (скажем, полчаса - час). В результате, за время вашего возвращения к точке 3 на участке 5-6 может вновь образоваться «белое пятно», и маршрут может снова поменяться, «позвав» нас «на разведку» участка 5-6! Конечно, мы туда уже вряд ли поедем, но это наглядно демонстрирует, как может нас «водить» антипробковая система при определенном стечении обстоятельств.  

Вернемся к анализу результатов обсуждаемого тестирования. 

До графического примера упоминалось, что команда Автоспутника столкнулась с проблемой временного «зацикливания» маршрута. Это было так. После выезда из упомянутой ранее пробки на Люблинской улице, при движении по Волгоградскому проспекту в сторону ТТК, маршрут Автоспутника вдруг предложил развернуться на развязке проспекта с ТТК и поехать по Волгоградскому проспекту назад в сторону Люблинской улицы! Несмотря на то, что на преодоление участка от Люблинской улицы до ТТК потребовалось также много времени, команде пришлось «подчиниться», следуя правилам тестирования, и ехать строго по маршруту.  

Далее, пока команда возвращалась по Волгоградскому проспекту в сторону Люблинской улицы, маршрут изменился снова, предписав опять развернуться на Волгоградском проспекте напротив Шоссейной улицы. Таким образом, команда еще раз проехала по участку Волгоградского роспекта в сторону ТТК! На этот раз маршрут «вышел из цикла», предложив проехать ТТК мимо и двигаться дальше по Волгоградскому проспекту. Во время таких «маневров» многие наблюдатели решили, что Автоспутник отказался от участия, т.к. слишком сильно отстал от других (Автоспутник выехал с Люблинской улицы на Волгоградский проспект существенно позже других команд, попавших в эту же пробку, сильно задержавшись перед самым выездом с Люблинской улицы на проспект).

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

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

В первой половине маршрута команда Навитела удалилась дальше всех других команд на юг, достигнув почти самой южной точки МКАД, что было довольно необычно, т.к. промежуточная точка находится с северной стороны ТТК. Программа выбрала въезд в Москву через Восточное Бирюлево (Липецкую улицу), пройдя по МКАД мимо въездов в Москву через Капотню и Братеево (что неминуемо привело бы к пробке на Люблинской улице) и мимо Каширского шоссе. Проехав Восточное Бирюлево, затем Царицыно, команда выехала на Каширское шоссе уже недалеко от парка Коломенское. Доехав до Варшавского шоссе, команда через некоторое время «ушла» на набережную Москвы реки незадолго до ТТК. Проехав по набережной до Новоспасского моста, команда выехала через Таганскую площадь на Садовое кольцо. Съехав с Садового кольца на улицу Щепкина, команда вскоре достигла промежуточной точки.

Как уже рассказывалось ранее, команда СитиГида заехала в Москву через Братеево, проехав по Люблинской улице до Волгоградского проспекта. После этого маршрут пошел на ТТК, однако в районе Бауманской программа предложила съехать с ТТК в сторону Садового кольца. После выезда на Садовое кольцо с Орликова переулка, маршрут Ситигида совпал с маршрутом Навитела до самой контрольной точки.

Обратные маршруты СигиГида и Навитела начались также одинаково, однако если Навител предложил стандартный маршрут через ТТК и Волгоградский проспект до МКАД, то у СитиГида обратный маршрут получился гораздо более сложным. Между двумя последовательными тоннелями на ТТК в районе Лефортово, СитиГид предложил съехать на Красноказарменную улицу. Проехав до шоссе Энтузиастов, программа предложила вернуться на ТТК с шоссе, однако, по рассказу водителя команды, перед самым поворотом  на ТТК маршрут изменился, и команда поехала по шоссе Энтузиастов дальше (в сторону центра) до Рогожского Вала. Проехав по Рогожскому Валу перпендикулярно Нижегородской улице (направление Рязанского проспекта) и, далее, мимо пересечения с Волгоградским проспектом, команда повернула с площади Крестьянской Заставы в сторону Южного Порта, проехав через 1-ю Дубровскую, а затем Шарикоподшипниковскую улицы. По рассказу водителя команды Навитела, он и созванивались с командой СитиГида, как только команда Навитела выехала с ТТК на Волгоградский проспект: в это время команда СитиГида еще не доехала до Волгоградского проспекта (то есть до места, расположенного дальше на пару километров от пересечения проспекта с ТТК). Следовательно, в то время казалось, что преимущество явно на стороне команды Навитела, так как чтобы по Волгоградскому проспекту доехать от Крестьянской Заставы до ТТК, пришлось бы потратить немало времени, потому что этот участок обычно плотно забит пробкой в это время. Однако СитиГид быстро провел команду через весь район Южного Порта, выведя ее в район Печатников. Оттуда команда выехала в середину Люблинской улицы, несколько задержавшись лишь в пробке перед туннелем под железной дорогой, разделяющей микрорайоны Печатников и Люблино. С Люблинской улицы команда вскоре повернула внутрь района Марьино почти прямо в сторону финиша, а затем по улице Верхние Поля пересекла МКАД, достигнув финиша лишь на 7 минут позже команды Навитела. Если же учесть чистое время от промежуточной точки до финиша, то времена пути обеих команд на практически совпали: Навител – 1:47, СитиГид – 1:46.  

Как видим, маршруты Навитела и СитиГида сильно отличались, однако разница во времени между командами получилась несущественной в обеих половинах маршрутов. Навител показал «тягу» к более прямолинейным маршрутам, СитиГид «петлял» гораздо больше, но при этом обе программы пришли к финишу примерно в одно время. Однако, к сожалению, эти команды не выполнили свою главную задачу: привести пользователя к цели ранее, чем это сделали программы «без пробок». Разница оказалась существенной: почти часовое опоздание от TomTom (без пробок), и в полтора раза больше времени на маршрут, нежели победитель теста.

Теперь рассмотрим маршрут Навиком (Garmin), вспомнив, что он получал данные через TMC с Ситигидовского пробкосервиса probki.net. Логично было бы предположить, что маршрут команды «Навиком» должен быть похож на маршрут команды «СитиГид». Первая половина маршрута к промежуточной точке у них действительно совпала, и проехали они его примерно за одно и то же время, однако в районе ТТК маршруты разделились: СитиГид предпочел ехать по ТТК, а Навиком поехал дальше по Волгоградскому проспекту в сторону центра. Доехав до Таганской площади, Garmin команды «Навиком» предложил ехать дальше в центр в сторону Китай-города по Верхней Радищевской улице.

Но почему то программа решила объехать короткий прямой проезд через Таганскую площадь, сделав петлю на сторону выезда с площади на внешнее Садовое кольцо: повернув направо, программа предложила развернуться под Садовым кольцом и вернуться на площадь, чтобы продолжить движение дальше. К сожалению, не удалось найти описание соревнования от команды Навикома, чтобы понять из-за чего возникла такая «петля»: из-за ошибки в карте или из-за того, что короткий участок на Таганской площади считался настолько загруженным, что программа решила сделать петлю вместо того, чтобы напрямую проехать короткий участок площади. Или из-за того, что вначале маршрут вел на Садовое кольцо, но в последний момент перестроился в сторону движения в центр. Проведя массу времени в пробках внутри Садового кольца, и проехав после Китай-города через Большую Лубянку и участок Бульварного кольца на Цветной бульвар, команда доехала до Олимпийского проспекта, где на «финишной прямой» ее маршрут снова воссоединился с маршрутом СитиГида. Правда, произошло это примерно на 40 минут позже времени проезда команды СитиГид, так что проезд через центр оказался неудачной идеей.

В связи с тем, что разрыв времени у команд Навикома и СитиГида к моменту проезда контрольной точки стал слишком велик, дальнейшее сравнение их маршрутов теряет практический смысл, так как за 40 минут обстановка в городе могла существенно измениться. Тем более что уже начиналось время вечернего часа-пик: команда СитиГида проехала контрольную точку в 16:44, а Навиком – уже в 17:25.

Обратный маршрут Навиком заслуживает отдельного внимания, так как в нем также проявилась проблема несовершенства пробкосервисов, приводящая к нежелательным «петлям» маршрута. Начало обратного маршрута Навиком было непохожим на других, но было не лишено логики: команда не стала разворачиваться на Шереметьевской улице, чтобы вернуться по ней же к ТТК, а поехала дальше, чтобы выехать на проспект Мира через улицу Бочкова. Для выезда на ТТК с проспекта Мира программа избрала вполне логичный проезд по Водопроводному переулку, которым пользуются многие водители. Существует альтернативная возможность выезда на ТТК через улицу Гиляров-ского и Трифоновскую улицу с кратким заездом на проспект Мира в направлении из центра, но Трифоновская обычно плотно забита автомобилями, поэтому это обычно худшая альтернатива. Далее, программа повела команду по ТТК вплоть до пересечения с шоссе Энтузиастов, после чего сделала «трюк» очень похожий на маршрут команды победителей «PocketGIS-2». Аналогично маршруту команды «PocketGIS-2», после проезда по Старообрядческой улице, программа вывела команду на Нижегородскую улицу в сторону центра, затем маршрут сделал маневр вплоть до съезда в микрорайон без выезда на ТТК. Казалось бы, далее маршрут должен был вывести их на Нижегородскую улицу в нужном направлении таким же образом, как и команду «PocketGIS-2», однако этого не произошло, и программа повела команду к Волгоградскому проспекту, выведя на него через улицу Талалихина.

Однако маршрут по Волгоградскому проспекту оказался коротким, т.к. программа… предложила вернуться к направлению на Рязанский проспект с выездом на Нижегородскую улицу через проезд по внешнему участку ТТК! Таким образом, командой была сделана «петля» в несколько километров, вместо того, чтобы преодолеть загруженный, но короткий участок под ТТК по Нижегородской улице, выехав на него аналогично команде «PocketGIS-2». При этом, судя по всему, команде пришлось заметное время постоять на Волгоградском проспекте, а также на съезде с ТТК на Нижегородскую улицу. На этом все «петли» закончились, и команда проделала путь по Рязанскому проспекту вплоть до МКАДа и затем к финишу. Итак, по сравнению с СитиГидом команда «Навиком» потратила на путь к контрольной точке на 41 минуту больше (2:42 против 2:01), а обратно – на 69 минут больше (2:55 против 1:46). Основными причинами существенных задержек команды Навиком относительно команды СитиГида видятся следующие: проезд через самый центр города в первой половине маршрута, а на обратном пути – большая «петля» между Рязанским и Волгоградским проспектами. Такая «петля», возможно возникла из-за «метания» маршрута. О вариантах причин, вызывающих «метание» маршрута рассказывалось выше. Все это привело к кардинальному увеличению времени в пути: команда проделала весь путь за 5:37, что примерно на 3 часа дольше команд победителей.  

В заключение, вернемся к исследованию маршрута команды «Автоспутник». Напомним, что команда провела в пути наибольшее количество времени: более 6 часов. Это почти на 4 часа или более чем в 2 с половиной раза дольше команды победителей! Что же случилось с этой командой? Кратко напомню об уже обсужденной выше части пути команды к контрольной точке: проезд вокруг Капотни (вместо прямого проезда по улице Верхние Поля), затем попадание в пробку на Люблинской улице, далее «зацикливание» маршрута на Волгоградском проспекте (езда в сторону центра, разворот на ТТК и езда обратно по проспекту в сторону Люблинской, затем снова разворот и повторный проезд по проспекту в сторону центра). Все это заняло очень много времени, однако на этом «приключения» команды не закончились. Доехав до Таганской площади и заехав на Садовое кольцо, программа предложила съехать на Николоямскую улицу, «присоединившись к идее» маршрута команды Навикома: проехать через Китай-город, затем Большую Лубянку.Далее со Сретенки маршрут кратко «заехал» на Садовое кольцо, чтобы сразу уйти на ул. Щепкина. Казалось бы, промежуточная точка уже близка, и нужно ехать по улице Дурова, а затем по ул. Советской Армии сразу попасть на Шереметьевскую. Именно так и делали Навител и Навиком. Однако Автоспутнику что-то помешало сделать это, возможно потому что эти улицы уже были забиты машинами, ведь подошло время часа-пик (было уже примерно 18 часов).

Так что программа предложила поехать по Олимпийскому проспекту, затем свернуть на улицы Трифоновскую и Верземника, выведя команду на внешнюю сторону ТТК через разворот под Рижской эстакадой. Попав на ТТК, маршрут «увел» команду на первый же съезд в восточную часть Марьиной Рощи, «поводив» ее ступеньками по всем трем параллельным улицам восточной части Мариной Рощи: от 4-й до 2-й. Оказавшись на Шереметьевской улице, пришлось еще проехать по ней до разворота под Шереметьевским мостом, и вернуться по Шереметьевской назад, т.к. контрольная точка находилась южнее выезда на Шереметьевскую. При этом программа при первой же возможности предложила уехать с Шереметьевской на этот раз в западную часть Марьиной Рощи на Октябрьскую улицу. В итоге, промежуточная точка была «взята» со стороны Октябрьской улицы. Итак, на первую «половину» маршрута ушло почти 4 часа (3:56)! Это более чем на час дольше предыдущего по длительности результата команды Навиком, доехавшей до контрольной точки за 2:42. И это почти на 3 часа дольше команды победителей, проехавших контрольную точку через 1:09 с момента старта.

Обратный путь Автоспутник начался в разгар вечернего часа-пик (в 18:39), поэтому время обратного пути 2:25 не столь удивляет, однако оно также является слишком большим – 2:25. Фактически, команда Автоспутника приехала к финишу уже на спаде часа-пик – в 21:04! Из примечательных «моментов» обратного маршрута можно выделить следующее. Команда объехала Рижскую эстакаду на ТТК большой петлей через Садовое кольцо, выведя команду на Олимпийский проспект, затем «ступеньками» на улицу Щепкина, Гиляровского и проспект Мира. Далее, съехав с Садового кольца через площадь Красных Ворот на Каланчевскую улицу, затем проехав за Казанским вокзалом, команда Автоспутника повернула на Ольховскую улицу, и вернулась на ТТК. Сомнительно, что от такого объезда команда выиграла, а не потеряла время по сравнению с прямым проездом по ТТК, потому что пробка после недлинного участка Рижской эстакады обычно исчезает или существенно уменьшается.

Последним интересным моментом маршрута команды Автоспутник являлась петля для выезда с ТТК на Волгоградский проспект через разворот на 2-ю улицу Машиностроения вблизи Шарикоподшипниковской улицы. Эта петля является альтернативой специально оборудованной малой петле для выезда на Волгоградский проспект, съезд на которую обычно забит автомобилями. Возможно «большую петлю» предложила программа, либо водитель собирался объехать очередь на «малую петлю», где его не пустили часто дежурящие около «малой петли» сотрудники ГИБДД, из-за чего пришлось проехать мимо. В любом случае по 2-й улице Машиностроения не всегда удается быстрее попасть на Волгоградский проспект, так как там тоже собирается много желающих таким образом попасть на проспект. После выезда на Волгоградский проспект, маршрут команды был стандартным: до МКАД, затем к точке финиша.  

Какие выводы можно сделать из результата Автоспутника? Налицо либо неправильная настройка «чувствительности» программы к пробкам (уже упоминалось, что предполагается, что чувствительность была выставлена слишком высокая, несмотря на обратное предположение представителя Автоспутника, позже прокомментировавшего такой результат), либо плохая согласованность работы с сервисом Яндекс.Пробки, либо слишком грубая оценка степени заторов по информации от Яндекса или сочетание этих факторов.  

Действительно, параметр «чувствительности к пробкам» появился из-за слишком грубой дискретизации данных от Яндекса: ранее предлагались лишь 4 возможных состояния: «движение свободно», «движение затруднено», «пробка» и «движение перекрыто». То есть на пробки оставалось лишь 2 состояния («движение затруднено», «пробка»). Однако реальная практика показывает, что этого слишком мало (далеко не только по результатам этого теста, а по опыту использования антипробковых систем в последние годы). К примеру, время проезда пробки, где средняя скорость равна 3 км/ч отличается от времени проезда пробки со средней скоростью 1 км/ч в 3 раза. Однако обе таких пробки будут отображаться одинаково, сели используется мало «градаций» пробок. Параметр «чувствительности к пробкам», фактически условно задает, как расценивать данные о «затрудненном движении» или «пробке» по сравнению с отсутствием данных. Если задать низкую чувствительность, то программа будет недооценивать серьезность пробок, если же высокую – переоценивать, что ничуть не лучше, а зачастую и хуже недооценки, потому что это приводит к повышению вероятности возникновения ненужных «петель» на неразведанные дороги или на «белые пятна», которые могут иметь свои пробки.  

Впрочем, Яндекс, как минимум с лета 2009 года начал передавать данные о средних скоростях дорог, по которым передается заторная информация. Однако не удалось найти данных о том, что сервер Автоспутника уже стал передавать эти средние скорости на свои программы для прокладки маршрута вместо морально устаревших 4-х «градаций». Помимо этого, привязка данных Яндекса к карте Автоспутника также может не всегда работать корректно, так как Яндекс и Автоспутник используют карты от разных поставщиков. Если эта проблема к моменту теста не была решена, то некоторые дороги могли быть не покрыты данными от Яндекса, а в некоторых местах данные могли «привязаться» даже к другим дорогам. В любом случае, результат тестирования показал, что паре Автоспутник-Яндекс.Пробки нужно всерьез задуматься о текущем качестве сервиса, выявив основные причины снижения качества работы. В этом смысле был бы очень интересным результат программы Be-on-road, которая на момент теста тоже использовала сервис Яндекс.Пробок. Возможно, это пролило бы свет на первопричину проблем: качество работы программы Автоспутник со своим сервером или качество работы сервиса Яндекс.Пробки.  

ПОЧЕМУ ПОБЕДИЛ ПРОБКОВОРОТ?  

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

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

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

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

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

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

Вернемся к Пробковороту. Еще одной особенностью Пробковорота является относительно большое число «градаций», характеризующих состояние дорог. Официально заявлено 8 градаций, не считая девятой, означающей перекрытие дороги. Такое количество градаций существенно точнее отражает ситуацию на дороге, нежели в системах, использующих лишь 2-3 градации. Кроме того, в Пробковороте может быть заложено и большее количество «градаций», которое не отображается как разные, но может передаваться сервером и учитываться алгоритмом прокладки маршрута. Достоверной информации о реальном количестве градаций скорости (передаваемом севером Пробковорота на устройства пользователей) нет, однако точно известно, что их не менее 8-ми, и что количество может быть расширено до 16-ти. В этом смысле Пробковорот точнее многих антипробковых систем. Однако следует заметить, что, например, сервер probki.net передает на пользовательские устройства с программой СитиГид значения средних скоростей, что потенциально может быть еще точнее. Впрочем, для навигаторов правильней передавать не столько значения средних скоростей, сколько обратную величину: время проезда единицы длины, например, в секундах на 100 метров. Это позволило бы увеличить критически важную точность на низких скоростях (до 5 км/ч) и одновременно снизить бессмысленную точность на больших скоростях (от 50 км/ч и выше). Напомню, что в статье приводился пример трехкратной разницы между временем проезда пробки на скоростях 1 и 3 км/ч.

СЕРВИСЫ «ПРОБОК» В МОСКВЕ. МИФЫ И РЕАЛЬНОСТЬ.  

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

Например, официальная новость Навител от 8 октября 2009 года, гласит о том, что (цитата): «По данным собственного сервера статистики, на сентябрь 2009 года бесплатным сервисом Навител.Пробки пользуются в среднем 80 000 человек в день – и это только в Москве»! Сравним это количество с реальным количеством участников Пробковорота в день тестирования 23 декабря 2009 года. По данным сервера статистики Пробковорота в тот день было зафиксировано лишь 184 человека (пользователя с разными ID), что более чем в 400 раз меньше среднего количества пользователей, заявленного Навител в октябре 2009 года.  

Возникает вопрос: почему же команда Навител при таком огромном числе пользователей затратила в полтора раза больше времени, нежели команда «PocketGIS-2», приехав к финишу даже позднее двух программ, не использующих сервис пробок?  

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

Однако, похожие выводы касаются и других коммерческих систем, таких как СитиГид, Навиком и Автоспутник. Навиком запустил сервис лишь незадолго до обсуждаемого тестирования, и такой результат 22 можно оправдать недостаточной отлаженностью системы. Однако системе СитиГид это вряд ли простительно, так как они уже несколько лет назад запустили пробкосервис в Питере, и у них уже прошло немало времени, достаточного для раскрутки и отладки своего сервиса с момента его официального запуска в Москве. То же касается и «пары» Автоспутник-Яндекс.Пробки, проблемы которой можно объяснить недостаточной согласованностью работы этих сервисов друг с другом. Пока рано делать выводы о качестве работы самого сервиса Яндекс.Пробок, т.к. в тестировании не принимала участие их «родная» программа Яндекс.Карты. Однако нельзя исключать, что этот сервис также нуждается в доработке.  

Относительно организации будущих тестирований пробкосервисов, хотелось бы пожелать им более четкой организации, предусматривающей точное время старта, исправность всех участвующих автомобилей, предоставления управления только адекватным водителям (не «гонщикам») и обязательности полного опубликования текстовых отчетов каждой команды и официальных результатов тестирования. Кроме того, для повышения объективности результатов, было бы правильней дожидаться приезда всех участников к промежуточной точке, стартовав от нее к финишу синхронно. Тогда была бы исключена составляющая, связанная с изменением дорожной обстановки на обратном пути для участников, прибывших в промежуточную точку в разное время.  

ПЕРСПЕКТИВЫ МЕТОДОВ ПРОГНОЗИРОВАНИЯ ДОРОЖНОЙ ОБСТАНОВКИ  

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

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

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

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

Если вы выезжаете в момент нарастания часа-пик, в момент вашего выезда навигационная программа может проложить маршрут через какое-то далекое от вас шоссе, которое в данный момент еще свободно. Однако к тому времени, когда вы доедете до этого шоссе, оно уже может забиться автомобилями до такой степени, что гораздо быстрее было бы проехать по совсем иному маршруту. В Москве это особенно часто случается с теми, чей маршрут прокладывается в объезд некоторых шоссе через МКАД. Чисто онлайновые системы с такими ситуациями ничего не могут сделать, независимо от количества их онлайн-пользователей – они предложат маршрут по тем дорогам, по которым быстрее проехать в данный момент времени без учета изменения обстановки в течение времени вашего пути. Ведь чтобы узнать что будет на том шоссе, когда вы там очутитесь, нужно уметь предсказывать обстановку с упреждением, «заглядывая в будущее», чего такие онлайн-системы делать не умеют. Впрочем, в течение езды по маршруту онлайн-система отслеживает изменения на дорогах, и по мере приближения к упомянутому в примере шоссе, постепенное увеличение его загруженности, в конце концов, может привести к построению системой альтернативного маршрута. Однако, если бы система «знала» заранее о динамике развития пробки и состоянии того шоссе на момент вашего проезда по нему, то ваш маршрут мог бы пройти по дорогам, которые вы уже давно минуте, прежде чем чисто онлайновая система «поймет» неоптимальность проезда по этому шоссе. Таким образом, наиболее эффективный маршрут может пролегать по дорогам, которые вы проскакиваете мимо, пользуясь чисто онлайновой системой без предсказания будущей обстановки. Возвращаться же к тем дорогам не будет иметь смысла, ведь вы их уже проехали, и время, необходимое на возврат уже не даст необходимого выигрыша, не говоря уже о психологической составляющей, когда вам не захочется возвращаться к тем местам, что вы проехали.  

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

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

Хорошая система прогноза должна учитывать не только тип дня и текущее время, подставляя нужные статданные из истории, но и сравнивать онлайн данные текущего дня и времени со статистическими, «подыскивая» наиболее похожую статистику развития ситуации. Это даст возможность учитывать разнообразные комбинации условий, которые могут создаваться на дороге в зависимости от трудно учитываемых факторов, таких как изменения погоды, проведение мероприятий и многое другое. Это непростая задача, однако, она может и должна быть решена для получения более «разумных» прогнозов. Такой «автовыбор» наиболее близких к текущей ситуации статданных можно считать следующим важным шагом в развитии систем прогноза дорожной обстановки.

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

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

Это даст возможность получать по выбору пользователя:  

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

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

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

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

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

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

ОТ «ЭГОИСТИЧЕСКИХ» К «КОЛЛЕКТИВНЫМ» СИСТЕМАМ ОПТИМИЗАЦИИ МАРШРУТОВ  

Все что описано выше относится к системам, так называемого, «эгоистического» построения маршрута. Смысл такого построения в том, что маршрут для каждого пользователя прокладывается лишь исходя из оптимизации его собственного маршрута. Широкое применение «эгоистических» систем, когда количество водителей, использующих эти системы, станет соизмеримым с общим количеством участников дорожного движения, породит новую проблему. Большое число участников дорожного движения, использующих навигационные системы с «эгоистическими» алгоритмами построения маршрута, будет «забивать» свободные дороги из-за похожих маршрутов, отдающих предпочтение одним и тем же «свободным» дорогам. В-особенности эта проблема касается чисто онлайновых систем, ориентирующихся лишь на текущую дорожную обстановку. Поэтому, следующим шагом развития антизаторных систем должно быть развитие методов предсказания потоков автотранспорта и распределения их по альтернативным маршрутам. В таком случае система будет не только отдавать информацию о пробках, но и рекомендовать маршрут. Это даст возможность лучше распределять потоки автомобилей по разным дорогам, добиваясь более равномерной загрузки дорог, что предотвратит «перекосы» когда слишком много машин отправляется на одну дорогу, вызывая ее перегрузку, несмотря на наличие альтернативных «недозагруженных» дорог, по которым также можно было бы проложить маршрут для части пользователей.  

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

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

Принять участие в обсуждении методики второго теста, который ориентировочно состоится 17 ноября 2010 года, можно на форуме GPS Клуба

Авторская орфография сохранена

Перепечатка без согласия автора категорически запрещена

Мнение GPSClub.ru может не совпадать с мнением Автора