По поводу пробок
По поводу пробок
Дело в том, что программа не умеет расставлять пробки на участке графа. В ситуации, когда граф очень длинный (расстояние от Ярославки от Щелковоского шоссе порядка 10 км.), и затруднение присутствует на небольшой его части, то желтым или красным закрашиватеся граф целиком, и программа ни за что не проложит маршрут через этот участок. Можно ли что либо сделать со стороны разработчиков в этой ситуации.
Glofiish X500+
Предполагается, что если Вы выехали по МКАД от Ярославки на Щелковскую, Вы обязательно проедете по затору, а значит какой бы ни была длинной дуга графа и какой бы незначительной была бы длина пробки на ней, математически точный выбор маршрута может быть осуществлен при условии назначении корректного уровня затора, учитывающего _реальное_ увеличение времени проезда по всей дуге без разбиения дуги на поддуги.
Например, если на 1 км дуги скорость составляет 5 км/час, на остальном участке - 100 км/час средняя скорость проезда по дуге должна быть назначена 34 км/час.
Это правило не работает только если на длинной дуге находится точка старта или финиша.
>Можно ли что либо сделать со стороны разработчиков в этой ситуации.
Можно использовать "промежуточные" градации заторов.
Например, если на 1 км дуги скорость составляет 5 км/час, на остальном участке - 100 км/час средняя скорость проезда по дуге должна быть назначена 34 км/час.
Это правило не работает только если на длинной дуге находится точка старта или финиша.
>Можно ли что либо сделать со стороны разработчиков в этой ситуации.
Можно использовать "промежуточные" градации заторов.
Для этого нужно переделывать карту (дробить сегменты на мелкие), в результате чего "поплывет" система нумерации сегментов графа, на которой "висит" идентификация заторов, а также появится дополнительная потребность в ресурсах (пусть и незначительная, но она появится).Пикс писал(а):На подобных участках нужны именно заторы, которые будут по длине короче этого участка. В реальной ситуации затор может быть 1 км., а программа то наивно считает, что все 10 км.
Поэтому я предлагаю тот вариант который предложил (учитывать длину затора коррекцией интенсивности затора). Для него никаких перестроек программы и карты осуществлять не надо.
А то что пробки только в пределах МКАД, это Смилинк так передает или программа не может принять? Всем известно про частые пробки на Ярославке в р-не Королева. На Ленинградке в Химках. На Минке при везде в город (особенно в воскресенье летом). Да в общем на всех магистралях. Было бы не плохо знать о дорожной ситуации на подъездах к городу, чтобы вовремя выбирать пути объезда.
Смилинк собирает информацию в пределах МКАДа и на ближайших к нему подъездах-выездах.adanilov писал(а):А то что пробки только в пределах МКАД, это Смилинк так передает или программа не может принять? Всем известно про частые пробки на Ярославке в р-не Королева. На Ленинградке в Химках. На Минке при везде в город (особенно в воскресенье летом). Да в общем на всех магистралях. Было бы не плохо знать о дорожной ситуации на подъездах к городу, чтобы вовремя выбирать пути объезда.
to VctOs: Доколе пробки на выездах будут отображаться "против шерсти"?
Glofiish X500+
В планах развития ядра на этот год добавление соответствующего контура "дуракозащиты" (foolproof), предназначенного для игнорирования сведений о заторах в запрещенном направлении движения не предусмотрено. По той теории реализации устойчивых к сбоям систем, которой меня учили, при обнаружении первого явно противоречивого предложения в потоке исходных данных разбор потока должен быть прекращен, состояние программы должно быть возвращено к состоянию до начала разбора потока. Говоря более простым языком - заторы перестанут грузиться вовсе. Разве это лучше? Молчаливое игнорирование ядром некорректно направленных заторов спрячет проблему и затруднит ее обнаружение. Разве это лучше? Немолчаливые технологии внутри ядра в принципе реализованы быть могут, но с отступлением от идеологического принципа "все общение с пользователем осуществляется через надстройку".Пикс писал(а):to VctOs: Доколе пробки на выездах будут отображаться "против шерсти"?
Проблема состоит в том, что существует практически реализуемый способ заставить LaserMap Advanced Kernel считывать и отображать заторы в запрещенном для проезда направлении. Академически правильные системы должны выявлять подобные явные противоречивости входных данных текущей версии карты и по факту выявления предпринимать соответствующие действия.
Не вижу противоречия, честно говоря. Ничего страшного, если на запрещённом участке есть ещё и пробка, и программа лишь скачивает и использует лишние в данном случае данные. Просто в этом случае "более сильное условие" (запрет) должно "поглощать" "более слабое условие" (пробка).
Противоречие было бы, если бы, например, пользователь вручную прокладывал маршрут (если предположить такую возможность) через запрет. И то выход из положения есть - указать ему на запрет в "таком-то месте" и запросить подтверждение проезда в этом месте.
Противоречие было бы, если бы, например, пользователь вручную прокладывал маршрут (если предположить такую возможность) через запрет. И то выход из положения есть - указать ему на запрет в "таком-то месте" и запросить подтверждение проезда в этом месте.
"Вот если бы все на мине подорвались... Но об этом можно только мечтать !"
K750i + HP4700 + BT338
K750i + HP4700 + BT338
Я не совсем четко сформулировал свою мысль.
В обсуждаемом случае "более сильное условие" это не запрет проезда ("черный затор"), а отсутствие возможности проехать в требуемом направлении (однонаправленная дуга графа): дуги графа в направлении лжезатора в принципе не существует. Во встречном направлении дуга есть, но это совсем другая дуга.
В обсуждаемом случае "более сильное условие" это не запрет проезда ("черный затор"), а отсутствие возможности проехать в требуемом направлении (однонаправленная дуга графа): дуги графа в направлении лжезатора в принципе не существует. Во встречном направлении дуга есть, но это совсем другая дуга.
Трудно понять. Вы используете программу на базе ядра годичной давности, я - современную версию ядра. За год ядро сильно изменилось и вспомнить детали о том, что было и как реализовано год назад нереально, а главное - бессмысленно пытаться латать трижды устаревшую версию. Судя по коду дуракозащита в API была всегда. Но есть основания полагать, что пробки подгружаются минуя API при помощи высокопроизводительного файлового интерфейса. В нем есть входной контроль идентификатора дуг, но нет контроля направления на который требуются значительные ресурсы, а текущая стратегия модификации ядра заключается ровно в обратном - в минимизации потребности в ресурсах (моя рабочая гипотеза по BT+VGA для 4700 состоит в том, что если сократить требовательность к ресурсам это может повысить устойчивость - в любом случае, это единственное, что я могу предпринять в этом направлении: BT ядро не трогает и сообщений о критических сбоях ядра имеющих шансы порушить операционку у меня нет).Чайни писал(а):А откуда эти лжезаторы берутся ? Их СМИЛинк передаёт в таком виде ? Тогда действительно, защиту от дурака надо сделать