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