Hind, можно, надо вытащить оттуда DistanceToSegment
Ну вот: http://amdmi3.ru/files/speeds
Сделано по кускам Ярословки (на выезде из Москвы), МКАД (в Лосином острове) и Ленинградке (Мокшево-Новомелково).
в pieces считалось одна точка = один замер, в track-avg - один trkseg = один замер.
AMDmi3, по y - скорость, а что по x?
По х - функция вероятности
по x ничего, это просто отсортированные отсчеты
+лужнецкая набережная, +новый арбат.
Не, ребят, нельзя из этого одно число вытащить, вообще никак. Скорости равновероятны в широких диапазонах, “полок” нет, средняя температура по больнице - ересь, максимум - ну, положим, можно, только что он даст, если транспорт движется на этой скорости не более 10% времени, а 10% можно при желании и быстрее поехать.
to liosha
чёт у меня на локальные треки ругается… трек сгенерированный гармин ХТ мобайл
C:\TilesAtHome\osm-speed-read-only>perl speed.pl 44523757 --gpx 091225.gpx
Downloading way 44523757
Ok
4 segments
bbox: 44.5424458788406,48.5072843,44.5483504211594,48.5088342
Downloading OSM tracks
GPX page 0: 225 points
Loading file 091225.gpx
Not an ARRAY reference at speed.pl line 123.
Очередная “фишка” Geometry::Planar.
Исправил, теперь 14.9
Ругань на пустые треки тоже исправил.
AMDmi3, вытащить из этого нужно прогноз скорости (при отсутствии других факторов).
Лучшим прогнозом будет всё-таки мат. ожидание, даже несмотря на то, что распределение не самое нормальное.
Это не прогноз, это средняя температура по больнице с нулевой ценностью, и как-то ее пытаться использовать - значит обманывать себя и пользователей. Я предлагаю в базу вносить фактические и проверяемые значения, а прогноз скорости в зависимости от времени суток/дня недели/времени года оставить пробочникам.
AMDmi3, предложи прогноз получше.
А насчёт ценности - любой прогноз лучше его отсутствия.
В качестве любого прогноза предлагаю maxspeed:practical
Ilis, не катит, потому что слишком мало факторов учитываются
Не стоит забывать, что мы скорее всего вносим ошибки, так что далеко не факт.
Я бы подошел к проблеме более системно чем просто посчитать МО.
Во-первых, я правильно понимаю, что сейчас ожидаемая скорость на ребре берется фиксированная от типа highway или что-то в таком роде, т.е. М.О. при отсутствии ошибок все-таки будет в среднем лучше?
Во-вторых, для каких конверторов мы это делаем? Они умеют только циферку на ребро или что-то сложнее типа хотя бы циферка утром/днем/вечером/ночью?
В-третьих, надо проанализировать данные - как скорость изменяется в течение суток и недели, какой она была год назад, и как она меняется в среднем внутри одного трека.
В-четвертых, нужен способ оценки качества того, что получится. Нужны реальные данные по скорости на какой-то момент времени от какого-нибудь пробкосервиса.
В-пятых, качать треки кусочками не дело, нужны все точки Москвы (ну либо другого города где есть другая информация).
Аргументируйте пожалуйста
ага. highway и maxspeed.
И м.о. (в качестве прогноза) будет лучше.
Большинство доступных навигаторов умеют только одну циферку.
Я был бы очень рад получить доступ к такой статистике
Хм… Первая глава любого текста про прогнозирование.
UPD
Как вариант: http://www.bull-n-bear.ru/risk_in/?risk_in=risk_in5
Ilis, не катит, потому что слишком мало факторов учитываются
В силу своей субъективности там учитываются вообще все факторы
Но если должно учитываться много объективных факторов, тогда надо чтобы все они не противоречили отсутствию значений этих факторов на других рёбрах.
Если мы проезжаем по одной из параллельных дорог в пробке со скоростью 20 км/ч, и назначаем эту скорость этой дороге, то каким образом можно учесть тот факт, что на соседних дорогах в это же время будет точно такая же скорость? Ведь дефолтная там 60.
С подсчётом МО могу ещё предположить артефакты такого типа, как постоянная езда одним человеком на работу и с работы в час пик по одной и той же дороге, и регулярным выкладыванием этих треков. Дорога, к примеру, не особо транзитная, поэтому там будет сто медленных треков и пара случайных быстрых.