Супер, посмотрю.
Лёш, почему у меня ppm не видит Math::Geometry::Planar? В чем хитрость?
Он кривой, поэтому его надо ставить руками.
Взять отсюда:
http://search.cpan.org/CPAN/authors/id/E/EW/EWILHELM/Math-Geometry-Planar-Offset-1.05.tar.gz
http://search.cpan.org/CPAN/authors/id/D/DV/DVDPOL/Math-Geometry-Planar-1.17.tar.gz
Распаковать, запустить по-очереди Makefile.pl, nmake, nmake install.
А куда распаковать, или куда угодно?
Куда угодно
Этот ваш перл - мировое зло:
NMAKE : fatal error U1073: don't know how to make 'C:\Program'
Stop.
Лёша, запусти 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 совсем игрушка - пользователи руками должны вносить скорость в базу