СитиГИД перешел на новые алгоритмы обработки информации о пробках

[Vlad_SP]

Вот сегодня варианты прокладки маршрута.

53км за1:05

Или

32км за 1:15.

Есть ли смысл ехать лишних 20км из-за сомнительных10 минут выигрыша.

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

(скучающе зевая....) Аааа.... Уже стопицот раз об этом писалось. Но, видимо, для менеджеров МИТа эта функция на ...дцатом месте по приоритету.

[svlad2012]

(скучающе зевая....) Аааа.... Уже стопицот раз об этом писалось. Но, видимо, для менеджеров МИТа эта функция на ...дцатом месте по приоритету.

 

На данном этапе развития у СГ есть три маршрута: оптимальный (быстрейший), короткий и пешеходный. Вы хотите, чтобы СГ предлагал на выбор один из этих трех маршрутов? 

 

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

 

Единственное, что можно предложить, как мне кажется, - это альтернативный маршрут с другой степенью сглаживания. Получиться ли он при этом короче? Думаю, что не всегда.

[Толян]

невозможно

Гугл и прогород об этом не знали и сделали.

[sashaan]

невозможно сосчитать другой "такой же" маршрут - чуть помедленнее, но зато покороче

 

LOL )))   как вариант - выбор кратчайшего маршрута ))) 

 

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

[bushmen]

чуть помедленнее, но зато покороче

 А кто сказал, что "чуть помедленнее"? Просто "короче", а уж со временем, как получится.

 

1000-ое сообщение

Изменено 6 декабря, 2013 пользователем bushmen

[leshiy2k]

и при выдаче вариантов указать среднюю скорость на каждом и количество маневров

Не надо! По крайней мере на маршрутах длиной 3 и более тысячи километров. Количество маневров на экран не уместится.

Гугл и прогород об этом не знали и сделали.

Да неужели? В какой версии ПроГород так сделал? А то мужики-то не знают... Там есть варианты "Быстрый", "Удобный" и "Короткий". Быстрый обычно оказывается не быстрым, короткий не коротким и удобный неудобным. Но задумка была - минимум времени для быстрого, минимум маневров для удобного и минимум расстояния для короткого. Удобный еще и типа с учетом некоторого влияния пробок считается, короткий - без учета пробок вообще.

И до кучи - ПроГород сделал расчет на сервере при учете пробок. Мощности хорошего сервера и коробочки на ВинСЕ как-то трудно сравнивать... А уж с учетом, что у ПГ вообще облако считает маршруты и пробки...

Изменено 6 декабря, 2013 пользователем leshiy2k

[arctec]

Не надо! По крайней мере на маршрутах длиной 3 и более тысячи километров. Количество маневров на экран не уместится.

Давать в форме 1.3425Е+10

Поправлено с моего GT-N7000 при помощи T9

[/DiOs]

На месте МИТа, чтобы отвязаться от всех желающих между выборами президента ну хоть что-нибудь повыбирать, я бы сделал очень просто: выдавал бы маршрут с учётом пробок и без учёта, но с учётом текущей псевдостатистики. Первый назвал бы "Быстрее", второй -- "Короче". Ничего нового для этого добавлять вообще не надо.

[bushmen]

Первый назвал бы "Быстрее", второй -- "Короче".

 Мне кажется, что в этом случае далеко не всегда псевдостатистика будет короче по расстоянию.

[leshiy2k]

 Мне кажется, что в этом случае далеко не всегда псевдостатистика будет короче по расстоянию.

Тогда называть "Быстрее" и "Короче, Склифосовский!"

[svlad2012]

внутренний голос мне подсказывает, что в процессе расчета маршрута СитиГИД получает НЕСКОЛЬКО маршрутов, и выбирает из них самый "быстрый"

Уверен, что врёт!

 

Гугл и прогород об этом не знали и сделали.

Мы, похоже, говорим о разном.

Я о том, что алгоритм строит маршрут, чтобы получить минимальное (экстремум функции) значение времени, или расстояния, или пр. Алгоритм не может получить промежуточное значение.

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

Что делает Гугл и прогород мне не ведомо, но подозреваю, что у гугла разные маршруты - разные графы дорог.

 

З.Ы. А может сделать так:

 

В левой колонке - установленные значения (маршрут по умолчанию), в правой - с чем хотим сравнить.

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

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

Третья - где мы не хотим ехать (стандартная для всех карт)

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

[/DiOs]

Я о том, что алгоритм строит маршрут, чтобы получить минимальное (экстремум функции) значение времени, или расстояния, или пр. Алгоритм не может получить промежуточное значение.

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

 Мне кажется, что в этом случае далеко не всегда псевдостатистика будет короче по расстоянию.

А вы попробуйте -- это же легко делается.

[IШIN]

На данном этапе развития у СГ есть три маршрута: оптимальный (быстрейший), короткий и пешеходный. Вы хотите, чтобы СГ предлагал на выбор один из этих трех маршрутов? 

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

 

я бы сделал очень просто: выдавал бы маршрут с учётом пробок и без учёта, но с учётом текущей псевдостатистики. Первый назвал бы "Быстрее", второй -- "Короче". Ничего нового для этого добавлять вообще не надо.

 

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

Например, предложить варианты маршрута

1. Кратчайший

2. Быстрейший (ныне оптимальный)

3. Без пробок (по статистике)

4. С платными дорогами (если щтатно у юзера платная галка снята)

5. С магистралями/без магистралей (в зависимости от состояния галки, которой сейчас нет, но может быть когда-нибудь сделают...)

Рассматривать разные варианты "избегать объездов" я б не стал, они КМК не меняют маршрут принципиально.

 

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

ИМХО, было б забавно. В отном случае предлагает с КАДом и без, в другом с ЗСД и без, в третьем - только один вариант (т.к. все остальные все равно длиннее и дольше.)

[svlad2012]

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

 

Только вот что за пр. взять -- договориться не могут. И не только они.

Так я это и не утверждаю. Только для лучшего взаимопонимания.

 

Думаю, что не столько договориться, сколько формализовать эту функцию, чтобы она всегда вела себя адекватно. Ведь где-то я уже приводил результаты моделирования построения маршрута типа "учитывать 80% скорости и 20% длины", тогда у меня получилось, что результат очень зависит от распределения пробок и топологии - где-то маршрут получался на 20% короче, а где-то нет

[/DiOs]

Вот из разряда "ничего не добавлять" есть же еще варианты

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

М-да...

[svlad2012]

 Мне кажется, что в этом случае далеко не всегда псевдостатистика будет короче по расстоянию.

Подтверждаю - по статистике может быть длиннее и дольше.

От дома до работы статистика меня ведет по КАД/ЗСД с временем 55 мин.

С пробками бывают варианты: быстрее - также по КАД/ЗСД, но с временем около 47 мин (прогноз и фактически)

                                                     короче   - через центр, но с временем порядка 1 час 30 мин

[/DiOs]

Думаю, что не столько договориться, сколько формализовать эту функцию

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

Подтверждаю - по статистике может быть длиннее и дольше.

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

[arctec]

Я о том, что алгоритм строит маршрут, чтобы получить минимальное (экстремум функции) значение времени, или расстояния, или пр. Алгоритм не может получить промежуточное значение.

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

А если взять быстрейший маршрут и ещё несколько быстрых, но медленнее быстрейшего на (пальцем в небо) 20%, и из этого набора выбрать кратчайший?

Поправлено с моего GT-N7000 при помощи T9

[svlad2012]

А если взять быстрейший маршрут и ещё несколько быстрых, но медленнее быстрейшего на (пальцем в небо) 20%, и из этого набора выбрать кратчайший?

Поправлено с моего GT-N7000 при помощи T9

Если вопрос ко мне, то не по моей зарплате

 

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

[arctec]

Если вопрос ко мне, то не по моей зарплате

 

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

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

[ERER]

На месте МИТа, чтобы отвязаться от всех желающих между выборами президента ну хоть что-нибудь повыбирать, я бы сделал очень просто: выдавал бы маршрут с учётом пробок и без учёта, но с учётом текущей псевдостатистики. Первый назвал бы "Быстрее", второй -- "Короче". Ничего нового для этого добавлять вообще не надо.

 

А вот нельзя ли сделать так: классический "Оптимальный" и маршрут где к критериям "Оптимального" добавляется критерий максимизации средней скорости на маршруте? Не знаю возможно-ли такое.   Если результаты по времени будут отличаться незначительно (критерий незначительности определяется отдельно), то предлагать пользователю выбор из этих двух маршрутов. Путь он решает стоять 1 час в пробках в городе или тот же час ехать по КАДу..

Изменено 6 декабря, 2013 пользователем ERER

[/DiOs]

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

[Artur273]

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

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

[svlad2012]

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

Хм, на мой взгляд, петли - следствие векторности пробок.

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

 

А вот нельзя ли сделать так: классический "Оптимальный" и маршрут где к критериям "Оптимального" добавляется критерий максимизации средней скорости на маршруте? Не знаю возможно-ли такое.   Если результаты по времени будут отличаться незначительно (критерий незначительности определяется отдельно), то предлагать пользователю выбор из этих двух маршрутов. Путь он решает стоять 1 час в пробках в городе или тот же час ехать по КАДу..

 Масло масляное: S=V*t. Уменьшая t мы автоматом увеличиваем V

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

Сформулируйте его, пожалуйста, четко

[ERER]

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

 

Нет. Это делается только один раз.