Лёша, запусти speed.pl 27474958
Посмотрим эту самую развязку.
Значит не куда угодно распаковывать надо было 
А куда-нибудь без пробелов в путях…
А под Windows x64 nmake не работает. :\
>> Downloading way 27474958
>> 12 segments
>> bbox: 30.1530358,59.7992803817579,30.158446,59.8027235182421
>> Downloading trackpoints
>> GPX page 0: 5000 points
>> GPX page 1: 3322 points
Average forward speed: 44.102280
Average backward speed: 47.588891
Average total: 45.784321
Интересно, а откуда взялся “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?
Надо ли фильтровать не автомобильные треки?
В голову залез такой алгоритм фильтрации - скачивать трек целиком и смотреть его среднюю скорость на всем протяжении трека, если она ниже какого-то порогового значения (пешеход и велосипед к примеру), то не учитывать этот трек при расчете средней скорости.