Интересно, а откуда взялся “backward speed” ? Этот съезд всю жизнь (ему 2 года недавно исполнилось) был односторонним, треки в JOSM вроде только в одном направлении…
А как в Josm посмотреть направление треков?
Я ж говорю: фильтры ещё не настроены 
Скорее всего подцепились треки от основного шоссе, из-за этого скорость завышена.
А backward speed из-за закрученности дороги, сейчас направление нормально определяется только для относительно прямых дорог.
Вот абсолютно прямой односторонний вей: 53762581 - считается в обоих направлениях.
Вей 34254310 выдает деление на ноль.
>> Downloading way 34254310
>> 3 segments
>> bbox: 38.1267569,56.2677333524262,38.1350766,56.2691092475738
>> Downloading trackpoints
>> GPX page 0: 357 points
Illegal division by zero at d:\...\speed.pl line 84.
Но идея мне нравится. дайте мне следующую версию на-поиграться
В настройках отображения GPX-треков можно включить показ стрелочек.
Покурил скрипт
-
Поскольку однозначного мапматчинга треков веям не делается, и сегмент трека считается относящимся к вею, если он лежит к нему достаточно близко, то для двухвейных дорог треки в оба направления будут получать оба вея. Если вей односторонний (oneway=yes), то наверно стоит выдавать об этом предупреждение.
-
По поводу направления и близости - наверно нужно анализировать сегменты вея отдельно, по одному ?
Близость считается для всех сегментов, а направление только относительно первой точки.
А вообще да, использовать для подсчёта сегменты трека - идея не самая лучшая (зато самая простая)
По хорошему нужно выделять проходящие по вею цепочки, и подсчитывать уже их.
http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en
Вроде есть и для x64
В статье тоже больше вопросов, чем ответов.
А Speedcollector совсем игрушка - пользователи руками должны вносить скорость в базу 
Супер! Если еще и привязка по направлению будет к каждому сегменту вея, можно будет уже не только играться.
Второе пожелание - возможность брать данные не только из осм, но и из локальных треков (одного, нескольких или каталога).
Добавил поддержку локальных треков. Соответственно ключи:
–gpx - маска файла
–noosm - не подгружать треки из осма
Переделал способ привязки треков к дорогам - теперь проверяются и положение, и направление.
Заодно сделал предупреждение об односторонности дороги.
В принципе, скорости вроде получаются вполне реальные, так что можно использовать
Респект!
Давайте думать, как мы это будем использовать.
Может тупо зальем все данные в ОСМ, придумав для этого какой-нить новый тэг, типа speed:average?
Надо ли фильтровать не автомобильные треки?
В голову залез такой алгоритм фильтрации - скачивать трек целиком и смотреть его среднюю скорость на всем протяжении трека, если она ниже какого-то порогового значения (пешеход и велосипед к примеру), то не учитывать этот трек при расчете средней скорости.
Soitanen, вряд ли их получится отфильтровать “неадминистративными” методами.
Скорость плохой показатель - во время пробок я нередко пешком иду быстрее автомобильного потока
Вряд ли трек будет содержать только стояние в пробке, дальше все равно поедешь 50-60 км/ч минимум - значит не пешеход. Как-то так.
Soitanen, осм выдаёт не треки целиком, а только куски из запрошенной области
UPD
Вот, для примера, одна страница ответа: http://gis-lab.info/data/mp/page0.gpx.zip
liosha, ааа, понял. Тогда да, не получится так “отфильтровать”. Все же верится, что автомобильных треков много больше, чем пешеходных.