Поскольку однозначного мапматчинга треков веям не делается, и сегмент трека считается относящимся к вею, если он лежит к нему достаточно близко, то для двухвейных дорог треки в оба направления будут получать оба вея. Если вей односторонний (oneway=yes), то наверно стоит выдавать об этом предупреждение.
По поводу направления и близости - наверно нужно анализировать сегменты вея отдельно, по одному ?
Близость считается для всех сегментов, а направление только относительно первой точки.
А вообще да, использовать для подсчёта сегменты трека - идея не самая лучшая (зато самая простая)
По хорошему нужно выделять проходящие по вею цепочки, и подсчитывать уже их.
Супер! Если еще и привязка по направлению будет к каждому сегменту вея, можно будет уже не только играться.
Второе пожелание - возможность брать данные не только из осм, но и из локальных треков (одного, нескольких или каталога).
В голову залез такой алгоритм фильтрации - скачивать трек целиком и смотреть его среднюю скорость на всем протяжении трека, если она ниже какого-то порогового значения (пешеход и велосипед к примеру), то не учитывать этот трек при расчете средней скорости.
Soitanen, вряд ли их получится отфильтровать “неадминистративными” методами.
Скорость плохой показатель - во время пробок я нередко пешком иду быстрее автомобильного потока
Далеко не везде. С некоторых проездов даже в Москве я собирал по несколько велосипедных треков (для точности), причем до этого там треков не было, не говоря уж о загороде где все только на велосипеде собрано. Алсо, если даже больше автомобильных - то, насколько я помню, были крупные импорты треков от общественного транспорта, а они все-таки далеки от, на что хочется чтобы опирался навигатор. Максимальную скорость выбирать - может быть, но тогда достаточно пары гонщиков, которые когда-то там проехали - и привет, на нарте неверная информация.
Давайте лучше не будем ничего расставлять автоматически по трекам - это очень чревато. Мне вообще не нравятся эти последние веяния - на основании каких-то эвристик надобавлять каких-то циферок, и думать что это как-то улучшит роутинг. Если добавляете, то только в говорящие тэги, а-ля traces_speed:average, traces_speed:maximal, traces_speed:median - тогда с можно будет экспериментировать, но никто не должен их путать с maxspeed и maxspeed:practical и другими тэгами, которые может достаточно точно заполнить человек, который там регулярно ездит, и которые он не будет заполнять, если понимает что тэг не отражает действительность.
А может действительно нужно считать не среднюю скорость, а, как говорилось в другой теме, 80% перцентиль? Это возможно посчитать данным скриптом (понятно, что переделав его) и попробовать сравнить результаты?
Пробовал заставить скрипт считать медиану и перцентиль, правда, пока несколько втупую - используя в качестве выборки все мгновенные отсчеты скорости. Первый результат оказался настолько же туп - при движении с малой скоростью точек генерируется намного больше, поэтому медиана оказывается близкой к минимальным скоростям. Возможно, если в качестве выборки использовать средние скорости каждого трека в отдельности, будет лучше.