Лучшее - враг хорошего?

[ERER]

Сдается мне, что на данный момент к СГ очень хорошо подходит фраза, вынесенная в название темы.

Вот несколько мыслей, подтверждающих это, на основе достаточно активного использования СГ-а вот уже ЕМНИП 4-й год.

1. Скорости.

Сейчас СГ указывает скорости с точностью до 1 км/ч. Причем не только указывает, но и если я ничего не путаю, использует эти значения при прокладке. Все вроде хорошо. Кроме одного. Эти значения не являются реальной скоростью на данном участке. Почему? Да потому, что СГ отображает просто среднюю скорость последнего датчика. А почему данный датчик проехал с какой скоростью? Двигался ли он быстрее потока или медленнее? Программе это неведомо. Но СГ не задумываясь ставит 34 км/ч, после чего также, не задумываясь меняет ее на 45 км/ч, получив данные от другого датчика, а затем и на 21 км/ч, т.к. третий датчик просто напросто остановился на красный сигнал светофора. И все эти изменения могут повлиять (и влияют) на выбор маршрута. Хотя никаких причин для этого нет. Загрузка данного участка не менялась вообще.

Поэтому логично приходи к тому, что нет никакой необходимости учитывать скорость датчика с точностью до 1 км/ч. Т.к. эта точность намного выше погрешности, которая в нашем случае даже ИМХО не поддается учету.

Вполне достаточно для города использовать шаг учета в 10-15 км/ч, а разделить зоны примерно так:

(т.е. другими словами вернуться на некоторое время назад )

[1] - 5 км/ч и ниже.

[2] - от 5 до 15 км/ч

[3] - от 15 до 30 км/ч

[4] - от 30 до 45 км/ч

[5] - от 45 до 60 км/ч

[6] - от 60 км/ч и выше.

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

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

Ну а для статистики данные датчиков естественно используются в полном объеме.

Продолжение, надеюсь, следует ...

[YoGun]

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

:blink:

[ERER]

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

И что? Пример в данном случае - это просто пример-пояснение.

Изменено 25 января, 2011 пользователем ERER

[YoGun]

По Вашему примеру, это значит, что на после проезда каждого из датчиков, скорость будет так же меняться: [4], [5], [3].

Я бы ещё понял, если бы речь шла об усреднении. Но для этого, на мой взгляд, ещё недостаточно датчиков. В противном случае, мы получим, что прежде чем скорость упадёт с [допустим] 50, до 5, туда надо будет загнать несколько человек.

[YoGun]

Я в этом смысле больше поддерживаю точку зрения, озвученную в своё время господином Oxigenом, о том, что достаточно всё равно 80 там или 82, но вот 5 или 2 это имеет значение. Более того, в Москве эти "5" и "2" не отражают полную картину, равно как и "15", и "7". С чём я и пытался достучаться до руководства МИТа, однако тест в Питере показал, что дело не в особенностях Московского движения, где можно простоять на одном месте несколько десятков минут, и что видимо в Питере тоже происходит, однако программа до сих пор в этом смысле на том же месте.

[ERER]

По Вашему примеру, это значит, что на после проезда каждого из датчиков, скорость будет так же меняться: [4], [5], [3].

Я же говорю, что просто описание.

Вот упрощенная иллюстрация:

Сейчас:

Датчик проехал на зеленый:

Второй постоял на красном:

Маршрут сменился на более длинный и не факт, что более быстрый.

При "зональности":

Датчик проехал на зеленый:

Второй постоял на красном:

Маршрут не сменился.

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

[YoGun]

Я же говорю, что просто описание.<...>

Я Вам скажу больше, если б маршрут бы сначала считался по скоростям Статистическим, а затем наклдывались бы пробки и просчитывалось, есть ли смысл объезжать, то уже было бы лучше. Однако сейчас считается сразу с наложением пробок на карту. В результате, если один датчик простоял на светофоре, то Вас пошлёт в объезд, даже если другой проехал на зелёный. И маршрут пересчитается только в том случае, если Шумахер разгонится и проедет это же самое место с достаточной скоростью, что бы превысить дельту, которая заложена в программу. (Там ещё, конечно, роль играют и повороты и их количество, но в упрощёном варианте можно и так сказать.) Что мы и видим и с карманами, и П-образными объездами (в 5.0 не такими бросающимися в глаза).

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

[PsevDANIm]

ИМХО - зональность не решение проблем.

Главная, на мой взгляд, мысль была озвучена, но отодвинута на второй план:

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

Скорость должна быть (60+5)/2=32. Следовательно, если туда заезжает ещё один датчик и его скорость тоже 5 => (32+5)/2=18, что уже, согласитесь, существенно понижение скоростного индекса, и скорее всего Вас уже поведёт в объезд.

Предположим - трудность была из-за проезда чиновника, и пробка быстро рассасывается, и вот уже четвёртый датчик выдаёт скорость 45 => (18+45)/2=35 - вполне рабочая уже не пробочная скорость - маршруты не ломаются!

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

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

Изменено 25 января, 2011 пользователем PsevDANIm

[WhAle_15]

Т.е. после 60 - не может быть сразу 5. Скорость должна быть (60+5)/2=32. Следовательно, если туда заезжает ещё один датчик и его скорость тоже 5 => (32+5)/2=18, что уже, согласитесь, существенно понижение скоростного индекса, и скорее всего Вас уже поведёт в объезд.

В таком примере вижу следующий нюанс. Итак, с моей колокольни...

Как Вы думаете, с какой скоростью образуется пробка? То есть так, что было свободно - и уже стоим. По приведённому выше алгоритму получается так, что если скорость на ребре реально замедлилась до 5км/ч, то после проезда именно по нему двух датчиков мы получаем на выходе скорость всего лишь 18км/ч. И неизвестно сколько времени понадобится для получения данных, чтобы скорость на том ребре превратилась в реальную. Такой алгоритм имеет смысл только тогда, когда за определённый небольшой промежуток времени приходит большое количество данных по одному ребру от разных датчиков, в противном случае он только усугубляет ситуацию.

[ERER]

Я Вам скажу больше, если б маршрут бы сначала считался по скоростям Статистическим, а затем наклдывались бы пробки и просчитывалось, есть ли смысл объезжать, то уже было бы лучше. Однако сейчас считается сразу с наложением пробок на карту. В результате, если один датчик простоял на светофоре, то Вас пошлёт в объезд, даже если другой проехал на зелёный. И маршрут пересчитается только в том случае, если Шумахер разгонится и проедет это же самое место с достаточной скоростью, что бы превысить дельту, которая заложена в программу. (Там ещё, конечно, роль играют и повороты и их количество, но в упрощёном варианте можно и так сказать.) Что мы и видим и с карманами, и П-образными объездами (в 5.0 не такими бросающимися в глаза).

Мне не надо рассказывать как работает сейчас. Я как бы в курсе. Зональность как раз и уменьшит вероятность описанного выше.

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

Это где так? На данный момент при всеобщем стоянии я вижу весь диапазон скоростей, начиная от 2 км/ч.

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

[Пирс]

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

Меню-> Маршрут->Тип-> Кратчайший?

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

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

Ну или связать пробки с ДПОИ. Кто-нибудь отметил аварию, и сервер свяжет ее с низкими скоростями от датчиков на этом ребре, и средним временем разъезда аварии, и выдаст прогноз для этого ребра.

Изменено 26 января, 2011 пользователем Пирс

[ERER]

Меню-> Маршрут->Тип-> Кратчайший?

Не катит, т.к. великое стояние далеко не по всему маршруту. ;)

[eklmn]

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

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

[1] - 5 км/ч и ниже.

[2] - от 5 до 15 км/ч

[3] - от 15 до 30 км/ч

[4] - от 30 до 45 км/ч

[5] - от 45 до 60 км/ч

[6] - от 60 км/ч и выше.

то, например, датчик проехавший со скоростью 14.5 км/ч попадает во вторую зону,

а со скоростью 15.5 км/ч уже в третью.

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

[ERER]

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

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

[1] - 5 км/ч и ниже.

[2] - от 5 до 15 км/ч

[3] - от 15 до 30 км/ч

[4] - от 30 до 45 км/ч

[5] - от 45 до 60 км/ч

[6] - от 60 км/ч и выше.

то, например, датчик проехавший со скоростью 14.5 км/ч попадает во вторую зону,

а со скоростью 15.5 км/ч уже в третью.

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

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

[eklmn]

так и получается, что на границах ступенек "гуляние маршрута" не уменьшится, а наоборот, увеличится.

Зачем тогда огород городить?

[ERER]

так и получается, что на границах ступенек "гуляние маршрута" не уменьшится, а наоборот, увеличится.

Зачем тогда огород городить?

Вероятность попадания датчика в пограничное значение много меньше.

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

[eklmn]

Вероятность попадания датчика в пограничное значение много меньше.

Вот тут не соглашусь.

Эта вероятность зависит от количества зон.

Чем больше ступенек, тем выше вероятность "нарваться" на границу.

Соответственно, если ступенек нет, то и попаданий на границу не будет.

как-то так... :)

[ERER]

Вот тут не соглашусь.

Эта вероятность зависит от количества зон.

Чем больше ступенек, тем выше вероятность "нарваться" на границу.

Соответственно, если ступенек нет, то и попаданий на границу не будет.

как-то так...

Ты исходишь из того, что скорсоть датчика - скорость ребра. Но это не так.

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

Изменено 3 февраля, 2011 пользователем ERER

[eklmn]

Да всё равно, что это будет за скорость (хоть усредненная, хоть статистически нормализованная, хоть сферического коня в вакууме).

Главное принцип: маленькое изменение этой скорости вызовет необоснованное серьёзное изменение маршрута.

Именно от этого ты и пытался уйти, когда предлагал ступеньки.

Но улучшение происходит только в пределах ступеньки, а на границе, наоборот ситуация ухудшится.

И чем больше ступенек, тем больше этих зон ухудшения.

Стало быть, самый лучший вариант совсем без ступенек?

[ERER]

Главное принцип: маленькое изменение этой скорости вызовет необоснованное серьёзное изменение маршрута.

Именно от этого ты и пытался уйти, когда предлагал ступеньки.

Но улучшение происходит только в пределах ступеньки, а на границе, наоборот ситуация ухудшится.

И чем больше ступенек, тем больше этих зон ухудшения.

Стало быть, самый лучший вариант совсем без ступенек?

Нет. Сейчас в диапазоне, к примеру, 90 км/ч имеем 89 ступенек, вместо, к примеру, 5-ти.

[eklmn]

Нет. Сейчас в диапазоне, к примеру, 90 км/ч имеем 89 ступенек, вместо, к примеру, 5-ти.

Но изменит маршрут только одна из этих маленьких ступенек, также как и только одна большая.

Просто изменение маршрута наступит не на скорости 36 км/ч, а на скорости 45 км/ч.

Вот и вся разница.

Думаю надо не ступеньки делать, а как-то усреднять скорости датчиков.

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

Это уже где-то в другой теме обсуждают.

Изменено 3 февраля, 2011 пользователем eklmn

[ERER]

Но изменит маршрут только одна из этих маленьких ступенек, также как и только одна большая.

Просто изменение маршрута наступит не на скорости 36 км/ч, а на скорости 45 км/ч.

Вот и вся разница.

Поясни.

Сейчас смена скорости с 34 на 35 может сменить марршрут, также как с 35 на 36 или с 38 на 34, не говоря уже от смене с 44 на 31. В отличии от зонального. Т.е. количество вероятных перерасчетов уменьшается.

Просто нельзя опираться в расчетах на разницу в значениях, которая меньше (много меньше) погрешности измерения. А сейчас именно так и происходит.

[eklmn]

Поясни.

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

меняем скорость на правом плече.

Без ступенек СГ до 36 км/ч поведет налево, больше 36 - направо.

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

А если со ступеньками, то всё точно также, только скорость при которой будет перепрокладка, теперь сместится на то значение, которое установлено, как граница зоны (45 км/ч).

т.е. до 45 налево, больше 45 - направо.

Мне кажется так.

Изменено 3 февраля, 2011 пользователем eklmn

[Пирс]

Просто нельзя опираться в расчетах на разницу в значениях, которая меньше (много меньше) погрешности измерения. А сейчас именно так и происходит.

Это правильно, но ступеньки скорости эту проблему только усугубят. (14 км/ч попадает во вторую ступеньку, а 16 в третью)

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

[PsevDANIm]

Лучшие ступеньки используются сейчас - шаг = 1 км/ч.

Сокращение кол-ва ступенек (сейчас 120;)) даже если хотя бы на минимум т.е. в 2 раза приведёт к большему % погрешности.

Чем меньше ступеней - тем больше %.

ИМХО.