Distance calculation from trackpoints. Sanity check Please.

I am analyzing a track I recorded last summer and have found an interesting
discrepancy. The track consists of roughly 600 points taken at a 90 second
interval. (I thought I had set it to 60 which is my standard).

Total distance travelled by bike was 294km.
Analyzing the GPS track yields 287km.


There was a 93.5km stretch of a bike path on an old railway (paved !).
(Labelle to Mont-Laurier). My bike computer agreed with the distances
along the bike path. But the GPS, according to track calculations, saw only
90.2 km.

The software used to calculate distances from track points had been used
years ago to process about 40,000 track points in australia with surprising
accuracy compared to what I had recorded on my bike computer.

On the road, looking at the GPS's trip display, there didn't seem to be any
great error rate. But as the trip progresses, there are expected deviations
(for instance, GPS calculates distance on a ferry, but bike computer
doesn't). And at one point, I lost signal for a few minutes (rain + canyion
between rock faces where the single track railway passed). But this was a
fairly straight stretch, so once the GPS would lock back in, the distance
betwene 2 track points should be fairly accurate. So after a while, I
didn't really bother checking the GPS's distances since they no longer
matched. But I expected the track would be accurate since processing a
track still calculates distances between points where GPS was not locked in
to SVs.





QUESTION:

Could the 90 second track recording interval explain such discrepancies
(basically cutting curves too much and hence recording smaller distances ?)

In my past experience, 60 second intervals seemed adequate at the bicycle
speeds.(roughly 425m of distance per sample at touring speeds). At 90
seconds, the distance is above 625m. Could that difference make such a big
difference ?

Is it more likely that it was due to the bad smapling rate that I got such
a high error rate (2.3%) ? Or should I test my software to ensure the
formulas are applied properly ? (I took them from the aviation formulary).






Elevation: in raw vertical elevation, I'd say max 2km total change
(up+down). So on a road with max 10% angles, it would be far less than 2km
diference. (and on the track section, elevation was only about 150m up and
150m down), it was the rest of the road that was hilly.

JF Mezei wrote:

Since the absolute difference between arc length and chord increases
approximately as the cube of the distance, you could expect
approximately three times the error at 90 sec vs 60 sec. We'd need to
know either the radius of the curves or the speed and net change in
heading. The later is easily obtained from the track log.


So did I for mine. :-) Which algorithm did you use and what language
did you implement it in? What GPS do you have? Can you produce a .GPX
file?

I have written functions in APL2 to do these sort of calculations so I
can make the following two suggestions:
        1) You could send me the track file, preferably as a .GPX file or, if
you are using a Garmin GPS and MapSource, a .GDB file. I would then run
the calculation and you could see the results. (It should be pretty
obvious how to get my correct e-mail address.)
        2) If you have (or have access to) APL2, I could send you my functions
to play with.


At 10% grade, 2Km total elev change would occur over 20Km horizontal
travel. Since (1-Cos .1 Atan2 1) is ~0.005, you should accumulate less
than 99.3 meters of horizontal error. Since it is highly unlikely that
the slope was always that much, it's pretty clear that isn't the problem.

I would conclude that either the bicycle computer, your software or the
track point interval is the problem.

On a 320Km trip through the BC mountains last September, I recorded the
track on my Garmin GPS-V using the auto setting on Auto-Highand
accumulated 1786 points. My software will extract x,y,z position (as
well as other stuff from a .GPX file.
+/Pyth 2-/[1]x
320522.6873
+/Pyth 2-/[1]2[2]x
320361.824
As you can see, there was only about 161m difference between the 3D and
2D track lengths. The GPS-V spaced 1786 points such that
between 0 100 200 300 400 500 600 700 800 meters
# of pts 494 693 309 148 86 43 12 1

Ted

Ted Edwards wrote:

I realised I had previously recorded track that used the same road for the
first 130 km of that trip that had been recorded at 60s intervals instead
of 90 sec.

I ran the same software on it and compared the results.

The first 50km which are mostly flat had an error of 600 metres. (slowly
growing)

The next 40km which are hilly with much lower average speed saw the gap
remain at 600m.

The next 20km are slowly climbing, but still allow relatively fast cycling
saw the gap increase to 1.0 km. The next 10km which are one big downhill
saw the gap narrow to 800 metres.

What I do in the program is to select the trackpoint which is nearest to
the waypoint. Since track points do not necessarily happen right on top of
a waypoint, there are variances which would be on average half of the
distance covered between two track points. But those errors are not
cumulative. So the 200metre variation in gap would be explainable by this.

The last common reading 10km later shows a 1.7km gap between the two, but
the recent track starts to diverge just before reaching the waypoint, the
60 second track gets to 0.1km from waypoint, whereas this year's track gets
to within 1km from waypoint (the waypoint is off the main road, and this
year I continued straight instead of going into the village).

So basically, I acquired roughly 1km divergence over a distance of 120km
with 90s vs 60 sampling intervals for each track.





                ));

} /* end of calculate distance in radians */

if(function & (CALC_DIST | CALC_SPEED))
{
*/




Wow, ! I haven't touched APL since CEGEP (between high school and
university). I still have my 2 manuals though :-)



Not yet. This is all home brew software. Exporting to XML shouldn't be hard
though. However, not sure how you could integrate the waypoint matching to
track.

Probably easier for me to generate a test track on my GPS in simulator mode
and then add waypoints at precise offsets from each other along the track
and then run that through my program to see if I get those same distances.


The bike computer would have been an obvious "blame it", except for the
fact that it isn't the one who disagreed with the signage along the bike
path... On the 93.5km path section, the GPS was off 1.7km compared to the
signage.

But that is also the section where the GPS lost a lock for a few minutes
here a there during a winding/climbing section of track so this may be the
big explanation. There was lots of rain too at the end of that section, and
constant drizzle for the last 50km which was also on windy road.

It is really disapointing to see this because I was really hoping to have
an accurate recording of that trip. What I might do is statistically
correct the track based on error rate for different sections and pad the
distances so that the total at the end of the day (and at various known
places) comes out OK.

An update.

I ran my program on a Montreal-Quebec track of roughly the same length and
this time, the distance seems right on the spot.

So it appears that a 90 second time interval for track point recording
really does degrade track accuracy significantly at bicycle speeds.

In fairness, Montreal-Quebec involves far less curves than
Montreal-Baskatong so a track accuracy would implicitely be more precise).

JF Mezei wrote:
I recognize that. I have it implemented as 'dist2' and have not found
it terribly accurate. Oh, it's probably more than adequate for most
navigation but uses great circle not oblate spheroidal calculations and
a not horribly precise value for Earth's radius. I ran a comparison
between Sodano, dist2 (same algorithm as yours) and xy_dist which is a
"flat earth" algorithm. For distances less than about 10 Km between
trackpoints, the error in "flat earth" is down in the millimeter range.
Each of the algorithms was run against the same set of points - a
reference point and three others offset by .001 .01 and .1 degree. This
was done varying the latitude, the longitude and both. I forget where I
found Sodano. Some claim Vincenti is better but I haven't got around to
implementing that yet. You'll notice that dist2 gives errors
proportional to distance while xy_dist gives errors that increase in
proportion to the square of the distance but even at 100Km/hr you'd
never get above a tenth of a meter with a waypoint every 60 seconds.

Comparing Sodano with xy_dist and dist2

xy_dist and dist2 algorithms come from Ed William's "Aviation Formulary"
http://williams.best.vwh.net/avform.html#flat for xy_dist
http://williams.best.vwh.net/avform.html#Dist for dist2

North-South
p049.5 120 p49.501 49.51 49.6,120
3d1(p0)Sodano p
111.219 1112.195 11122.038
3d2p0 xy_dist p
111.219 1112.194 11121.941
3d3(p0)dist2p
111.325 1113.250 11132.500
3|d2 d3-d1
.000 .001 .096 .106 1.055 10.462

East-West
p049.5 120 p49.5,-120.001 120.01 120.1
3d1(p0)Sodano p
72.437 724.366 7243.655
3d2p0 xy_dist p
72.437 724.366 7243.656
3d3(p0)dist2p
72.300 722.998 7229.980
3|d2 d3-d1
.000 .000 .001 .137 1.367 13.675

SW-NE
p049.5 120 p49.501 49.51
49.6,-120.001 120.01 120.1
3d1(p0)Sodano p
132.728 1327.244 13268.884
3d2p0 xy_dist p
132.728 1327.283 13272.834
3d3(p0)dist2p
132.742 1327.383 13270.203
3|d2 d3-d1
.000 .040 3.950 .014 .139 1.319

All distances are in meters rounded to the nearest millimeter

I'm running APL2 for OS/2 and it's wonderful. :-) Actually, I've been
using APL since 1967. It's great for this kind of stuff.

I don't need any waypoints. If you could send me the track in question
as a simple text file of Lat Lon elev separated by spaces, one track
point per line and preferably in decimal degrees but if that's not
convenient, I can easily convert from ddd mm.mmmm or what have you. All
I need to do is add one simple line to my Trackpoints function to handle
that. I can then calculate and return to you a plain text file of as
many lines as trackpoints by 12 columns containing

x y z T lat lon elev d-dist head d-time tk-dist speed
1 2 3 4 5 6 7 8 9 10 11 12

BTW, which GPS do you have?

Ted