HPC.ru lite - Все форумы
Форум: PocketGPS Pro и MacCentre PocketGPS
Тема: По поводу пробок
Страницы: [1] 2

[Ответить]
Пикс [30.10.2005 20:03] По поводу пробок:
Дело в том, что программа не умеет расставлять пробки на участке графа. В ситуации, когда граф очень длинный (расстояние от Ярославки от Щелковоского шоссе порядка 10 км.), и затруднение присутствует на небольшой его части, то желтым или красным закрашиватеся граф целиком, и программа ни за что не проложит маршрут через этот участок. Можно ли что либо сделать со стороны разработчиков в этой ситуации.
VctOs [30.10.2005 20:58] :
Предполагается, что если Вы выехали по МКАД от Ярославки на Щелковскую, Вы обязательно проедете по затору, а значит какой бы ни была длинной дуга графа и какой бы незначительной была бы длина пробки на ней, математически точный выбор маршрута может быть осуществлен при условии назначении корректного уровня затора, учитывающего _реальное_ увеличение времени проезда по всей дуге без разбиения дуги на поддуги.
Например, если на 1 км дуги скорость составляет 5 км/час, на остальном участке - 100 км/час средняя скорость проезда по дуге должна быть назначена 34 км/час.
Это правило не работает только если на длинной дуге находится точка старта или финиша.
>Можно ли что либо сделать со стороны разработчиков в этой ситуации.
Можно использовать "промежуточные" градации заторов.
Пикс [31.10.2005 09:24] :
На подобных участках нужны именно заторы, которые будут по длине короче этого участка. В реальной ситуации затор может быть 1 км., а программа то наивно считает, что все 10 км.
VctOs [31.10.2005 10:03] :
Для этого нужно переделывать карту (дробить сегменты на мелкие), в результате чего "поплывет" система нумерации сегментов графа, на которой "висит" идентификация заторов, а также появится дополнительная потребность в ресурсах (пусть и незначительная, но она появится).
Поэтому я предлагаю тот вариант который предложил (учитывать длину затора коррекцией интенсивности затора). Для него никаких перестроек программы и карты осуществлять не надо.
adanilov [11.11.2005 12:53] :
А то что пробки только в пределах МКАД, это Смилинк так передает или программа не может принять? Всем известно про частые пробки на Ярославке в р-не Королева. На Ленинградке в Химках. На Минке при везде в город (особенно в воскресенье летом). Да в общем на всех магистралях. Было бы не плохо знать о дорожной ситуации на подъездах к городу, чтобы вовремя выбирать пути объезда.
VctOs [11.11.2005 13:11] :
Ядро может пометить как затор или запрет проезда любую дугу графа вне зависимости от ее положения.
Пикс [11.11.2005 13:16] :
Смилинк собирает информацию в пределах МКАДа и на ближайших к нему подъездах-выездах.

to VctOs: Доколе пробки на выездах будут отображаться "против шерсти"?
VctOs [11.11.2005 13:42] :
В планах развития ядра на этот год добавление соответствующего контура "дуракозащиты" (foolproof), предназначенного для игнорирования сведений о заторах в запрещенном направлении движения не предусмотрено. По той теории реализации устойчивых к сбоям систем, которой меня учили, при обнаружении первого явно противоречивого предложения в потоке исходных данных разбор потока должен быть прекращен, состояние программы должно быть возвращено к состоянию до начала разбора потока. Говоря более простым языком - заторы перестанут грузиться вовсе. Разве это лучше? Молчаливое игнорирование ядром некорректно направленных заторов спрячет проблему и затруднит ее обнаружение. Разве это лучше? Немолчаливые технологии внутри ядра в принципе реализованы быть могут, но с отступлением от идеологического принципа "все общение с пользователем осуществляется через надстройку".
Чайни [13.11.2005 02:51] :
Честно говоря, не очень понял, в чём противоречие в нынешней системе. Вроде с пробками никаких проблем у программы нет... или я не так понял вопрос ?
VctOs [13.11.2005 12:06] :
Проблема состоит в том, что существует практически реализуемый способ заставить LaserMap Advanced Kernel считывать и отображать заторы в запрещенном для проезда направлении. Академически правильные системы должны выявлять подобные явные противоречивости входных данных текущей версии карты и по факту выявления предпринимать соответствующие действия.
[Ответить]
[Вперед >]