Длинные пробки

[d C G]

Давайте теперь вместе прочитаем эту ветку:

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

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

в ближайшем будущем будет работать уже по-другому

Спасибо.

[гидро]

остаётся уповать на ближайшее будущее

[Spectre]

При попадании в пробку (то есть при движении с очень малой скоростью или при полной остановке) на очень длинном ребре крайне вероятны ситуации' date=' когда:
- улетит с дороги GPS
- GPS начнет "плясать" и поедет, в т.ч., в другую сторону
- факта выезда с ребра не будет в обозримом времени (по крайней мере, это время превысит время жизни отметки).

Это приводит к тому, что о такой пробке система получает информацию только от пользователей, нажавших Да в окне запроса, т.к. реально измерить скорость движения по ребру нечем (поскольку нет факта выезда с этого ребра, а скорость с GPS недостоверна). Соответственно и среднюю скорость по одному датчику рассчитать невозможно.
[/quote']

Прочитал всю ветку и все ответы d C G, поэтому не в порядке спора, а в порядке конструктивных мыслей выскажусь.

 

1. Улетит с дороги GPS - эту ситуацию нужно учиться обрабатывать. Причем не только в тех случаях, когда он сам "улетает", но и в тех случаях, когда мы в тоннель въезжаем. Я вижу, что работа в этом направлении ведется, но пока все еще в зачаточном состоянии. Понимаю, что проблема сложная, но решать ее все равно надо. Кстати, если отметить на карте тоннели, решение проблемы их проезда станет более простым.

 

2. GPS начнет "плясать" и поедет в другую сторону - это по сути подвид предыдущей проблемы.

 

3. Факта выезда с ребра не будет - ну на то вы и задаете вопрос "вы в пробке?" Посчитать среднюю скорость от начала ребра, до текущей его части программа вполне может. Было бы желание.

 

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

 

 

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

 

Я лично пользуюсь СитиГидом в Москве в первую очередь потому, что он, в отличии от Яндекса, умеет отличить пробку 3 км/ч от 15 км/ч. Не будь этого преимущества, я СГ включал бы значительно реже.

[RomanMak]

Я согласен со Spectre...    есть факт въезда и нет факта съезда или попадания на другое ребро, т.е. есть факт нахождения на ребре и надо уметь считать сред. скорость от начала ребра до тек. положения.   Тут никто не утверждает, что это элементарно, но это реализуемо однозначно...   

 

Это приводит к тому' date=' что о такой пробке система получает информацию только от пользователей, нажавших Да в окне запроса, т.к. реально измерить скорость движения по ребру нечем (поскольку нет факта выезда с этого ребра, а скорость с GPS недостоверна). Соответственно и среднюю скорость по одному датчику рассчитать невозможно. [/quote']

 

Понятно, что факт выезда с ребра сразу позволяет посчитать скорость его проезда. Но!  Возьмем длиное ребро, например,  кусок КАД от вантового моста до развязки с Мурманским шоссе длинной в 4 км.   Возникает пробка из-за ремонта в районе развязки, скорость  в пробке 3-4 км/ч,  в эту пробку попадает 1 датчик.. и что получается, что в течении около часа программа будет считать, что пробки нет (или есть небольшая со скоростью упомянутых выше 15 км/ч)? В результате получим, что программа  "привезет" в эту пробку еще несколько датчиков!   Возможно, что длинное ребро стоит разбивать на несколько "виртуальных" коротких ребер, например, длиной по 500 метров...          

[YoGun]

<...>и что получается' date=' что в течении около часа программа будет считать, что пробки нет <...>[/quote']

 

Для этого вопрос и задаётся.

 

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

 

[RomanMak]

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

 

[YoGun]

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

 

 

Именно так сейчас и происходит при ответе Нет или неответе вообще.

 

[RomanMak]

 

Именно так сейчас и происходит при ответе Нет или неответе вообще.

 

Как об этом пользователи должны догадаться?    Ни в печатном рукодстве, ни в pdf-файле я этого не нашел.      Поэтому нажимал "Да", если действительно пробка и "Нет", если обычное для этого места скопление машин перед светофором.  А оказывается надо нажимать "да" практически всегда, если я не остановился для высадки/посадки пассажиров,  залить жижы в омыватель и т.д.  

[Kiros]

Именно так. Если едешь, но стоишь, то всегда "ДА":).

[гидро]

едиснтвенно средняя скорость в 99% случаев будет завышена, но если и она получается меньше неких 15 км-ч, то надо кричать караул и ставить её.. ну по моему мнению конечно.

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

[paul_2001]

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

Если бы я знал об этом заранее, то повернул бы на Пушкин и через 10 минут выскочил бы за поворотом на Колпино. Обидно...

[гидро]

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

заодно в случае длинных рёбер не на каде помогало бы оптимальнее подъезжать к середине ребра.

почему не сделали так наверно тоже коммерческая тайна

[sergeyastakhov]

...а сделать некую максимальную длину ребра и длинные бить

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

 

Ну, не то чтобы тайна.

Просто кол-во рёбер маршрутизации в одной карте - это, увы, пока ахиллесова пята СГ.

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

 

Бум надеятся что в новых версиях это исправят.

[RomanMak]

[

Просто кол-во рёбер маршрутизации в одной карте - это, увы, пока ахиллесова пята СГ.

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

 

Бум надеятся что в новых версиях это исправят.

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

[sergeyastakhov]

Достаточно' date=' чтобы программа разбивала длинное ребро, по которому едешь в данный момент, а для этого карту менять не надо.  [/quote']

 

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

 

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

[RomanMak]

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

[Danny98]

Давайте попробуем подумать все-таки о том' date=' что в таком месте происходит. Это понять не очень сложно при наличии небольшого желания.

При попадании в пробку (то есть при движении с очень малой скоростью или при полной остановке) на очень длинном ребре крайне вероятны ситуации, когда:

- улетит с дороги GPS

- GPS начнет "плясать" и поедет, в т.ч., в другую сторону

- факта выезда с ребра не будет в обозримом времени (по крайней мере, это время превысит время жизни отметки).

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

[/quote']

Так именно поэтому в мертвых длинных пробках очень часто пропадают ребра вобще на всем протяжении?

[huser]

Так именно поэтому в мертвых длинных пробках очень часто пропадают ребра вобще на всем протяжении?

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

[iys__]

Я так понимаю внутреннюю логику этого решения с 15 км/ч

Пусть мы имеем длинное ребро (4 км), на котором машины едут со скоростью 3 км/ч.

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

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

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

Далее, пусть некоторым всё-таки как-то удается проехать это ребро за 1 час 20 минут без "плясок" GPS и передать на сервер качественный трек. Вопрос, что с ним делать, если время жизни пробки почти в три раза меньше?

Отбросить как недостоверный? Логично, но всё-таки плохо - ведь на указанном ребре вшитая в карту скорость высокая (110 км/ч), и оставлять её такой высокой - значит, существенно исказить картину движения в городе. Значит, надо как-то это ребро пометить. Вот разработчики и приняли решение поставить там какое-то промежуточное значение (между вшитым в карту и реальным).

Спасибо, что об этом сказали.

Надеюсь, на новой вышедшей карте СПб эти длинные ребра разбиты на несколько коротких, и проблема снята.

[sergeyastakhov]

Надеюсь' date=' на новой вышедшей карте СПб эти длинные ребра разбиты на несколько коротких, и проблема снята.[/quote']

 

Ребро от Вантового до Мурманки побилось из-за дорисовки новых примыкающих дорожек. На других всё осталось по прежнему. Да и не вылечить это одной лишь правкой карты - тут надо алгоритмы дорабатывать.

[гидро]

почему не вылечить?

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

[sergeyastakhov]

почему не вылечить?

 

Ну я же выше про это писал: http://forum.probki.net/forum_posts.asp?TID=6122&PID=65034#65034

[гидро]

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

[urix]

Кстати - насчет телефона пробочного оператора на сайте.

Это всё замечательно. Но знать об этом мы не знали, и не узнаем.

Может всё-таки встроить его в программу? Во всплывающем окошке предоставить эту информацию - мол позвоните туда-то.

И в меню сделать пункт "Позвонить оператору", чтоб не запоминать номер.

[dirty]

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