trumpimar / mytracks

Automatically exported from code.google.com/p/mytracks
0 stars 0 forks source link

Track statistics are inaccurate #281

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
I used MyTracks to record my last hike, but the statistics given for the track 
are obviously inaccurate. If I export the track as KML file and open it in 
Google Earth, several of the given statistics values differ tremendously. The 
track distance is off by 2 km (14 km in MyTracks vs. 12 km in Google Earth), 
the minimal and maximal height is off by about 30 m and although I never 
stopped during the hike, MyTracks claims I didn't move for about 20 minutes. 
The statistical data given by Google Earth matches with the values taken from a 
map of the area where I hiked. As both MyTracks and Google Earth use the same 
GPS data recorded on my mobile phone, it is obviously MyTracks that messes up 
the statistics.

What steps will reproduce the problem?
1. Record a track with MyTrack
2. Export it as KML file
3. Load KML file in Google Earth
4. Compare statistics

Im using:
- Android 2.1 on Samsung Galaxy i5800
- MyTracks 1.0.21

Original issue reported on code.google.com by axel.kap...@gmail.com on 26 Jan 2011 at 8:35

GoogleCodeExporter commented 8 years ago
I recall noticing that gradient calculations seemed to be inaccurate at some 
point in the past, but haven't checked recently. Perhaps a known-answer test 
gpx would be useful for validating calculations, even a simple, arbitrary 
track...? Does one already exist?

Thanks for this app, btw! 

Original comment by nzli...@gmail.com on 9 Feb 2011 at 8:28

GoogleCodeExporter commented 8 years ago
I just noticed that the altitude of tracks imported into Google Earth only is 
correct if the option "Clamped to ground" is active. If I switch to "Absolute", 
tracks float in midair. So the offset in altitude is obviously caused by 
inaccuracies of the GPS measurements on my device. But I still have no 
explanation for the differences in track lengths and total time/moving time.

If you need more info or if I can help in validating the correctness of the 
statistical calculations, just let me know.

Original comment by axel.kap...@gmail.com on 14 Feb 2011 at 10:04

GoogleCodeExporter commented 8 years ago
The elevation data will inaccurate until we can fix:
http://code.google.com/p/mytracks/issues/detail?id=46

I recently fixed the general distance overcounting.  I am going to close for 
now.  Please reopen if you are still seeing distance over counted with 1.1.X

Original comment by sandordo...@google.com on 18 Feb 2011 at 4:44

GoogleCodeExporter commented 8 years ago
OK, so my original bug report actually encompasses three different bugs:

1. Inaccurate elevation data (Issue 46: 
http://code.google.com/p/mytracks/issues/detail?id=46)
2. Distance overcounting (fixed with r391)
3. Wrong results for moving time (apparently last worked on with r506)

I'm going to check the fix for distance overcounting in the coming days, but 
what about moving time? Is the fix for this problem still "work in progress"?

BTW, thanks for your quick response and this awesome app!

Original comment by axel.kap...@gmail.com on 19 Feb 2011 at 6:10

GoogleCodeExporter commented 8 years ago
I had some spare time today and decided to check the fix for distance 
overcounting. :) 
To do that I recorded a track with MyTracks, exported the collected data as KML 
and GPX files and opened both of those files with Google Earth. The following 
table shows the differences in distance of the three different track formats:

MyTracks native     : 14,2 km
KML in Google Earth : 13,8 km (error: ~3%)
GPX in Google Earth : 13,5 km (error: ~5%)

I guess a maximum error of 5% isn't that bad and I can definitely live with it. 
Would still be interesting, where exactly this error is introduced. Is it the 
conversion to KML/GPX or is there still some difference in the way the distance 
of the track is determined. I leave the decision, if it is worth to dig deeper, 
to the developers... :)

Thanks,

Axel

Original comment by axel.kap...@gmail.com on 24 Feb 2011 at 4:43

GoogleCodeExporter commented 8 years ago
I opened a new feature which outlines how we could implement a smoother 
recording function.  Unfortunately to do it right is not trivial.  Here are the 
details.  Please star/add to this issue:
http://code.google.com/p/mytracks/issues/detail?id=363

Original comment by sandordo...@google.com on 24 Feb 2011 at 4:59