Странно, карта новая, а маршруты старые...

[Кокос]

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

[d2003]

По поводу развязок МКАД это вечная проблема, встречающаяся очень часто. Однозначно что виноват алгоритм.У меня есть подозрение, что алгоритм вообще не учитывает повороты, развороты в построении маршрута. В результате он считает что развернутся на 180 градусов и проехать на 5 метров меньше - это лучше чем ехать лишнии 5 метров по стандартной развилке. А т.к. еще не всегда верна информация о возможности разворота - то и получаются какие грабли.
Что на это скажут разработчики?

Дмитрий

[Alikante]

Версия 1.42 на ЛЮБЫХ развязках, при которых вам надо пересечь будущую траекторию движения (по эстакаде или под ней) ошибочно путает Право\Лево. Например если вы едете по внешнешнему МКАДУ и затем по Ленинградке в центр, на подъезде к эстакаде прога будет орать "Налево", хотя там бетонный разделитель. Та же история при подъезде по Рублевке к эстакаде Кутузовского, если ехать в центр. Та же ситуация при движении с внутреннего МКАДа по Дмитровке в область. Та же ситуация при движении с внутреннего МКАДа на Осташковское в область. Та же бодяга с внутреннего МКАДа по Новорязанке в область. Это ОШИБКА программы. Видимо, там дефект математики. У меня, поэтому, к разработчикам нет вопроса почему это происходит - на вопрос откуда берутся рукосуи и раз3,14дяи вразумительный ответ дать трудно. У меня вопрос, когда (с извинениями) будет предоставлена пользователям исправленная версия?
Я пока еще не скачал себе версию 1.50, может там уже эта дырка исправлена.
Есть еще замечания по пробкам. Прикупил тут Роад информер и в первый же день его пользования опоздал в аэропорт. На информере пробка на МКАД от Рублевки до Ленинградки была не указана, при этом была указана пробка в обратном направлении, которой на самом деле не было - народ свистел мимо под "сотку". Если скрестить такого рода инфу (а на 77.ру ошибок в указании пробок больше чем в СМИлинк) то пользование системой должно будет давать эффект в стиле "полный сюр" - Программа, с ошибками в топологии, будет прокладывать маршрут в объезд несуществующих пробок, по пробкам, не указанным в системе. А потом еще спрашивают кто такой Сусанин, откуда он родом. Так что с нетерпением жду загрузки бета-версии (очень благодарен за признание этого факта - значит 1.42 - квази-бета-версия!). Буду испытывать. Впечатлениями поделюсь. Особенно от сравнения пробковых реалий с тем, что показывает 77.ру и Роадинформер одновременно.

Еще вопрос - что означает "Не могу соединить две точки маршрутом"?

[VctOs]

Версия 1.42 на ЛЮБЫХ развязках, при которых вам надо пересечь будущую траекторию движения (по эстакаде или под ней) ошибочно путает Право\Лево.

А сам маршрут он как строит?
Так:


или так как говорит голосом?

Еще вопрос - что означает "Не могу соединить две точки маршрутом"?

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

[Alikante]

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

Так что на вашей картинке маршрут проложен как раз так же, как и у меня. Только перед мостом Кутузовского прога нещадно орет "налево!".

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

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

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

Может я конечно и ахинею написал - без объявленной идеологии программы понять алгоритмы затруднительно. Однако, то что указанное мною свойство программы делать срезки - это точно ОШИБКА программы.

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

А то надоело смотреть, как тебя система толкает на 3-е кольцо, где в случае замедления движения ехать медленнее, чем мимо него.

[VctOs]

Я вообще понял, что это ошибка программы, когда не сам был за рулем, а для прикола решил поштурманить.
Тогда то я и разглядел, что вектора на карте указаны верно, и маршрут она правильно по развязке рисует.

Может я конечно и ахинею написал - без объявленной идеологии программы понять алгоритмы затруднительно. Однако, то что указанное мною свойство программы делать срезки - это точно ОШИБКА программы.

Согласно моей информации, полученной с использованием должностного положения от пожелавшего остаться неизвестным компетентного источника , эта "ОШИБКА" исправляется установкой ползунка "ключевые точки маршрута" вкладки "маршрут" диалога настроек (см. стр.28 документации с http://www.pocketgps.ru/download/Pocket ... al_119.pdf )

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

Согласно данным карты движения по Мансуровскому нет. Поэтому прокладка маршрута осуществляется до Еропкинского. У меня с Комсомольского маршрут прокладывается через Льва Толстого - Зубовскую - Пречистенку.

[Alikante]

К сожалению, предлагаемые компетентными источниками ответы только подтверждают, что программу перед продажей никто толком не тестировал. Или те, кто тестировал работать не умеют.
Повторяю в чем ошибка программы.
Рисует маршрут она ПРАВИЛЬНО. Врет блок ГОЛОСОВЫХ и ВИЗУАЛЬНЫХ ПОДСКАЗОК. Именно поэтому я понял в чем ошибка только когда не сам рулил. Это блок подсказок норовит столкнуть в срезку при пересечении текущего положения с будущим направлением движения.
Стыдно господа! Если уж обосрались - умейте хоть этот факт определить самостоятельно, а не кивать на чувствительность носов окуржающих!

К вопросу об этом самом регуляторе "Ключевые точки маршрута". Этот регулятор у меня стоит в крайнем левом положении, по причине того, что иначе программа вводит в заблуждение постоянным базаром: "правее-левее". При подъезде к перекрестку с не перпендикулярным пересечением проезжих частей или (не дай Бог) с числом пересекающихся векторов более двух понять куда прога рекомендует ехать - невозможно. Я сегодня проверю - если сдвинуть эти "ключевые точки" в среднее положение будет она врать развязки МКАДа или нет. Но по любому, если и перестанет, то это означает цепной дефект алгоритма, причина которого - игнорирование решения задачи выдачи рекомендаций по маневрированию ТОЛЬКО в местах пересечения проезжих частей.

По поводу непроезжего Мансуровского - это что, опять "К пуговицам претензий нет?" Но претензии есть и к пуговицам и к крою. Или вы не отвечаете за качество работ ваших субподрядчиков? Может вам объяснить, что, в случае иска, суд (если он только не совсем басманный) удовлетворит претензию к вам, при этом у вас будет право привлечь в качестве СООТВЕТЧИКА авторов картографии?

Лучше бы мне спасибо сказали за бесплатное тестирование.

[VladNew]

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

[VctOs]

Рисует маршрут она ПРАВИЛЬНО. Врет блок ГОЛОСОВЫХ и ВИЗУАЛЬНЫХ ПОДСКАЗОК. Именно поэтому я понял в чем ошибка только когда не сам рулил. Это блок подсказок норовит столкнуть в срезку при пересечении текущего положения с будущим направлением движения.

Спасибо за то, что Вы помогли мне разобраться с этим. Я написал Вас о ползунке не в порядке отмазки, а потому, что не был уверен в том, что Вы поробовали его понастраивать.

Стыдно господа! Если уж обосрались - умейте хоть этот факт определить самостоятельно, а не кивать на чувствительность носов окуржающих!

Поймите меня правильно. Общение с Вами не входит в круг моих обязанностей. Я ответил Вам потому что мне показалось, что Вы заинтересованы в улучшении программы и что наше общение возможно поможет улучшить программу. Я никоим образом не навязываю Вам мое общество, но если Вы расчитываете на мои ответы, постарайтесь строить фразы корректнее, в том числе принимая то, что Вы не располагаете сведениями об архитектуре продукта, а я не обо всем могу говорить в форуме и не имею ни опыта работы с продуктом, ни сведений о реализации его пользовательского интерфейса. Но зато я лучше всех знаю как используемое в PocketGPS картографическое ядро "LaserMap Advanced Kernel" _прокладывает_ оптимальный маршрут.
Кстати, о пуговицах.
Маршрут прокладывается по гарантирующему оптимальность результата алгоритму Дейкстры на основании пошлин, указанных картографами как оценка времени, требуемого на проезд по дуге. Затраты времени на маневры учитываются только в тех местах, где на карте явно изображены дуги маневров (территория Москвы и Зеленограда). Критерием оптимальности маршрута является минимизация суммы пошлин дуг. "Въезд" и "выезд" на ближайшую дугу осуществляется по воздушной прямой без учета существующих на местности и изображенных на карте препятствий (бордюрный камень, здания, водоемы, железные дороги, кустарник, газоны и т.д.). Пока я не видел ни одного сообщения, говорящего о том, что алгоритм поиска оптимального маршрута работает неверно.

Я сегодня проверю - если сдвинуть эти "ключевые точки" в среднее положение будет она врать развязки МКАДа или нет. Но по любому, если и перестанет, то это означает цепной дефект алгоритма, причина которого - игнорирование решения задачи выдачи рекомендаций по маневрированию ТОЛЬКО в местах пересечения проезжих частей.

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

По поводу непроезжего Мансуровского - это что, опять "К пуговицам претензий нет?"

Нет. Для того, чтобы понять причину проблемы необходимо ее воспроизвести. Мне описанную Вами ситуацию воспроизвести не удалось: маршрут у меня проложился совершенно не так как у Вас. Я не исключал вероятность использования различных версий карты и прокладки маршрута из разных точек.
Кстати, раз уж мы начали об этом говорить: разрешен ли по фактическому состоянию местности проезд по Мансуровскому?

[PanD@]

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

Есть старый анекдот. Разговаривают два программиста:
- Мой алгоритм оптимальный!
- А мой правильный!



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

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

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

[VctOs]

Есть старый анекдот. Разговаривают два программиста:
- Мой алгоритм оптимальный!
- А мой правильный!

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

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

Без учета критерия оптимальности правильным должен быть признан любой маршрут, соответствующий топологии графа организации дорожного движения. Например, не говоря об оптимальости, нельзя назвать неправильным маршрут, проложенный от станции метро Юго-Западная до станции метро Кузьминки через г.Волоколамск.
Поэтому в обсуждаемом случае правильным следует считаеть только оптимальный маршрут.

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

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

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

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

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

[VladNew]

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

[d2003]

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

Дмитрий

[Alikante]

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

Что критично. Алгоритм, использованный в обсуждаемой программе - не единственный.
В других известных мне алгоритмах (Smartpath, Tom-Tom, ПАЛМГИС и используемый в машинах Опель) проблемы "право-лево" при пересечении (в 2-D) текущей позиции с будущим маршрутом не существует.
Как не существует проблемы указаний системы "правее-левее" в условиях отсутствия пересечений пороезжих частей.

Нет в них также регулятора плотности точек маршрута.

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

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

В случае, когда, например, автобан не имеет съездов, как бы не петляла сама дорога (например автобан Запад-Восток в Швейцарии или автобан Монте-Карло - Ницца), система молчит, пока вы не начнете приближаться к указанному в проложенном маршруте съезду.
Там есть еще одна хорошая функция. Если вы засомневались правильно ли вы едете, вы нажимаете кнопку "Подсказка пути" и ласковый женский голос говорит вам расстояние до ближайшего поворота - например : "Через 20 миль на перекрестке с круговым движением третий поворот налево" (в Англии)

Употребленное вами слово "воздушное" многое объясняет в идеологии системы. Мне кажется ее изначально делали для авиации. Так как если все это давать в 3-D, то по таким указаниям очень удобно сажать самолет вслепую в полном тумане ночью при выключенных огнях на ВПП. Тогда, действительно, надо отслеживать все изгибы трассы движения. На земле же, в авто, такая плотность точек избыточна. Она только ресурс КПК сжирает.
Поэтому-то программе не хватает памяти проложить маршрут от Бронниц до Шереметьево. Хотя на том же КПК, другая программа легко прокладывает маршрут от Парижа до Варшавы.

Может к движку "плотность точек маршрута" добавить флажок "Только пересечения проезжих частей"?

И вообще, есть ли смысл трахаться с доводкой алгоритма Лазер-мэп, если он был разработан для других целей? Может лучше купить готовый алгоритм от Том-Том или какой еще? Может тот же ПалмГисовский? Никому же в голову (кроме совсем отчаянных) не приходит сегодня писать новый Windows для коммерческих целей. Написать то можно, но писать и отлаживать будешь очень долго и угрохаешь кучу денег на это. При всех недостатках этих самых Окон, вероятность того, что новая система такого же масштаба окажется лучше, не слишком велика.
Хороших вам выходных

[VctOs]

Я тоже хочу внести свою лепту в модификацию алгоритма прокладки маршрута.

Но ведь по-моему все (по Москве) уже реализовано именно так как Вы предлагаете.
Вот пример типового перекрестка:

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

Ну и разворот соответственно.

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

Я думаю что это решит многие проблемы.

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