Выкладываю.
По поводу вычислений - для определения скорости нужно знать пройденное расстояние между точками трека и соответствующее время. Понятно, что в эти периоды двигаемся равномерно и прямолинейно.
Вычисление расстояния - в свое время Саша amk не смог убедить меня в отсутствии погрешности вычисления, связанного с неочевидным вычислением длины дуг некруглой Земли, поэтому я воспользовался формулами древних арабов http://gis-lab.info/qa/great-circles.html.
Это первый способ, для полярных (градусных) координат.
Второй способ - перегнать градусные координаты в прямоугольные генштабовские и воспользоваться теоремами про катеты и гипотенузы. Это делает программа Franson CoordTrans.
При вычислении времени помним, что время в Экселе есть количество (число) каких-то мелких периодов от какого-то давнего события.
В общем, все несложно, если нужно, пишите ТЗ, прогу напишем.
Я тебя убеждал в малости, а не в отсутствии это все равно, как считать, ясно, что делать и так и эдак.
Кстати, а какая погрешность у прибора? Какая погрешность у сглаживания точек?
А при чем тут Эксель? Эксель оставим бухгалтерам... время берем из файла
Написать "прогу" - пустое. Хоть на чём. А вот понять, как усреднять мне было бы интересно.
Цель: внятный график скорости вдоль трека.
Типичная трудность, пример: прямой асфальт, легкие спуски-подъемы. Крутишь, не замечаешь. Однако скорость все равно меняется, на картинке будет видно. Явно должна быть опция, срезающая такое. Или нет?
Последний раз редактировалось amk; 04.06.2015 в 23:13.
Никогда не жалей о том, что сделал, если в этот момент был счастлив…
А какая она, эта малость? Коренево и Ивантеевка (половина дневного перехода) по широте различаются на 20'. Если использовать всю длину параллели (чтобы потом взять ее часть), может, существенным окажется несферичность Земли и скорость у Ивантеевки будет отличатся от скорости у Коренево?
Остальные погрешности систематические, в разностях должны исчезнуть, ИМХО.
Впрочем, оставим рассуждения до рюмки чая.
Если теория усреднения интересна, я ее тебе запрограммирую. В соответствии с твоим ТЗ.
Лёша, я не собираюсь ничего считать точно. Но мне, как математику, очевидно, что погрешности, возникающие при вычислении по приближённым формулам (которых можно избежать), не превосходят других, неизбежных погрешностей.
Запрограммировать я и сам могу. Но хотелось бы понять умом как именно усреднять.
Про скорость у Ивантееевки и скорость у Коренево.
Предположим, что :
1. За 1 единицу времени ты проехал 1 градус вдоль параллели.
2. Ты сделал это дважды, у Ивантеевки и у Коренево.
3. Ивантеевка и Коренево отстоят на 1 градус по широте, обе примерно на 45%
Нормальные предположения?
Тогда относительная погрешность скорости будет [cos(45)-cos(46)]/cos45 ~ 2%
Ошибки усреднения всяко больше!
Ты глянь на Валину картинку. Между 7 и 7.5 (хорошее шоссе до Новосёлово). Явно Валентин ехал плавно и без особенных рывков. А колебания на графике у него - от 16 до 35. Где-то в горку, где-то с неё? Я бы попробовал отфильтровать бегущим окном... только хлопотно... ширину окна подбирать... пики вообще бы посрезал...
Последний раз редактировалось amk; 05.06.2015 в 00:55.
Никогда не жалей о том, что сделал, если в этот момент был счастлив…
Если задача получить внешне ровный красивый график, то мне кажется и усреднять надо операциями над линией, а не данными. Например кривыми Безье, а степень усреднения привязать к масштабу. Скорее всего такое сглаживание уже будет реализовано в библиотеке построения графиков, так что делать вообще ничего не надо..
Только он же информативность будет терять, даже если сохранять площадь под графиком. Например если убрать колебания от 16 до 35, то вместо холмистой местности получится, что Валентин просто неспеша ехал по плоскачу Или вместо перепрыгивания через брёвна каждые 10м - выйдет спокойный матрас в прогулочном темпе.
Если посмотреть как делают другие, страва, garmin connect, ridewithgps итд - они немного упрощают данные, но ровный общий график никогда не делают, он похож на выдаваемый озиком.
А перегруженность графика компенсируется функционалом разбивки трека на сегменты и приближения интересующей части в один клик, с выводом статистики (средняя, время остановок, итд) только по этому участку. Получается некий аналог сглаживания, только без потери информативности и с окном, которое выбирает сам пользователь.
Мне кажется, задача заключается в том, чтобы убрать часть информации, сделав оставшееся читаемым. "Перепрыгивание через бревна" не спрячется, если хоть как-то сохранять среднюю скорость. И холмистая местность тоже.
Да что говорить, гармин сам усредняет много чего (не пишет какие-то точки?), насколько я понимаю.
Никогда не жалей о том, что сделал, если в этот момент был счастлив…
Задачу надо ставить не в заумных терминах ("сглаживание", "кривые Безье"), а простыми понятными словами - определить влияние продолжительности обеда или размера группы на среднюю скорость и количество остановок, определить время появления усталости и т.п.
Средствами Экселя и Ozi API можно разрисовать сам трек, расставив прямо на карте точки, где, например, заметно меняется средняя скорость.
Ну, скажем, одно бревно = 20 сек, общее время движения = 10ч. Как ни рисуй, на такое замедление больше 1 пикселя не получится выделить. Что Озик и выводит.
Можно пойти от обратного - например, нам нужно минимум по 3-5 пикселей на один перепад скорости, чтобы они не слипались вместе. Алгоритм не важен, это требование к результату.
Значит на графике в 1500 пикселей (разрешение 1680*1050 + поля) при движении 10 часов будут терятся любые изменения скорости в пределах от 1 до 2 минут.. А это уже не только потеря брёвен-бордюров, но и оврагов, мостов, локальных участков говен, итд.
Другой вариант - сглаживать всё, но выводить поверх серенького несглаженного графика. Тогда вроде бы и красиво, и на фоне виден характер движения.
Это без проблем делается по существующим серисам типа стравы. Только надо датчик пульса цеплять для определения усталости.
Саш, на самом деле там есть небольшие горки, да и ветер был попутным. Там что кое-где действительно ехали за 30, а кое-где и 16 было.
Вообще про точность и погрешность расчетов согласен с Сашей. Конечно, если соблюдать академичность, то все эти жуткие формулы гаверсинусов и прочее оправдано. Полностью оправдано их использование в нормальном географическом софте или, например, при расчете дальнего артиллерийского огня - Но для обсчета треков велопоходов с экселе заморачиваться со всем - это ИМХО стрельба из пушек по воробьям. Ради интереса сделаю эксперимент - возьму трек длиной 100-200 км и сравню, какую длину насчитает Озик (который, очевидно, считает точно и правильно) и что выйдет при простом сложении длины отрезков между точками, каждый из которых посчитан по теореме Пифагора. Почти уверен, что разница будет минимальной и явно меньше иных погрешностей -.
Про фильтрацию скоростей - вопрос тонкий. Наверное, стоит как-то фильтровать и отсеивать точки, для которых УСКОРЕНИЕ или сама скорость выходят за рамки реальности (такие точки порой возникают из-за глюков прибора). Сглаживать все остальное - это в некоторой степени искажение действительности (причем неочевидно, где начинающееся), поэтому отчасти бессмысленно.
Последний раз редактировалось Valentin Gvozdev; 05.06.2015 в 16:00.
Велотуризм на VGVOZDEV.NAROD.RU || ТЕЛЕФОН 8-916-582-04-17
Поcледние рассказы: Белоруссия-2010 || Север - 2010
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)