Определение скоростей дорог по трекам

AMDmi3, ну дык у своих бы спросил :wink:

UPD.
Кстати, на весенний ИМАТ вроде выкладывали статистику по москве за какой-то один месяц

Эээ, я совсем не про это… Для одной из дорог, на которой будут треки, будет известно и матожидание, и дивергенция, и медиана и все остальные статистические параметры, и пусть даже с максимально возможной точностью при наилучшем методе подсчёта. А на соседней дороге не будет треков вообще, поэтому не будет никакой статистики. При этом мы догадываемся, что пробки возникают на этих двух дорогах одновременно и пропадают одновременно. Какие дефолтные значения мы должны присвоить обоим дорогам?

А, блин жеж, забыл совсем. Надо попробовать.

Что это, где это?

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

Дык ваши же опять :slight_smile:
http://imat2010.yandex.ru/datasets

UPD. Не, там голый граф был, без геопривязки

Да пробки во всём городе возникают одновременно :slight_smile: Ну пусть на обеих есть треки, а на третьей, довольно кривой дороге, куда никто не сунется, нет треков. И имеем одну основную дорогу с МО=20, параллельную, менее удобную, но более размытую по трекам с МО=25, и третью, в полтора раза длиннее, но вообще без МО, с дефолтной скоростью 50.

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

Избавился

Даже если есть такие дороги, думаю, после того, как навигатор построит по ним, в виду этих 50, треки появятся и ситуация устаканится. По-моему, главное, что здесь надо сделать - это обеспечить непрерывность изменения данных. Средние скорости в тегах должны регулярно обновляться, ведь база треков растет, на дорогах бывают ремонты, сменяются зима и лето. Выборка треков за 4 года способна сгладить многие колебания, как сезонности, так и пробок.

Ага, среднего по больнице за 4 года ещё не хватало.

По моему самое плохое во всей этой истории – попытка учитывать пробки. Для долговременных прогнозов использовать быстроизменяющиеся характеристики.

У максимальной скорости такого недостатка практически нет, а пробки должен учитывать (и учитывает же!) пробочный сервис.

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

Набуханный чудень пролетит на ямахе 270 ночью и капец…

Тогда уж надо отсекать по типам дорог минимальную скорость, отсекать превышения, по типу для города не выше 70, и из остатка строить.

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

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

Угу, это фундаментальное свойства мат.ожидания. Если эксперементы повторяются, а результаты складываются, то сумма стремится к м.о.*[число экспериментов]

Спасибо, оперативно. Правда, я уже поставил VS, благо, лицензионная есть, и собрал оффсет. :3

У меня первая мысть такая же была. Но если подумать, источников веса ребра больше нет вообще никаких, кроме взятого с потолка числа а-ля maxspeed для данного типа дороги (highway=*). Вот что (и как) именно брать, на самом деле, большой вопрос, тем более если в итоге ожидается только одно число (хотя на деле в течение суток возникают диаметрально противоположные ситуации).
Я однозначно против использовать что-то по трекам прямо сейчас, но за поэкспериментировать-сравнить-использовать-если-лучше. Что нужно написано выше - реальные данные по скоростям движения как какой-то момент времени, в идеале за неделю. У своих я попросил, посмотрим что ответят. Что скажут товарищи из ПокетГис и Ситигида (Zkir?).

Ну что я могу сказать? :slight_smile:

  1. В СГ вроде дозрели до идеи сделать не один скоростной индекс для ребра (зашитый в саму карту), а N, на каждый интервал времени свой. Но до ее реализации нужно дожить.

  2. Если брать одно число, то нужно считать среднее, единственно что видимо нужно делать экспоненциальное сглаживание, чтобы более старые данные входили с меньшим весом. Текущий год - 1, прошлый 0.3, позапрошлый 0.09, попзапозапрошлый - 0.027

  3. Я бы на данном этапе предпочел ориентироваться на базу треков OSM (Запрашивать у МИТ треки Москвы(?) - это целое дело.) Идея проставить ботом avgspeed (и регулярно ее обновлять) кажется мне хорошей идеей.

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

Коэффициент “давности” сейчас попробую сделать.

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

Ezhick, осм большинство треков отдаёт без таймстемпов

liosha, тогда что нужно? Просто треки?