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

Покурил скрипт :slight_smile:

  1. Поскольку однозначного мапматчинга треков веям не делается, и сегмент трека считается относящимся к вею, если он лежит к нему достаточно близко, то для двухвейных дорог треки в оба направления будут получать оба вея. Если вей односторонний (oneway=yes), то наверно стоит выдавать об этом предупреждение.

  2. По поводу направления и близости - наверно нужно анализировать сегменты вея отдельно, по одному ?

Близость считается для всех сегментов, а направление только относительно первой точки.

А вообще да, использовать для подсчёта сегменты трека - идея не самая лучшая (зато самая простая) :slight_smile:
По хорошему нужно выделять проходящие по вею цепочки, и подсчитывать уже их.

http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en
Вроде есть и для x64

Кстати: http://wiki.openstreetmap.org/wiki/Average_speed_per_way

В статье тоже больше вопросов, чем ответов.
А Speedcollector совсем игрушка - пользователи руками должны вносить скорость в базу :slight_smile:

Супер! Если еще и привязка по направлению будет к каждому сегменту вея, можно будет уже не только играться.
Второе пожелание - возможность брать данные не только из осм, но и из локальных треков (одного, нескольких или каталога).

Захостил на гугле: http://code.google.com/p/osm-speed/

Добавил поддержку локальных треков. Соответственно ключи:
–gpx - маска файла
–noosm - не подгружать треки из осма

Переделал способ привязки треков к дорогам - теперь проверяются и положение, и направление.
Заодно сделал предупреждение об односторонности дороги.

В принципе, скорости вроде получаются вполне реальные, так что можно использовать :slight_smile:

Респект!

Давайте думать, как мы это будем использовать.

Может тупо зальем все данные в ОСМ, придумав для этого какой-нить новый тэг, типа speed:average?

Надо ли фильтровать не автомобильные треки?

В голову залез такой алгоритм фильтрации - скачивать трек целиком и смотреть его среднюю скорость на всем протяжении трека, если она ниже какого-то порогового значения (пешеход и велосипед к примеру), то не учитывать этот трек при расчете средней скорости.

Soitanen, вряд ли их получится отфильтровать “неадминистративными” методами.
Скорость плохой показатель - во время пробок я нередко пешком иду быстрее автомобильного потока :slight_smile:

Вряд ли трек будет содержать только стояние в пробке, дальше все равно поедешь 50-60 км/ч минимум - значит не пешеход. Как-то так.

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

UPD
Вот, для примера, одна страница ответа: http://gis-lab.info/data/mp/page0.gpx.zip

liosha, ааа, понял. Тогда да, не получится так “отфильтровать”. Все же верится, что автомобильных треков много больше, чем пешеходных.

Максимальную!

  1. Быстро подъехал к пробке, а потом час стоял.
  2. Час стоял в пробке, а потом быстро поехал.

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

Давайте лучше не будем ничего расставлять автоматически по трекам - это очень чревато. Мне вообще не нравятся эти последние веяния - на основании каких-то эвристик надобавлять каких-то циферок, и думать что это как-то улучшит роутинг. Если добавляете, то только в говорящие тэги, а-ля traces_speed:average, traces_speed:maximal, traces_speed:median - тогда с можно будет экспериментировать, но никто не должен их путать с maxspeed и maxspeed:practical и другими тэгами, которые может достаточно точно заполнить человек, который там регулярно ездит, и которые он не будет заполнять, если понимает что тэг не отражает действительность.

А может действительно нужно считать не среднюю скорость, а, как говорилось в другой теме, 80% перцентиль? Это возможно посчитать данным скриптом (понятно, что переделав его) и попробовать сравнить результаты?

Вот не понимаю, зачем считать перцентиль, когда лучший прогноз даёт именно м.о.

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