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

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-базу, грузить в неё треки, и переделывать скрипт для работы с такой базой.

Ezhick · 2010-09-20T11:36:53.000Z

Ты имеешь в виду аналогичную осмовской или есть вариант конвертить треки как-то еще? Просто попытка поднять на зеркале апи молотилку треков у меня успехом не увенчалась.

glebius · 2010-09-29T13:49:58.000Z

ИМХО, целевые данные для этой программы не в городах, а всякие третьестепенные дороги в областях отличных от Московской. Там нет пробок, но качество дорожного покрытия ограничивает скорость. Благодаря gpslib у нас есть куча данных на эти дороги.

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

wowik · 2010-09-30T12:27:20.000Z

glebius:

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

Еще бывает плохая видимость из-за времени суток и рандомная плохая погода и плохое время года (дорогу не чистят от снега)

liosha · 2010-09-30T12:43:56.000Z

Ezhick:

Ты имеешь в виду аналогичную осмовской или есть вариант конвертить треки как-то еще? Просто попытка поднять на зеркале апи молотилку треков у меня успехом не увенчалась.

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

Только вот дойдут ли руки всерьёз этим заняться - хз…

Ezhick · 2010-09-30T13:53:36.000Z

Леш, если есть понимание куда копать - поделись, я покопаю. Ибо тема мне интересна, мог бы повозиться.

Мне видится что надо парсить gpx, (возможно чистить трек), выбирать последовательные точки с одной скоростью (ну то есть с очень близкой), строить из них linestring, класть его в базу вместе с указанием на скорость на этом отрезке.

liosha · 2010-09-30T14:51:20.000Z

Да пока даже понимания нет - так, мысли просто…
Треки понятно что чистить надо. Linestring имхо не подходит - с ним геморно на совпадения проверять.
Мне кажется надо разбивать треки на сегменты, и хранить эти сегменты в виде центральной точки и курсового угла - так быстрее всего будет сопоставлять.