Это не прогноз, это средняя температура по больнице с нулевой ценностью, и как-то ее пытаться использовать - значит обманывать себя и пользователей. Я предлагаю в базу вносить фактические и проверяемые значения, а прогноз скорости в зависимости от времени суток/дня недели/времени года оставить пробочникам.
Не стоит забывать, что мы скорее всего вносим ошибки, так что далеко не факт.
Я бы подошел к проблеме более системно чем просто посчитать МО.
Во-первых, я правильно понимаю, что сейчас ожидаемая скорость на ребре берется фиксированная от типа highway или что-то в таком роде, т.е. М.О. при отсутствии ошибок все-таки будет в среднем лучше?
Во-вторых, для каких конверторов мы это делаем? Они умеют только циферку на ребро или что-то сложнее типа хотя бы циферка утром/днем/вечером/ночью?
В-третьих, надо проанализировать данные - как скорость изменяется в течение суток и недели, какой она была год назад, и как она меняется в среднем внутри одного трека.
В-четвертых, нужен способ оценки качества того, что получится. Нужны реальные данные по скорости на какой-то момент времени от какого-нибудь пробкосервиса.
В-пятых, качать треки кусочками не дело, нужны все точки Москвы (ну либо другого города где есть другая информация).
В силу своей субъективности там учитываются вообще все факторы
Но если должно учитываться много объективных факторов, тогда надо чтобы все они не противоречили отсутствию значений этих факторов на других рёбрах.
Если мы проезжаем по одной из параллельных дорог в пробке со скоростью 20 км/ч, и назначаем эту скорость этой дороге, то каким образом можно учесть тот факт, что на соседних дорогах в это же время будет точно такая же скорость? Ведь дефолтная там 60.
С подсчётом МО могу ещё предположить артефакты такого типа, как постоянная езда одним человеком на работу и с работы в час пик по одной и той же дороге, и регулярным выкладыванием этих треков. Дорога, к примеру, не особо транзитная, поэтому там будет сто медленных треков и пара случайных быстрых.
Ну это должно решиться грамотным выбором точек, чтобы параллельную дорогу не зацеплять.
Вот-вот, меня это и беспокоит - выборка у нас хреновая. А вне шоссе еще и нерепрезентативная. Это не считая упомянутых велотреков, общественного транспорта (кстати, а напомните все-таки, общественный транспорт в москве заливали?).
Кроме всего этого есть еще светофоры-лежачие полицейские, которые надо тогда то-ли не учитывать в навигаторе, то-ли как-то выкидывать из треков.
Софтом я готов заняться, это интересная тема. Надо подумать как достать все треки по Москве и можно ли достать какой-нибудь старый снапшот ожидаемых скоростей от пробочного сервиса.
Эээ, я совсем не про это… Для одной из дорог, на которой будут треки, будет известно и матожидание, и дивергенция, и медиана и все остальные статистические параметры, и пусть даже с максимально возможной точностью при наилучшем методе подсчёта. А на соседней дороге не будет треков вообще, поэтому не будет никакой статистики. При этом мы догадываемся, что пробки возникают на этих двух дорогах одновременно и пропадают одновременно. Какие дефолтные значения мы должны присвоить обоим дорогам?
Вот это весьма и весьма сложно. Неизвестно, насколько близка должна быть параллельная дорога для образования пробки, многое зависит от конфигурации перекрестков и наличия съездов с нее. Хотя, если пробки возникают на обеих дорогах, весьма вероятно что треки есть на обеих.
Да пробки во всём городе возникают одновременно Ну пусть на обеих есть треки, а на третьей, довольно кривой дороге, куда никто не сунется, нет треков. И имеем одну основную дорогу с МО=20, параллельную, менее удобную, но более размытую по трекам с МО=25, и третью, в полтора раза длиннее, но вообще без МО, с дефолтной скоростью 50.