Завышен относительно чего? Матожидания? Ну и что?
Он лучше по двум причинам. Он будет сравним с дефолтными скоростями на дорогах, по которым нет статистики, и он не будет давать долговременный прогноз на основе частоизменяющихся данных, т. е. будет более стабильным.
Ilis, ещё раз: интересует ПРОГНОЗ.
Не долговременный, и не сравнимый с дефолтными скоростями, а реалистичный.
Твой прогноз - завышен, поэтому не подходит.
liosha, ну ты знаешь почему он лучше (или хуже). 
Лучше или хуже всегда бывает только в определенном смысле.
Для одного лучше осторожный прогноз, а для другого - оптимистичный.
Для первого нужна оценка снизу, а для второго оценка сверху.
70-80% квантиль тоже нужен, он показывает насколько данная дорога в принципе проезжаема (по состоянию покрытия, искусственным неровностям). Стратегия азартного игрока, так сказать.
Zkir, к сожалению, “для кого” - тоже параметр неопределённый 
А навигаторы хотят одно конкретное число, а не кучу разных оценок.
Ещё раз, мой прогноз сравним с прогнозам по тем дорогам, по которым нет статистики. Потому что в подавляющем большинстве случаев по дорогам ездят с максимальной, а не средней скоростью.
Прогноз, основанный на МО, может для кого-то и более подходит, но тогда прогноз, основанный на дефолтных скоростях по дорогам без статистики – завышен относительно прогноза по МО.
Ну как раз это-то несложно выровнять 
Когда будут известны средние скорости, запросто можно подсчитать их зависимость от тегов.
Вот в этом-то вся и загвоздка!
На одних дорогах будет число, полученное одним методом, на других – другим. И надо чтобы эти методы как-то коррелировали.
Например, если у нас есть 5 % дорог со статистикой в каком-то городе, по идее надо остальные дороги как-то пересчитать в этом же городе. Например, если МО в 2 раза ниже скорости по классу дороги, то на остальных дорогах надо тоже дефолтные скорости поделить на два (ну или на какой-то коэффициент в зависимости от класса)
Треки - это понятно, но треки надо из ОСМ доставать. Думаю там можно договориться о выгрузке. Другое дело - нужны реальные данные о скорости движения, насколько я понимаю у пробочных сервисов они должны быть. С ними можно юудет сравнить то что было, и то, что мы посчитаем по трекам - так можно понять насколько лучше/хуже стало и насколько то что получилось соответствует реальности в разное время сутор/недели.
Это все равно старые треки. Я надеюсь все что есть у ситигида залито, и с таймстэмпами. Хотя, насколько я знаю, в OSM есть ограничение на число точек в одном месте, может там действительно не всё.
Да.
Хм. Возможно, туда часто попадает один трек ‘туда и обратно’. В любом случае, я бы считал только по точкам, с аггрегацией за несколько десятков секунд. По трекам можно считать максимальную/среднюю скорость только чтобы выкинуть велосипедистов/пешеходов и прочее, что портит статистику.
Кстати, насчет целевой аудитории - можно, на самом деле, для разного времени дня выкладывать карты. Если навигатор умеет только одну цифру, больше мы ничего не сможем сделать.
Еще мысль - по-моему, надо действительно ориентироваться на максимальную скорость. Пробки, все-таки, отдельная сущность, и с большой вероятностью человек, зная, где ожидать пробки/посмотрев Яндекс.пробки или послушав радио, там просто не поедет. Учитывая это, роутинг лучше иметь по скорости при свободном движении. Это действительно будет однозначный maxspeed:practical.
Да? Ситигид ввел статистику только что, больше ни у кого из коммерческих операторов статистики нет. Остается один Покетгис с большой статистикой. Как вы думаете, Покетгису интересно отдать эту статистику конкурентам?
Я грешным делом думал у вас realtime информация есть. Хватило бы нескольких снапшотов - утром, вечером и днем вне часа пик.
Конкуренты, блин… Конкурировали бы алгоритмами, а треками делились со всеми. Качество бы у всех повысилось, и конкуренция бы никуда не делась.
Чтобы делиться треками, нужно с пользователями заключить соответствующее соглашение. Пока что встречаются только соглашения о конфиденциальности и нераспространении информации далее пробочного оператора.
Добавил в скрипт определение квантиля: http://files.mail.ru/4K328Z
Вес сегмента трека используется ровно тот же, что и при расчете МО - длина и давность сегмента.
Поведение вполне ожидаемое - на “пробочных” участках МО и 80% квантиль могут отличаться раза в полтора-два, на трассах - в пределах 10-20%. Имхо, скорость по 80-90% квантилю вполне может использоваться в качестве maxspeed:practical.
Надо сказать, что можно использовать и avgspeed, т.к. использование длины сегмента в качестве веса заметно снижает вклад “стоячих пробок” и коротких остановок, но “ползучие” пробки, пешие и велотреки не отсеивает.
Наверное, хотелось бы в конвертере увидеть настраиваемые порядок использования и коэффициенты пересчета скоростей при конвертации (maxspeed: 0.9, maxspeed:practical: 0.95, avgspeed: 1.0), чтобы можно было выбирать между “оптимистичными” и средними скоростями - ведь в каждом навигаторе свои “тараканы”.
Что-то тема заглохла. По-поводу снижения дефолтной для всего города скорости: можно, например, делать maxspeed:practical только, если она окажется выше, чем дефолтная. Тогда исчезнут проблемы с тем, что по левой улице нет треков и у нее скорость будет 50, а вот на соседней все прокатились, там 45, в итоге навигатор едет по мелкой соседней улице.
А вообще, было бы здорово организовать сервер, которые регулярно загружал бы треки с ОСМ, а затем 1 раз в неделю делал пересчет maxspeed:practical для… (России? Региона? Города-экспериментатора?). Тогда все проблемы сошли бы на нет, т.к. даже по улицам без треков народ бы прокатился, в виду того, что туда повел навигатор. Но это мечты… 
Ну собственно ничего сложного в этом нет, вопрос только в том, что выкачивать каждую неделю тучу треков с ОСМа - тяжко и неудобно, куда проще было бы хранить их на этом самом сервере. Если есть желающие поделиться (и регулярно делиться) осмысленным количеством треков по какому-то куску Москвы (для меня оптимально СЗАО-ЗАО, благо я туда смогу влить и вливать свои треки), то я готов попробовать сделать такую статистику и заливать ее в осм с неким уникальным тэгом, который в случае если эксперимент провалится, можно будет легко вычленить и убить. Можно пробовать и всю Москву, но надо смотреть какая получится нагрузка на сервак. Насколько прожорлив скрипт при работе с локальной коллекцией треков?
Ну… некоторые проблемы есть.
Во-первых, нарезка веев в OSM - “где густо, где пусто”. Где-то улицы/дороги цельные на всем протяжении, где-то разрезаны между перекресткамии. А для использования дорожном графе, имхо, лучше всего бы резать веи именно в узлах графа.
Для длинных цельных междугородных трасс проблемой также является слишком большая область скачивания треков.
Во-вторых, скорость работы зависит от числа сегментов вея. Если генерализовать веи внутри скрипта (можно даже без оглядки на перекрестки, важно только сохранить близость к трекам) или брать дороги из файла с предварительно генерализованными веями, скорость можно повысить. Имхо, генерализация повысила бы и точность расчета (по сути, убрав “джиттер” вея).
Для работы с локальной базой треков этот скрипт вообще не предназначен.
Если за такое браться, нужно поднимать локальную postgis-базу, грузить в неё треки, и переделывать скрипт для работы с такой базой.
Ты имеешь в виду аналогичную осмовской или есть вариант конвертить треки как-то еще? Просто попытка поднять на зеркале апи молотилку треков у меня успехом не увенчалась.
ИМХО, целевые данные для этой программы не в городах, а всякие третьестепенные дороги в областях отличных от Московской. Там нет пробок, но качество дорожного покрытия ограничивает скорость. Благодаря gpslib у нас есть куча данных на эти дороги.
В отличие от пробок, которые рандомны и имеют суточную зависимость, плохое покрытие оно всегда плохое покрытие.
Еще бывает плохая видимость из-за времени суток и рандомная плохая погода и плохое время года (дорогу не чистят от снега)