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

liosha · 2010-09-10T09:10:54.000Z

Ilis, могу ещё раз повторить, что целевая ситуация не определена.
Единственное, что про неё можно сказать, это что речь идёт про автомобиль. Ни время суток, ни день недели, ни сезон, ни погода, ни мощность двигателя, ни стаж водителя, ни куча других факторов - ничего этого заранее не известно. Но при этом прогноз на скорость нужно дать.

Если ты готов предложить прогноз лучше м/о - давай.

Ilis · 2010-09-10T09:16:32.000Z

liosha:

Ilis, могу ещё раз повторить, что целевая ситуация не определена.
Единственное, что про неё можно сказать, это что речь идёт про автомобиль. Ни время суток, ни день недели, ни сезон, ни погода, ни мощность двигателя, ни стаж водителя, ни куча других факторов - ничего этого заранее не известно. Но при этом прогноз на скорость нужно дать.

Если ты готов предложить прогноз лучше м/о - давай.

Так я уже дал maxspeed:practical

Можно пытаться получить этот же параметр автоматически, из треков. Например, брать в расчёт только равномерные треки, где скорость на интересующем участке в городе строго больше 15 км/ч на любом отрезке трека. Потом выкинуть 20 % самых быстрых треков и взять максимальную скорость из оставшихся.

liosha · 2010-09-10T09:19:40.000Z

Ilis, а теперь объясни, почему этот прогноз лучше, если он заведомо завышен?

Ilis · 2010-09-10T09:23:14.000Z

Завышен относительно чего? Матожидания? Ну и что?

Он лучше по двум причинам. Он будет сравним с дефолтными скоростями на дорогах, по которым нет статистики, и он не будет давать долговременный прогноз на основе частоизменяющихся данных, т. е. будет более стабильным.

liosha · 2010-09-10T09:26:52.000Z

Ilis, ещё раз: интересует ПРОГНОЗ.
Не долговременный, и не сравнимый с дефолтными скоростями, а реалистичный.
Твой прогноз - завышен, поэтому не подходит.

Zkir · 2010-09-10T09:31:25.000Z

liosha, ну ты знаешь почему он лучше (или хуже). Лучше или хуже всегда бывает только в определенном смысле.
Для одного лучше осторожный прогноз, а для другого - оптимистичный.
Для первого нужна оценка снизу, а для второго оценка сверху.

70-80% квантиль тоже нужен, он показывает насколько данная дорога в принципе проезжаема (по состоянию покрытия, искусственным неровностям). Стратегия азартного игрока, так сказать.

liosha · 2010-09-10T09:35:21.000Z

Zkir, к сожалению, “для кого” - тоже параметр неопределённый
А навигаторы хотят одно конкретное число, а не кучу разных оценок.

Ilis · 2010-09-10T09:35:55.000Z

liosha:

Ilis, ещё раз: интересует ПРОГНОЗ.
Не долговременный, и не сравнимый с дефолтными скоростями, а реалистичный.
Твой прогноз - завышен, поэтому не подходит.

Ещё раз, мой прогноз сравним с прогнозам по тем дорогам, по которым нет статистики. Потому что в подавляющем большинстве случаев по дорогам ездят с максимальной, а не средней скоростью.

Прогноз, основанный на МО, может для кого-то и более подходит, но тогда прогноз, основанный на дефолтных скоростях по дорогам без статистики – завышен относительно прогноза по МО.

liosha · 2010-09-10T09:37:34.000Z

Ilis:

Прогноз, основанный на МО, может для кого-то и более подходит, но тогда прогноз, основанный на дефолтных скоростях по дорогам без статистики – завышен относительно прогноза по МО.

Ну как раз это-то несложно выровнять
Когда будут известны средние скорости, запросто можно подсчитать их зависимость от тегов.

Ilis · 2010-09-10T09:39:56.000Z

liosha:

А навигаторы хотят одно конкретное число, а не кучу разных оценок.

Вот в этом-то вся и загвоздка!

На одних дорогах будет число, полученное одним методом, на других – другим. И надо чтобы эти методы как-то коррелировали.

Например, если у нас есть 5 % дорог со статистикой в каком-то городе, по идее надо остальные дороги как-то пересчитать в этом же городе. Например, если МО в 2 раза ниже скорости по классу дороги, то на остальных дорогах надо тоже дефолтные скорости поделить на два (ну или на какой-то коэффициент в зависимости от класса)

AMDmi3 · 2010-09-10T15:42:06.000Z

Ezhick:

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

Треки - это понятно, но треки надо из ОСМ доставать. Думаю там можно договориться о выгрузке. Другое дело - нужны реальные данные о скорости движения, насколько я понимаю у пробочных сервисов они должны быть. С ними можно юудет сравнить то что было, и то, что мы посчитаем по трекам - так можно понять насколько лучше/хуже стало и насколько то что получилось соответствует реальности в разное время сутор/недели.

liosha:

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

Это все равно старые треки. Я надеюсь все что есть у ситигида залито, и с таймстэмпами. Хотя, насколько я знаю, в OSM есть ограничение на число точек в одном месте, может там действительно не всё.

dimuzz:

AMDmi3, максимальное значение по оси X - это суммарное количество точек/треков?

Да.

dimuzz:

Уж очень большая “полка” на околонулевых скоростях (самая большая, пожалуй, на мкад).

Хм. Возможно, туда часто попадает один трек ‘туда и обратно’. В любом случае, я бы считал только по точкам, с аггрегацией за несколько десятков секунд. По трекам можно считать максимальную/среднюю скорость только чтобы выкинуть велосипедистов/пешеходов и прочее, что портит статистику.

Кстати, насчет целевой аудитории - можно, на самом деле, для разного времени дня выкладывать карты. Если навигатор умеет только одну цифру, больше мы ничего не сможем сделать.

Еще мысль - по-моему, надо действительно ориентироваться на максимальную скорость. Пробки, все-таки, отдельная сущность, и с большой вероятностью человек, зная, где ожидать пробки/посмотрев Яндекс.пробки или послушав радио, там просто не поедет. Учитывая это, роутинг лучше иметь по скорости при свободном движении. Это действительно будет однозначный maxspeed:practical.

Ezhick · 2010-09-10T18:54:34.000Z

AMDmi3:

Другое дело - нужны реальные данные о скорости движения, насколько я понимаю у пробочных сервисов они должны быть.

Да? Ситигид ввел статистику только что, больше ни у кого из коммерческих операторов статистики нет. Остается один Покетгис с большой статистикой. Как вы думаете, Покетгису интересно отдать эту статистику конкурентам?

AMDmi3 · 2010-09-10T19:06:59.000Z

Я грешным делом думал у вас realtime информация есть. Хватило бы нескольких снапшотов - утром, вечером и днем вне часа пик.

Ilis · 2010-09-11T06:44:00.000Z

Ezhick:

Как вы думаете, Покетгису интересно отдать эту статистику конкурентам?

Конкуренты, блин… Конкурировали бы алгоритмами, а треками делились со всеми. Качество бы у всех повысилось, и конкуренция бы никуда не делась.

Eugene120 · 2010-09-11T09:29:09.000Z

Чтобы делиться треками, нужно с пользователями заключить соответствующее соглашение. Пока что встречаются только соглашения о конфиденциальности и нераспространении информации далее пробочного оператора.

dimuzz · 2010-09-17T18:22:41.000Z

Добавил в скрипт определение квантиля: http://files.mail.ru/4K328Z
Вес сегмента трека используется ровно тот же, что и при расчете МО - длина и давность сегмента.
Поведение вполне ожидаемое - на “пробочных” участках МО и 80% квантиль могут отличаться раза в полтора-два, на трассах - в пределах 10-20%. Имхо, скорость по 80-90% квантилю вполне может использоваться в качестве maxspeed:practical.
Надо сказать, что можно использовать и avgspeed, т.к. использование длины сегмента в качестве веса заметно снижает вклад “стоячих пробок” и коротких остановок, но “ползучие” пробки, пешие и велотреки не отсеивает.
Наверное, хотелось бы в конвертере увидеть настраиваемые порядок использования и коэффициенты пересчета скоростей при конвертации (maxspeed: 0.9, maxspeed:practical: 0.95, avgspeed: 1.0), чтобы можно было выбирать между “оптимистичными” и средними скоростями - ведь в каждом навигаторе свои “тараканы”.

SenatoR · 2010-09-20T07:00:04.000Z

Что-то тема заглохла. По-поводу снижения дефолтной для всего города скорости: можно, например, делать maxspeed:practical только, если она окажется выше, чем дефолтная. Тогда исчезнут проблемы с тем, что по левой улице нет треков и у нее скорость будет 50, а вот на соседней все прокатились, там 45, в итоге навигатор едет по мелкой соседней улице.

А вообще, было бы здорово организовать сервер, которые регулярно загружал бы треки с ОСМ, а затем 1 раз в неделю делал пересчет maxspeed:practical для… (России? Региона? Города-экспериментатора?). Тогда все проблемы сошли бы на нет, т.к. даже по улицам без треков народ бы прокатился, в виду того, что туда повел навигатор. Но это мечты…

Ezhick · 2010-09-20T08:52:12.000Z

SenatoR:

А вообще, было бы здорово организовать сервер, которые регулярно загружал бы треки с ОСМ, а затем 1 раз в неделю делал пересчет maxspeed:practical для… (России? Региона? Города-экспериментатора?). Тогда все проблемы сошли бы на нет, т.к. даже по улицам без треков народ бы прокатился, в виду того, что туда повел навигатор. Но это мечты…

Ну собственно ничего сложного в этом нет, вопрос только в том, что выкачивать каждую неделю тучу треков с ОСМа - тяжко и неудобно, куда проще было бы хранить их на этом самом сервере. Если есть желающие поделиться (и регулярно делиться) осмысленным количеством треков по какому-то куску Москвы (для меня оптимально СЗАО-ЗАО, благо я туда смогу влить и вливать свои треки), то я готов попробовать сделать такую статистику и заливать ее в осм с неким уникальным тэгом, который в случае если эксперимент провалится, можно будет легко вычленить и убить. Можно пробовать и всю Москву, но надо смотреть какая получится нагрузка на сервак. Насколько прожорлив скрипт при работе с локальной коллекцией треков?

dimuzz · 2010-09-20T10:59:40.000Z

Ну… некоторые проблемы есть.
Во-первых, нарезка веев в OSM - “где густо, где пусто”. Где-то улицы/дороги цельные на всем протяжении, где-то разрезаны между перекресткамии. А для использования дорожном графе, имхо, лучше всего бы резать веи именно в узлах графа.
Для длинных цельных междугородных трасс проблемой также является слишком большая область скачивания треков.
Во-вторых, скорость работы зависит от числа сегментов вея. Если генерализовать веи внутри скрипта (можно даже без оглядки на перекрестки, важно только сохранить близость к трекам) или брать дороги из файла с предварительно генерализованными веями, скорость можно повысить. Имхо, генерализация повысила бы и точность расчета (по сути, убрав “джиттер” вея).

liosha · 2010-09-20T11:12:50.000Z

Для работы с локальной базой треков этот скрипт вообще не предназначен.
Если за такое браться, нужно поднимать локальную postgis-базу, грузить в неё треки, и переделывать скрипт для работы с такой базой.