timvetrov

А еще СГ не умеет измерять скорость интернета...

ОК, поставим SP. Thanx.

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

SP - это же сервис-пак? Или я отстал от жизни и что-то недопонял? Вот в этой версии так же все печально с тапом, как и в 7.7 до сервис-пака? В принципе, моя коллега пользуется 7.7 на TN-610HD и не сильно плачет (но она знавала ПО и похуже намного, все-таки работает в области Clinical Research). Я имею в виду - после 7.2 будут ли проблемы с этим тапом на 7.7 - или все в рамках приличий (ну, 1-2 секунды подождать, а не 3-4-5)?

Вспоминается гениальный Черномырдин. "Никогда такого не было, и вот опять!" Sorry за офф-топик. На самом деле, проблема известная, что-то МИТ подкрутил, и вылезли проблемы пользователей, некорректно перенесших лицензию, а также другие глюки. Надо проверить логин/пароль и написать в техподдержку email.

Вроде бы проблемы наблюдались у пользователей, некорректно перенесших лицензию с WM. Рекомендация была проверить логин/пароль и обратиться в техподдержку.

В сервис-паке разве это не поправили? Сестра до сих пор ездит на 7.2, я ей стремался ставить 7.7 именно из-за задержки тапа, но вроде сообщали, что в сервис-паке проблема решена. Ставить 7.7 или нет?

В том-то и дело, что нет этих 20% (и даже 2/13=15% и тех нет на самом деле). В этом-то и проблема. СГ не просчитывает риски, а чем больше маневров, тем больше риска застрять. ИМХО да. Мне кажется, старые версии считали время лучше, т.к. были коэффициенты на маневры, а теперь в связи с пробками-2 их ликвидировали либо уменьшили. Мне кажется, лишние маневры - это зло. Допустим, есть два варианта. Один с 2 маневрами, другой с 8. Допустим, на каждом маневре можно либо выиграть 30 сек, либо потерять. Т.е. за каждый маневр должен быть штраф в 1 мин (потому что если пользователь приедет быстр

Не знаю, возможно, у меня такой проблемы нет, вот я и не понимаю, зачем следить за процессом поиска спутников. На моем аппарате спутники находятся в течение 10-20 секунд после старта. Другой вопрос, что, бывает, едешь тихо-мирно по шоссе в совершенно чистом поле, и вдруг сигнал GPS теряется. (во дворах и в городе почему-то этого как раз не бывает) Но в такой ситуации как-то странно на скорости 100 км/ч лезть куда-то и что-то там выяснять. Я просто терпеливо жду, и через 30 секунд, как правило, все восстанавливается. Вот я и не понимаю, какой практический смысл. Ну, потерялись спутни

Диагностика GPS - не задача навигационной программы.

Ветрянка тоже неплохо...

Я в итоге воспользовался IGo для андроида. Версия под андроид примитивная, но зато простая и интуитивно понятная. У подруги был IGo под айфон, там реально фиг разберешься (вынуждены были два дня пользоваться, т.к. мой багаж вместе с навигатором забыли сначала в Питере, а потом в Риме). А СГ по картам OSM не прокладывал маршрут через регионы (от Рима до Флоренции), так что пользоваться не пришлось. По Финляндии езжу с СГ+OSM. По Италии вот не получилось.

А каково практическое применение таких изысков? ИМХО, сине-желто-красной индикации вполне достаточно.

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

Вроде уже должны учитываться. Так что баги надо теперь репортировать.

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

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

Очень радует, что разработчики видят проблему. Будем ждать.

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

Таким образом, помнится, считал время Навител в свое время. Выбираешься из района на МКАД - прогноз времени в пути 4 часа. Едешь по МКАД - прогноз 20 минут. Заташниваешься обратно в Москву - опять прогнозирует, что еще 3 часа ехать. В итоге полтора часа. ИМХО, средняя скорость отдельного датчика при оценке времени прибытия вообще учитываться не должна. Пробкоданные - это усредненные данные, и вероятность проехать ребро быстрее или медленнее среднего чаще всего никак не связана с тем, что ждет меня впереди. Поясню свою мысль. Допустим, есть ребро между регулируемыми перекрестками и пробкод

ИМХО пробку перед переездом вообще учитывать некорректно. Закрыли переезд - нарисовалась пробка, открыли - реально пробки давно нет, а СГ тащит в объезд. И наоборот. Когда СГ будет учитывать время доезда и использовать статистику вместо пробочных данных, тогда это все будет актуально. А пока нет.

Цифры участвуют, но есть две проблемы. 1. Недооценка риска потери времени при маневре. Т.е. время прохождения маневра заложено в векторной скорости, т.е. никогда не учитывается риск задержки дольше, чем средняя. 2. Перескорости, т.е. учет нереальных для того, кто ездит нормально, скоростей. ИМХО, данные датчиков должны обрезаться до реальной легальной скорости (зависит от длины ребра и разрешенной максимальной скорости). Сейчас нередко вижу ребра со средней скоростью 75-80 в городе. Надо понимать, что неверный расчет времени - всего-лишь симптом.

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

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

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