Speed and average speed calculations don't take altitude into account

[GoogleCodeExporter]

For high-grade displacements, such as vertical movement, some of our
calculations are incorrect - the average speed is calculated by calling
Location.distanceTo(), which flatters the points to the Earth's surface
using WGS84 (so a purely vertical track would result in zero average speed).

We should also check which devices take altitude into account for
Location.getSpeed(), and possibly use the accelerator sensors for this
instead (or as an addition).

Original issue reported on code.google.com by rdama...@google.com on 11 May 2010 at 3:14

[GoogleCodeExporter]

The good thing about this change is that it would make my bicycle commute look 
a tiny bit faster because it has 
a few short/steep climbs.  But I'm worried that the notorious inaccuracies of 
the elevation measurements from 
GPS would make the speed calculations less reliable unless you find a good way 
of filtering those out. (Without 
flattening legitimate anomalies of course! I'm sure someone will use this for 
parachuting or for their trip to the 
I.S.S. Of course you have all the data to do this intelligently, provided 
people give you the correct activity types :-
) Maybe I'm just arguing that users should be able to opt out of this bug fix.

Original comment by simon.le...@gmail.com on 21 May 2010 at 3:12

[GoogleCodeExporter]

Please don't do this. Speed over the ground is what (almost) everyone wants.  
Even at 38000 ft in a 747. 

Original comment by beards...@gmail.com on 24 Aug 2010 at 8:44

[GoogleCodeExporter]

Is there a way to call the terrain layer to see what the avg height might be 
for a given area or point?

Original comment by christopher.wanko on 25 Aug 2010 at 3:06

[GoogleCodeExporter]

The terrain layer is also just a set of images.

There is a google elevation service though - 
http://code.google.com/apis/maps/documentation/elevation/ - this one should be 
more precise, but it does require a data connection (or post-processing).

Original comment by rdama...@google.com on 25 Aug 2010 at 5:48

[GoogleCodeExporter]

This would be contrary to all other forms of navigation and will be woefully 
inaccurate anyhow. I vote for leaving as-is, or at best making it an opt-in 
option, i.e. off by default.

Original comment by thomas.h...@gmail.com on 14 Sep 2010 at 4:22

[GoogleCodeExporter]

I would argue that most people would expect to see their true speed (distance / 
time) because that's how it's measured in any speedometer in any craft (car, 
bicycle, boat, airplane, ...)  No one would expect to get a speed based on a 
projection of their path to an arbitrary 2D plane aligned with the horizon.  
Even though it usually won't make more than 2% or 3% difference, reporting the 
true speed and true distance (including elevation changes) seems like the 
honest and correct thing to do.

Original comment by dbear...@gmail.com on 20 Sep 2010 at 10:12

[GoogleCodeExporter]

I was hoping to use this while skiing this winter to figure out the speed and 
distance of my runs, so the elevation change is vital to my intended use!

Original comment by cgerst...@gmail.com on 4 Dec 2010 at 3:40

[GoogleCodeExporter]

Agree with above, the only speed recorded by any vehicle is the true speed. The 
one that takes altitude change into account. 
same for distance a car report the true distance not the 2d projected one. And 
for hiking it is much better to know the true distance and speed.
Regards

Original comment by eric.bay...@googlemail.com on 9 Dec 2010 at 12:30

[GoogleCodeExporter]

(just removing OpSys-Android label, all issues are in Android anyway)

Original comment by rdama...@google.com on 26 Jul 2011 at 1:00

• Removed labels: OpSys-Android

[GoogleCodeExporter]

It seems like a good idea to use the google elevation service.  Either use it 
automatic when possible or allow people to choose.  I wouldn't mind opening a 
track and then choosing "update elevation" which will then, for the points 
recorded, get the correct elevation.  Currently the elevation is always off.  
Sometimes too high, sometimes too low.

Original comment by sven.br...@gmail.com on 21 Dec 2011 at 12:50

[GoogleCodeExporter]

I'd argue against this. A 1 in 10 grade is steep but the horizontal distance is 
only 0.5% smaller than the distance along the grade. My Tracks distance errors 
are much greater than that and other things could be done first for much 
greater improvements in distance accuracy. If GPS height is used, vertical 
errors might make the distance accuracy worse by more than the error obtained 
by ignoring grade. I don't know the resolution of the Google location service 
or its method of estimating height but in Google Earth I have observed step 
changes in height in a series of points along a road and obvious errors along 
paths in hilly regions where the path had near verticle  declines to the side 
of the path that weren't there in Google Earth.

Original comment by kenep...@gmail.com on 24 Dec 2011 at 5:29

[GoogleCodeExporter]

I agree with #11 - don't do this.  It would be "polishing rocks" only in this 
case it would actually make the rocks rougher.  The problem is that most tracks 
and roads go at gentle slopes up the sides of steep hillsides, so if "accurate" 
elevation is used from the inaccurate horizontal GPS positions, the altitude 
could be even more incorrect than using the GPS altitude measurement.

Even on the steepest slopes - ski slopes, the skiers rarely go exactly straight 
down the steepest part of the slope.   For more discussion, see my comments to 
issue 46: #7, #9 & #12 here 
http://code.google.com/p/mytracks/issues/detail?id=46 

Original comment by fbh1...@gmail.com on 25 Dec 2011 at 8:08

[GoogleCodeExporter]

Original comment by jshih@google.com on 21 Jun 2012 at 11:20

• Changed state: WontFix