Possibility to load static (more precise) elevation data

[GoogleCodeExporter]

Mytracks uses gps to read elevation data. As gps is not very precise in 
measuring elevations 
there should be an alternative. I thought it would be nice if there was the 
option to update the 
recorded track points with static elevation data after recording the track (in 
the "This Track" 
popup?). 

This would be just an additional option as it requires a network connection and 
does not make 
sense in some cases (sea tracks, on bridges, flights and so on...). In most 
case however the 
results are more accurate which is especially important for mountain bike rides 
(I want to show 
my friends exactly how high i climbed with my bike :) )

implementation could be done using the google maps elevation service:
http://code.google.com/apis/maps/documentation/elevation/

but the usage limit of the service is an obstacle. Only 25,000 elevation 
location requests per day 
are allowed (i guess determined by the ip-address?). That still allows you to 
analyze a single 6h 
track with 1TP/sec but some users might want to analyze multiple recorded 
tracks a day without 
getting a new ip-adress in between.... the only alternative I know about is to 
use srtm data 
recored by the nasa http://www2.jpl.nasa.gov/srtm/ but i think thats to heavy 
for mytracks :)

If you're a developer, are you willing to implement this yourself? 
yes

Original issue reported on code.google.com by steffen.horlacher@gmail.com on 18 May 2010 at 9:46

[GoogleCodeExporter]

I really like the idea. I think we can merge the data from the gps with that 
from
google maps, meaning we can accept the gps as right if it's more than a certain
tolerance range off from what maps gives us - so if you're in a bridge, it's 
too far
off and you just trust the GPS, whereas if you're actually on the ground and 
just
getting bogus data from the GPS, it'll be closer to the expected value and then 
we
can just stick to the expected value.

Also, it should be possible to enable/disable this from the preferences.

Original comment by rdama...@google.com on 18 May 2010 at 10:18

• Added labels: Component-Logic, OpSys-Android, Priority-High, Type-Enhancement

[GoogleCodeExporter]

Yes, having that kind of data correction could solve the bridge problem, great!
However I did some tests on a HTC Desire comparing GPS/Google Maps elevation 
data and
noticed that the base value significantly differs so maybe calibration is 
required.
Also, I’d like to contribute to the mytracks project in some way (providing 
patches
for bug fixes and/or new features). Are you interested in contributions? 
What’s the
time schedule to make the complete source code open?

Original comment by steffen.horlacher@gmail.com on 19 May 2010 at 7:33

[GoogleCodeExporter]

Any news on this item? I really would like to check if (and how much) this 
option would increase accuracy of the trip measurement.
Steffen, as the code is now open source you already had a look at it. Is there 
already a version available for test in your repository?

Original comment by robert.e...@gmail.com on 2 Sep 2010 at 1:16

[GoogleCodeExporter]

Original comment by sandordo...@google.com on 6 Jan 2011 at 5:01

• Added labels: Priority-Medium, Work-Large
• Removed labels: Priority-High

[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]

There error in trip distance from assuming the route is on flat ground is 
almost always much smaller than other sources of distance error.

Original comment by kenep...@gmail.com on 10 Sep 2011 at 11:02

[GoogleCodeExporter]

I would strongly recommend against this change.  The problem is that if you are 
in an area with steep hills any small error in latitude/longitude can be 
amplified into a large error in the altitude if you take the true elevation 
value instead of the GPS value.

For example, I hike on trails in hilly/mountainous areas and the trails always 
try to go at small and constant angles up the side of the hills so that slope 
along the trail is much less than the slope up hill or down hill from the 
trail.  So any error in the horizontal direction will result in a much bigger 
error in the elevation.

Now the elevation gain reported by My Tracks after a hike in a hilly area is 
always significantly larger that it should be, but if you make this change the 
error will be even larger - not smaller.  For example on a hike that I take 
regularly, the true elevation gain, as best I can figure is about 930 feet.  
The elevation gain reported by My Tracks is typically 1100 to 1300 feet due to 
the GPS altitude errors.  But if I import the track into Google Earth and look 
at the elevation gain it reports by using the true elevation on the track 
recorded by My Tracks I get about 1600 feet.  If I look in detail, what I find 
is that Google Earth believes there are many small up hill and down hill 
excursions which are due to horizontal tracking errors away from the actual 
trail that are then being amplified by the steepness of the hill up or down 
from the not as steep trail I walked.  Hope that is clear... 

Original comment by fbh1...@gmail.com on 11 Sep 2011 at 6:26

[GoogleCodeExporter]

Let me recap your objection #07: because you believe there might be an error in 
elevation data after import, no one should be allowed to import that data into 
MyTracks.

Or did you not understand that import is an end-user initiated option?

Original comment by christopher.wanko on 11 Sep 2011 at 1:24

[GoogleCodeExporter]

Answer to #08:  I understood that it would be a user option to use the 
"accurate" imported elevation data.  But I recommend against implementing this 
feature because I believe the user will be disappointed in the result and thus 
the software developers effort to implement this feature would be wasted.

I may not have made this clear, but users right now can get the equivalent of 
this feature by simply importing their track into Google Earth which can 
display the "actual" elevation along the path in a graph and Google Earth also 
computes the "actual" elevation gain. In my experience on hilly terrain where 
paths (or roads) try to follow contours along a steep hillside, the horizontal 
GPS errors result in much worse vertical error due to the steep slope of the 
hillside.

The feature would only work well on relatively flat terrain where a horizontal 
position error gives a small vertical error.  But I don't think users care much 
about elevation data on flat terrains, so again the developer effort would be 
wasted.

Original comment by fbh1...@gmail.com on 11 Sep 2011 at 1:41

[GoogleCodeExporter]

Comment to #9
I'd still like to see it and have the option to use it.  My phone (Samsung 
Droid charge) had a problem with GPS elevation accuracy in Froyo rendering all 
of this summer's bike ride tracks elevation data completely useless.  A way to 
back-fill elevation from the maps elevation service would have been great.  A 
Gingerbread update has made GPS elevation operational but still very subject to 
sporadic spikes of "garbage" data typical of GPS based elevation.  Where I am 
there aren't any of the canyons, crevices, or abysses you are so consumed with 
and it would be just fine. 

Original comment by Michael....@gmail.com on 28 Nov 2011 at 10:10

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Answer to comment #10: if you are willing to import your track into Google 
Earth, you can use it's very accurate elevation data to get estimates for the 
elevation gained and lost on your track. As I said, it may still be inaccurate 
since horizontal errors in the track are amplified by the slope of the terrain 
you are traveling.

If you are unable to figure out how to get the elevation gain/loss out of 
Google Earth, post a comment and I will reply with detailed directions.

Original comment by fbh1...@gmail.com on 30 Nov 2011 at 1:32

[GoogleCodeExporter]

Current elevation calculation seems to be very imprecise. Not only barometric 
pressure is not used on the phones that support that, but also it's much worse 
than, say Runtastic's elevation calculation. Additionally, offline elevation 
fix would be a very nice feature indeed.

Original comment by vagaba...@google.com on 10 Dec 2012 at 10:12

[GoogleCodeExporter]

Original comment by jshih@google.com on 13 Oct 2014 at 9:50

• Changed state: WontFix

[GoogleCodeExporter]

whaddaya mean, won't fix no comment?  How about a comment, junior?

Original comment by christopher.wanko on 13 Oct 2014 at 9:59