Comments 31
Пешеход с 15 кмч это конечно круто :-)
Помню, как года два назад ехал на велосипеде с включенными яндекс-картами, так они в 2 часа ночи на абсолютно пустой улице нарисовали пробку. Но, видимо, с тех пор много поменялось.
Ничего не изменилось на примере Самары. Пробки ночью, когда дороги пустые. Это то же часть алгоритма, что нафига что-то «считать», если «там» всегда пробка или затруднения, значит надо всегда это и показывать.
В Самаре качество Я.пробок плохое. Пользуюсь только глядя на то, есть ли ДТП впереди, значит пробка действительно есть, значит объехать, либо, если нельзя объехать смотрю в каком ряду, чтобы держаться нужного.
В Самаре качество Я.пробок плохое. Пользуюсь только глядя на то, есть ли ДТП впереди, значит пробка действительно есть, значит объехать, либо, если нельзя объехать смотрю в каком ряду, чтобы держаться нужного.
И ни слова про фильтр Калмана (или его у вас там нет О_о) !;)
Что-то у меня видео в HQ глючить начинает, если его перематывать начать.
Скажите, а насколько адекватно сейчас считается время которое сервис говорит будет затрачено на добирательство из пункта A в B? Просто у меня складывается ощущение, что там разброс реальности от прогноза чудовищный, если пробок много.
Что-то у меня видео в HQ глючить начинает, если его перематывать начать.
Скажите, а насколько адекватно сейчас считается время которое сервис говорит будет затрачено на добирательство из пункта A в B? Просто у меня складывается ощущение, что там разброс реальности от прогноза чудовищный, если пробок много.
Аналогичная ситуация с HD.
И ни слова про фильтр Калмана (или его у вас там нет О_о) !;)
Фильтр Калмана встроен во все gps'ки. Они выдают уже сглаженный результат. Если вы посмотрите на GPS треки, то точки в них не будут хаотично прыгать. Кроме того, сами погрешности GPS носят не совсем случайный характер: они зависят от того, какие спутники принимает устройство и от состояния ионосферы на пути сигнала. Эти параметры не меняются мгновенно.
Так что нет, фильтр Калмана не используется. Его пробовали добавлять, но качество результата не возрасло.
В GPS при прогнозе используется линейная модель движения. Вы же можете использовать реальную модель дороги, что значительно поднимет точность использования Калмана. Приведу пример: однажды я делал систему, которая должна была кушать GPS-датчик низкоорбитального спутника и выдавать отфильтрованное положение. Судя по оценке сигма, которую давал GPS равнялась где-то 20 метрам. Если в таком алгоритме использовать линейную модель движения, то меньше пол метра-метр сигма не схлопывалась. Но если использовать априорную информацию по траектории и прогнозировать её даже неточным алгоритмом (который даёт ошибки в 500 метров за виток), то достаточно быстро ошибка уходила на уровень 1-2 сантиметров.
Может есть какая-то более глубокая специфика, почему он не работает. Но «Фильтр Калмана встроен во все gps'ки. Они выдают уже сглаженный результат.» не должно влиять на результат, если вы используете более точный прогноз движения.
«Эти параметры не меняются мгновенно.» — если параметры не меняются мгновенно, то по моему опыту фильтр Калмана должен работать. Вот если они быстро меняются — это хуже.
Может есть какая-то более глубокая специфика, почему он не работает. Но «Фильтр Калмана встроен во все gps'ки. Они выдают уже сглаженный результат.» не должно влиять на результат, если вы используете более точный прогноз движения.
«Эти параметры не меняются мгновенно.» — если параметры не меняются мгновенно, то по моему опыту фильтр Калмана должен работать. Вот если они быстро меняются — это хуже.
Спасибо за замечание, оно очень интересное. Пробовали и линейный фильтр Калмана и с моделью дороги: скармливали в фильтр вектор ошибки привязки на очередном шаге.
Я думаю, что качество не увеличилось потому, что используемый алгоритм привязки точек к дорожному графу и так справлялся с ошибками, которые мог скорректировать фильтр. Этот алгоритм значительно более изощренный, чем привязка к ближайшему ребру с нужным направлением.
Я думаю, что качество не увеличилось потому, что используемый алгоритм привязки точек к дорожному графу и так справлялся с ошибками, которые мог скорректировать фильтр. Этот алгоритм значительно более изощренный, чем привязка к ближайшему ребру с нужным направлением.
У Хокинга в книге по физике одна формула, у вас пост о статистике и ни одной. Соревнуетесь с мэтром? Намеренно упрощаете?
Малый шад, 9-11 класс, уже должны осилить и формулы, и алгоритмы.
Малый шад, 9-11 класс, уже должны осилить и формулы, и алгоритмы.
Последнее время навигатор при наличии двух маршрутов предлагает ехать по более длительному и более длинному, к тому же это платная дорога, начинаю подозревать в аффилированности кое кого. Причем при выборе короткого маршрута, навигатор норовит его перестроить обратно на платку. К сожалению уже потер скриншот, но можно и снова снять в ближайшее время.
А стоит ждать когда-нибудь разделения пробок по полосам? Точнее, по направлениям — например, те, кому сворачивать — стоят в пробке длиной квартала в три, а те, кому прямо — пролетают мимо «со свистом». При этом Я.Пробки считают, похоже, просто среднюю скорость, и навигатор строит маршрут с поворотом ровно по этому месту.
Пример: СПб, Синопская набережная в направлении к Смольной — регулярно полоса-две стоят на поворот на Большеохтинский мост.
Раз уж вы всё равно анализируете точки ДО и ПОСЛЕ и строите варианты маршрута — можно было бы и разделять проезжающих в разных направлениях.
Ещё вопрос: у меня подозрение, что при построении маршрутов есть некая прибавка «на светофоры», и если ехать по маршруту со светофорами, то время проезда примерно верное, а если ехать по главной дороге без светофоров, то приезжаешь стабильно раньше прогноза. Я прав, есть такая поправка?
Пример: СПб, Синопская набережная в направлении к Смольной — регулярно полоса-две стоят на поворот на Большеохтинский мост.
Раз уж вы всё равно анализируете точки ДО и ПОСЛЕ и строите варианты маршрута — можно было бы и разделять проезжающих в разных направлениях.
Ещё вопрос: у меня подозрение, что при построении маршрутов есть некая прибавка «на светофоры», и если ехать по маршруту со светофорами, то время проезда примерно верное, а если ехать по главной дороге без светофоров, то приезжаешь стабильно раньше прогноза. Я прав, есть такая поправка?
Пользуйтесь Ситигайдом. Там пробки по полосам уже несколько лет как реализовано. Называется эта технология «векторные пробки». Можно пройтись поиском по их форуму probki.net
Действительно, Яндекс.Пробки и маршрутизатор используют среднюю скорость для всех полос.
С поворачивающими есть ряд проблем:
1) Время на съезде может быть очень нестабильным из-за «хитрых» водителей, поворачивающих не с той полосы. В итоге входные данные очень шумные.
2) В общем случае не очевидно, в каком месте начинается разделение потоков. Если на съезде действительно собралась длинная очередь, то может начаться за сотни метров до поворота.
3) Считая отдельно поворачивающих и едущих прямо мы уменьшаем себе объём данных по каждому направлению, как итог получаем более шумное значение скорости и медленную реакцию на изменение дорожной ситуации.
Таким образом видно, что в лоб, просто расчётом разных скоростей по разным направлениям съезда, задача качественно не решается: более того при таком подходе качество может даже ухудшится (см. пункт 3). В общем, совсем непростая эта задача, но может когда-нибудь и она будет решена Яндексом.
С поворачивающими есть ряд проблем:
1) Время на съезде может быть очень нестабильным из-за «хитрых» водителей, поворачивающих не с той полосы. В итоге входные данные очень шумные.
2) В общем случае не очевидно, в каком месте начинается разделение потоков. Если на съезде действительно собралась длинная очередь, то может начаться за сотни метров до поворота.
3) Считая отдельно поворачивающих и едущих прямо мы уменьшаем себе объём данных по каждому направлению, как итог получаем более шумное значение скорости и медленную реакцию на изменение дорожной ситуации.
Таким образом видно, что в лоб, просто расчётом разных скоростей по разным направлениям съезда, задача качественно не решается: более того при таком подходе качество может даже ухудшится (см. пункт 3). В общем, совсем непростая эта задача, но может когда-нибудь и она будет решена Яндексом.
Есть еще один момент. Мы не просто анализируем точки ДО и ПОСЛЕ, но еще и делаем это в мягком реальном времени. Ждать несколько минут, пока машина проедет поворот, чтобы определить, свернула ли она, нельзя. Теоретически задача решаема: заметив два кластера скоростей на одном ребре графа можно поискать приоритетные направления, куда поворачивают машины с такой скоростью, после чего соотносить новые сигналы с тем или иным маршрутом в зависимости от их скорости. А практически, это сложный алгоритм, да еще и с положительной обратной связью. Он будет давать нестабильные результаты.
1) А на скорость «на прямой» эти хитрые водители, шпарящие по автобусным полосам, конечно, не влияют?
2) Ну в навигаторе же есть текущий маршрут. Можно же пользоваться этой инфой? Мне кажется, чаще всего водитель поворачивает именно по маршруту…
3) Ну да, это понятно, но неужели поделить на 2-3 так уж фатально? И потом, можно же не разделять потоки полностью, а просто дополнить граф информацией о времени проезда не только ребер, но и вершин между ними?
А вообще, конечно, все это (и коммент kibergus тоже) сильно смахивает на отговорки.
Да, понятно, что задача трудная, тяжело вписывающаяся в существующую концепцию, но от того не менее важная.
Я тоже надеюсь, что Яндекс сделает в этом направлении хоть что-то. Это будет точно лучше, чем просто оставить все как есть под благовидным предлогом.
2) Ну в навигаторе же есть текущий маршрут. Можно же пользоваться этой инфой? Мне кажется, чаще всего водитель поворачивает именно по маршруту…
3) Ну да, это понятно, но неужели поделить на 2-3 так уж фатально? И потом, можно же не разделять потоки полностью, а просто дополнить граф информацией о времени проезда не только ребер, но и вершин между ними?
А вообще, конечно, все это (и коммент kibergus тоже) сильно смахивает на отговорки.
Да, понятно, что задача трудная, тяжело вписывающаяся в существующую концепцию, но от того не менее важная.
Я тоже надеюсь, что Яндекс сделает в этом направлении хоть что-то. Это будет точно лучше, чем просто оставить все как есть под благовидным предлогом.
А когда вы начнёте пользоваться акселерометром и гироскопом в смартфонах? Сможете повысить точность определения координат.
Яндекс, дорогой, ну как тебе не стыдно писать статьи на Хабре про учет статистики в пробках, если ты банально не можешь просчитать маршрут и пункта А в пункт Б на определенный день в определенное время. Я вот прямо сейчас не могу просчитать маршрут в Шереметьево на завтра в 7 утра — брать мне Аэроэкспресс или такси, панимаишь?
А что вам мешает просчитать маршрут на завтра в 7 утра? В пробках есть режим статистики — выбираете там «понедельник, 7 утра», и считаете.
Вообще-то статья немного про другое ;-)
Но маршрут с учётом пробок на определённый действительно построить нельзя. Но посмотреть типичную ситуацию и её развитие вполне можно: maps.yandex.ru/-/CVfiYSLz (Пробки — Прогноз — Выбираете день недели и время).
В Шереметьево в 7 утра по Москве проедите отлично, а до поворота на Международное шоссе чуть-чуть постоите, а если будете проезжать МКАД уже после 7:30, то постоите побольше.
Но маршрут с учётом пробок на определённый действительно построить нельзя. Но посмотреть типичную ситуацию и её развитие вполне можно: maps.yandex.ru/-/CVfiYSLz (Пробки — Прогноз — Выбираете день недели и время).
В Шереметьево в 7 утра по Москве проедите отлично, а до поворота на Международное шоссе чуть-чуть постоите, а если будете проезжать МКАД уже после 7:30, то постоите побольше.
Вот на чего, а на статистику эта чтука не смотрит.
Не считает среднее время работы светофора, не считает нормальное время совершения поворота(или другого маневра), не смотрит на данные других машин, что ехали этим маршрутом ранее…
Не считает среднее время работы светофора, не считает нормальное время совершения поворота(или другого маневра), не смотрит на данные других машин, что ехали этим маршрутом ранее…
Если едет выделенная полоса, то это не значит, что остальные полосы едут. Когда уже это простое правило будет выполняться в вашем приложении?
Если куча придурков прется по тратуару\выделенной полосе на проспекте Андропова, то не нужно остальных направлять в тоже русло.
Давно уже себе взял за правило, что если Яндекс направляет на Андропова, то нужно срочно разворачиваться и ехать оттуда подальше.
Если куча придурков прется по тратуару\выделенной полосе на проспекте Андропова, то не нужно остальных направлять в тоже русло.
Давно уже себе взял за правило, что если Яндекс направляет на Андропова, то нужно срочно разворачиваться и ехать оттуда подальше.
Выделенные полосы невозможно определить по GPS. Получается под них нужно писать отдельный алгоритм, который бы пробовал понять, что здесь данные нетипично оптимистичные. При этом данные вида «кто-то едет быстро, кто-то медленно», очевидно, будут похожи на много других ситуаций, например, просто хвост пробки или светофор.
Итого, да, проблеме ставим +1, но быстрого решения обещать не можем.
Итого, да, проблеме ставим +1, но быстрого решения обещать не можем.
Почему пешеходов нельзя отличать через акселерометр? По тому же методу как работает куча приложений шагомеров и беговых трекеров.
Можно. Но исторически применяемый нами алгоритм появился раньше массового внедрения акселерометров в смартфоны. И в целом он довольно удачно справляется с задачей. Впрочем, возможно мы добавим и ещё одну степень фильтрации пешеходов, уже на основе акселерометра.
В 5s так вообще motion сопроцессор как раз для этих целей: сам подскажет, идет человек или едет.
Жаль не увидел раньше, но надеюсь прочтете) Товарищи яндексоиды, сделайте пожалуйста «пробки в интернете» — насколько я понимаю, по вечерам 3g интернет плохо ловит из-за скоплений людей читающих фейсбуки в пробках, а не лажовости приема отдельных моделей телефонов. а эти скопления можно отследить и тогда можно будет заранее знать, смогу ли я зачекиниться\уточнить маршрут там где хочется или надо это заранее сделать)
Sign up to leave a comment.
Как статистика помогает делать Яндекс.Пробки лучше