Closed GoogleCodeExporter closed 9 years ago
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
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
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
Original comment by sandordo...@google.com
on 6 Jan 2011 at 5:01
(just removing OpSys-Android label, all issues are in Android anyway)
Original comment by rdama...@google.com
on 26 Jul 2011 at 1:00
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
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
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
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
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
[deleted comment]
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
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
Original comment by jshih@google.com
on 13 Oct 2014 at 9:50
whaddaya mean, won't fix no comment? How about a comment, junior?
Original comment by christopher.wanko
on 13 Oct 2014 at 9:59
Original issue reported on code.google.com by
steffen.horlacher@gmail.com
on 18 May 2010 at 9:46