Эээ, я совсем не про это… Для одной из дорог, на которой будут треки, будет известно и матожидание, и дивергенция, и медиана и все остальные статистические параметры, и пусть даже с максимально возможной точностью при наилучшем методе подсчёта. А на соседней дороге не будет треков вообще, поэтому не будет никакой статистики. При этом мы догадываемся, что пробки возникают на этих двух дорогах одновременно и пропадают одновременно. Какие дефолтные значения мы должны присвоить обоим дорогам?
Вот это весьма и весьма сложно. Неизвестно, насколько близка должна быть параллельная дорога для образования пробки, многое зависит от конфигурации перекрестков и наличия съездов с нее. Хотя, если пробки возникают на обеих дорогах, весьма вероятно что треки есть на обеих.
Да пробки во всём городе возникают одновременно Ну пусть на обеих есть треки, а на третьей, довольно кривой дороге, куда никто не сунется, нет треков. И имеем одну основную дорогу с МО=20, параллельную, менее удобную, но более размытую по трекам с МО=25, и третью, в полтора раза длиннее, но вообще без МО, с дефолтной скоростью 50.
Даже если есть такие дороги, думаю, после того, как навигатор построит по ним, в виду этих 50, треки появятся и ситуация устаканится. По-моему, главное, что здесь надо сделать - это обеспечить непрерывность изменения данных. Средние скорости в тегах должны регулярно обновляться, ведь база треков растет, на дорогах бывают ремонты, сменяются зима и лето. Выборка треков за 4 года способна сгладить многие колебания, как сезонности, так и пробок.
Отсекать имеет смысл только то, что заведомо не совпадает с целевой ситуацией. Всё остальное погасится статистически.
В нашем случае целевая ситуация определена очень слабо: автомобиль. Других параметров вроде как нет.
Попытка учитывать пробки - в этом вся суть и есть. Считается, что пробки возникают в силу систематических причин, и по этому их можно прогнозировать. Если же пробки возникают в силу случайных причин (например исключительно из-за аварий) то прогнозировать их бессмысленно.
Угу, это фундаментальное свойства мат.ожидания. Если эксперементы повторяются, а результаты складываются, то сумма стремится к м.о.*[число экспериментов]
У меня первая мысть такая же была. Но если подумать, источников веса ребра больше нет вообще никаких, кроме взятого с потолка числа а-ля maxspeed для данного типа дороги (highway=*). Вот что (и как) именно брать, на самом деле, большой вопрос, тем более если в итоге ожидается только одно число (хотя на деле в течение суток возникают диаметрально противоположные ситуации).
Я однозначно против использовать что-то по трекам прямо сейчас, но за поэкспериментировать-сравнить-использовать-если-лучше. Что нужно написано выше - реальные данные по скоростям движения как какой-то момент времени, в идеале за неделю. У своих я попросил, посмотрим что ответят. Что скажут товарищи из ПокетГис и Ситигида (Zkir?).
В СГ вроде дозрели до идеи сделать не один скоростной индекс для ребра (зашитый в саму карту), а N, на каждый интервал времени свой. Но до ее реализации нужно дожить.
Если брать одно число, то нужно считать среднее, единственно что видимо нужно делать экспоненциальное сглаживание, чтобы более старые данные входили с меньшим весом. Текущий год - 1, прошлый 0.3, позапрошлый 0.09, попзапозапрошлый - 0.027
Я бы на данном этапе предпочел ориентироваться на базу треков OSM (Запрашивать у МИТ треки Москвы(?) - это целое дело.) Идея проставить ботом avgspeed (и регулярно ее обновлять) кажется мне хорошей идеей.
Чтобы что-то проставлять ботом, база треков нужна локально, причём предобработанная для быстрого сопоставления. Не уверен, что из осма получится вытащить треки на всю Москву.
Кроме того, по хорошему работать надо с рёбрами графа, а не с осмовскими веями.
Я не совсем понял, что именно нужно? Треки? Так наших треков в осм залито дофига и больше, люди двух-трехлетние архивы заливали целиком. Или что-то еще?