Новая идея - "зависимые пробки"

[al1_]

Возникла, тут, идея, врядли она будет реализована, но всё же...

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

Например: если есть пробка на внешнем ТТК перед Нижегородской - значит, с вероятностью 90% Нижегородка в область от ТТК до Ж/Д переезда стоит. Причём, даже не важно почему стоял тот, кто нарисовал пробку на самом ТТК: если он стоял в правом ряду, чтобы повернуть на Нижегородку - очевидно, что Нижегородка стоит, если же он стоял в левом ряду, чтобы проехать прямо, то с вероятностью 90% ему мешали "козлы", которые не желают стоять в очереди, а из левого ряда втискиваются в поворот направо (в данном примере на Нижегородку).

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

Т.е., на описанном примере, - если пробка на внешнем ТТК перед Нижегородкой и на Нижегородке в область ни кто не проехал, то автоматически ставить туда пробку.

[al1_]

Более, того, этот подход можно использовать и на прямых.

Например, если появилась пробка на Рязанке в центр в районе ул. Паперника, то с вероятностью 90% она длится до эстакады. И как только появляется "маленькая" пробка в районе Паперника, не надо будет дожидаться пока датчик "проползёт" всю пробку, она сразу появится. А если датчик не доехал до конца, а свернул, то при текущем подходе появится только чать пробки, а при использовании "зависимостей" - вся.

[lipskiy]

Идея не новая:

http://forum.probki.net/forum_posts.asp?TID=1674

[lipskiy]

А это - на второй пост, про прямые:

http://forum.probki.net/forum_posts.asp?TID=1485

[al1_]

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

Тогда, вопрос к разработчикам, нашёл по выше указанным ссылкам такой ваш ответ:

---------------

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

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

---------------

Там последние посты датируются сентябрём - октябрём 2007 года, т.е. почти год прошёл, будущее уже наступило!

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

al1_2008-08-15 13:02:23

[crazydoctor]

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

Слишком хрупкий и подверженный сбоям алгоритм получается.crazydoctor2008-08-15 16:07:39

[al1_]

В том примере, который я привёл, в первом посте, даже если что-то перекроют, то всё будет работать.

1. Если перекроют Нижегородку - зависимость сохраняется - нарисованная пробка на ТТК вызывает пробку на Нижегородке (её-же перекрыли)

2. Если перекроют ТТК - то нарисовавший на нём пробку, скорее всего съедет на ближайшем съезде, а это только Нижегородка, т.е. он-же нарисует антипробку и "зависимая" пробка не появится.

А в случае когда зависимости легко разваливаются - я и говорю, что разработчики и/или пользователи должны смотреть чтобы использовались только стабильные зависимости.al1_2008-08-15 18:08:18

[lipskiy]

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

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

[yasakov]

А вот мне идея "зависимых пробок" не нравится, и вот почему.

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

Я бы сформулировал идею немного по-другому: есть места, которые являются проблемными в рабочие дни с хх ч. хх мин. по хх ч. хх мин. И совершенно необязательно, чтобы кто-то с СитиГид туда предварительно вляпался, чтобы остальные об этом узнали. А раз так - давайте вести статистику, и по аналогии с пользовательскими корректурами изменять скоростные индексы на карте. Но с учетом времени суток иили дня недели.

Мне сложно говорить о Санкт-Петербурге, но в Москве с её радиально-кольцевой структурой и большим количеством радиально-кольцевых ЖД путей, эта идея могла бы существенно повысить качество пробочной информации.

[Lucky]

А мне нравится идея зависимых пробок, только применять их надо "с умом".

Если в часы пик на каком-то ребре в центре города возникает пробка со скоростью, например, 5 км/ч, а на объездных рёбрах (ближайших) будет стоять скорость 30-40-50 км/ч, то СГ к этой пробке подведёт еще несколько десятков жертв, пока на всех объездных рёбрах не появятся хрюшки.

Считаю, что зависимые пробки надо ставить с какой-то вероятностью, например 90-95%, их образования, и не ставить пробки, а уменьшать среднюю скорость на рёбрах до 15-20 км/ч.

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

[CaHuTaP]

Прочитал пост, коментарии, блин, как сейчас вижу сообщения на форуме типа "ехал, стояла хрюшка, а пробки нет!". И опять обругают Ситигид...

Кстати, у самого возникла идея!

Для реализации оной, правда, потребуется много работы для картографов... Что уже уменьшает шансы ее реализации...

А именно... В карты надо "вшить" светофоры(просто-есть или нет) на перекрестках улиц, а также на тех перекрестках, где их нет (!) отметить с кокой из улиц надо уступить дорогу.

Суть идеи. Если на какой-либо улице пробка и она является Главной, то с ОГРОМНОЙ вероятностью вьезд на эту улицу с другой, без светофора, будет проблематичен.

Должно работать, как не крути :)

[yasakov]

И опять приходим к идее учитывать а) скоростную статистику и б) привязке её (статистики) ко времени суток.

Задача в чистом виде "серверная". Сохраняйте все мои скорости, где бы я ни проехал, и время, когда ездил. И не только мои. А затем высчитывайте средние скорости по ребрам - НО (!) с обязательной привязкой ко времени.

Вот это была бы классная статистика!

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

[qrot]

Дело в том, что свои мысли про статистику придеться скорее всего забыть, потому что d C G писал, что ее они будут использовать только в самый последний момент, когда больше ничто улучшить сервис не поможет.

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

 

[RadioKot]

...

Единственный недостаток' date=' о котором кто-то уже писал здесь: если вдруг отчего-то на стандартном пробочном месте всё хорошо, программа туда не порекомендует ехать, ибо статистика говорит об обратном.[/quote']

Однако если кто-то проедет в таком месте быстрее, то "антипробка" на некоторе время исправит ситуацию. Каждый следующий проехавший подтвердит ее для следующих попутчиков. Если ситуация будет повторяться будет основание изменить статистику. Все это можно автоматизировать. Так что идея хорошая!

[CaHuTaP]

Кстати' date=' у самого возникла идея!

Для реализации оной, правда, потребуется много работы для картографов... Что уже уменьшает шансы ее реализации...

А именно... В карты надо "вшить" светофоры(просто-есть или нет) на перекрестках улиц, а также на тех перекрестках, где их нет (!) отметить с кокой из улиц надо уступить дорогу.

Суть идеи. Если на какой-либо улице пробка и она является Главной, то с ОГРОМНОЙ вероятностью вьезд на эту улицу с другой, без светофора, будет проблематичен.

Должно работать, как не крути [/quote']

Кто-нибудь может сказать что-нибудь по этому поводу? :)

[Lucky]

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

[CaHuTaP]

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

[YoGun]

К сожалению ссылки привёденные господином lipskiy уже не доступны, поэтому простите если это повтор.

Допустим на прямой дороге три ребра A,B,С, на ребре A и C стоят "хрюшки" 16 и 18, а с ребра B по каким-то причинам данные не пришли (человек свернул с маршрута, был сбой связи и .п.) почему бы туда автоматом не проставлять среднюю скорость соседних рёбер.

Речь идёт только о 3-х соседних рёбрах, у среднего нет данных и если разница между крайними не превышает (допустим) 5 км/ч

 

 

[Lucky]

К сожалению ссылки привёденные господином lipskiy[/color"> уже не доступны' date=' поэтому простите если это повтор.

Допустим на прямой дороге три ребра A,B,С, на ребре A и C стоят "хрюшки" 16 и 18, а с ребра B по каким-то причинам данные не пришли (человек свернул с маршрута, был сбой связи и .п.) почему бы туда автоматом не проставлять среднюю скорость соседних рёбер.

Речь идёт только о 3-х соседних рёбрах, у среднего нет данных и если разница между крайними не превышает (допустим) 5 км/ч

 

 

[/quote']

Имхо, подобный алгоритм будет скорее преследовать цель равномерно распределить пользователей СГ по пробкам, а не направлять их в альтернативу, наиболее вероятную с т. зр. макс. скорости проезда.

[YoGun]

 

А мне кажется, что при таком подходе СГ будет обходить места где недостаточно данных для того что бы перестроить маршрут (выгода менее трёх минут). Сейчас СГ считает на рёбрах, где нет данных, по скоростям по умолчанию. И может получится, что посчитает не как 16, 18 и 17, а как 16,18 и 70 (если там такая скорость по умолчанию).

 

 

[Lucky]

И СГ туда сразу пошлёт туда датчик - и всё станет известно.

[YoGun]

И СГ туда сразу пошлёт туда датчик - и всё станет известно.

 

Я имею ввиду, что если на одной улице по каким-то причинам выпало одно ребро, то не надо бы программе считать, что там свободно.

 

Яркий пример проезды под мостами на минимальной скорости в пробке. Получается скорость идёт по улице 13, 15, 12, потом проезжаем под мостом, сигнал отразился от стены, позицию "швырнуло" на съезд, потом вернулась, а в итоге ребро осталось без "хрюшки", далее идёт 14, 17, 15. Я понимаю, что одно ребро в такой ситауции "погоды не сделает". Но вдруг именно это пустое ребро окажется последней каплей к интервалу в 3 минуты, после которой маршрут бы изначально выбрался другой?

 

P.S. Датчик-разведчик там уже был, зачем жертвовать вторым...

 

 

Взглядом понятно что там твориться, но програма-то исходит из математических данных...

 

[Lucky]

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

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

Имхо, это будет достовернее.

[YoGun]

Так в этом случае' date=' могу предложить улучшение алгоритма: даже при выпадании инфы от датчика, нет проблем вычислить скорость его движения на "выпавшем" ребре, т.к. известно время начала движения по ребру (конец дв. по предыдущему) и время окончания (начало дв. по следующему).
[/quote']

 

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

Поэтому думаю это надо как-то на сервере организовать.

Что-то типа такого: приходят данные ребро С в такую-то сторону, смотрим есть ли данные на ребре B, если есть, то END, если нет, смотрим ребро A. Если С=A+/-5, то B=(A+C)/2 иначе END.

 

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

 

[sergeyastakhov]

Поэтому думаю это надо как-то на сервере организовать.

Что-то типа такого: приходят данные ребро С в такую-то сторону, смотрим есть ли данные на ребре B, если есть, то END, если нет, смотрим ребро A. Если С=A+/-5, то B=(A+C)/2 иначе END.

 

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

 

На сервере не получится. Сервер не знает причины отсутствия информации - то-ли курсор с дороги слетел и-за потери точности, то-ли человек во двор заезжал, то-ли кто-то отключил GPS, пока в ларёк за сигаретами ходил, то-ли ещё что. Пытаться восстановить потеряную информацию можно только в первом случае, но отличить её от второй даже на клиенте будет непросто...