GPX files

One question is whether you have any issues reusing GPX data for your device. I could consider generating normalised data if that were necessary.

"For this track http://tramper.co.nz/?8007 for example the gradient reaches 89 degrees. I'm not sure what this relates to on the ground!" I plugged it into gpsvisualiser.com for an elevation profile and it looks like there's a very sudden, almost vertical jump in elevation after 2km that seems inconsistent with the surrounding profile. Maybe this is from a GPS with a barometer that wasn't calibrated properly from the start, suddenly deciding to re-calibrate itself? This happens to me from time to time, at least. Google Earth has a nifty feature to reset all elevations in a track to whatever's consistent with its own topological data for those positions, but it sort-of relies on a person being able to do that and remembering.

Right, I see what you mean. At this point in time I am inclined to leave it as is given that any problems with the data will be visible when the elevation profile is added. It would be pretty hard to distinguish between an error and a very steep section of track programmatically. I could trip off the steepest few gradients, but I am reluctant to do that.

In the Kaimai there are places with ladders or chains bolted to the rock, so the steep gradients could be valid at these points. Also, there are places under rock overhangs or even inside tunnels where the GPS has a less accurate position, but continues recording the track log regardless. I have seen some wildly crazy track logs recorded in a narrow rocky gorge.

Matthew, the gpx metadata is going to be wildly inaccurate. Max/Min Gradients : when a GPS records a track, you often get points recorded with spurious location and/or elevation data (eg when the GPS is acquiring additional satellites, when reception is compromised (gully, overhang, dense wet canopy) – leading to spurious max and min gradients. Average gradient : IMO not worth calculating. Walking Time : is this calculated from the gpx file? if so, that’s risky because a gpx file will often be an edit of various recorded tracks – cutting out the side trips, stops, overnight etc. (endtime – starttime doesn’t equal walktime) If you are specifying co-ordinates (Start and Finish points), it would be informative to note the grid/datum in use. On the old website you could list points and display various grid/datum combinations. Elevation profile will be useful - but more useful if a fixed ratio for elevation : distance is used. If the ratio changes to suit the track then different tracks can’t be visually compared. Maybe have the ability to lock the ratio on demand. There’s a bit of work there ! but most useful is to have access to the gpx files – the other stuff is nice to have - thanks.

I think distance from GPX files will often also be suspect. It can often depend on how frequently a device is configured to record position points. As in fewer points means a curve will be measured as several straight lines, unless you're using a very fancy algorithm. More points means that every slight inaccuracy of the reading will result in deviations from what would otherwise be a straight line of travel. I'm not sure how significant all of this is. Maybe up to 10%? More? Then there are those situations like @iangeorge noted, where reception drops and the recorded track leaps around like crazy. This happens to me every time I sit down for a lunch break and the GPS in my pack lid can end up stuck under the rest of my pack. I normally try to delete all these wacky points when I look at my GPX file afterwards, but I think if I did it could easily show me travelling a much further distance during a stationary section. It's a pretty cool thing to have the website do, though, and it could drive someone crazy to try and fight with all this stuff. Maybe just a warning about the possible inaccuracies of GPS tracks would be reasonable, at least until there's a clearer idea of how well it's working.

Hi everybody, Thanks for your feedback. Short term changes will be to remove the reporting of steepest gradients as these are likely to reflect data issues. A warning about the quality of the data is a good idea. And there will be more info about where the data came from. BernieQ: I am using the start and end times for each track segment, not for the overall track. Currently reporting just a total value. I'd be interested to see an example where this is misleading. BernieQ: on start/end points I'm reading from the GPS data and this is always WGS84 -- fortunately it's in the standard: http://www.topografix.com/gpx.asp . I will label it as such. Note WGS84 and NZGD2000 are the same for tramping purposes. BernieQ: thoughts noted on elevation profile. Agreed. Izogi: It should be made clear that the GPS data relates to the file and is not the definitive info for that track. For example, you might wander off to have a look at a waterfall or whatever. I think if a distance is 10% off, that's still a pretty good indicator though. I will work on making this all clearer. Izogi: When your GPS loses and regains signal does it start a new track segment? If so then I'm currently not even measuring the bit in between. However, I'm also not drawing it, so there's some consistency there. Since I still have the raw data (the GPX file) I can reparse it in different ways until the result is good...

Hi Matthew. I haven't checked re the segments, but I rarely lose reception completely. What tends to happen is the reception will just get low, and despite (often) being completely stopped, the GPS will keep recording the best track it can. A typical scenario would be sitting on a hut balcony during a lunch break, and maybe my pack's lying down and obscuring the GPS even more. It might get a point differing by 20-30 metres or more in random directions every few seconds. This is least accurate when stationary, because the GPS just records a track with constant dancing movement in all directions despite there being no movement in reality. Even with low reception, a track with similar dancing around during a time of actual movement will at least represent the movement over time. The forwards/backwards inaccuracy will cancel itself out as long as the actual movement forwards is faster than the inaccuracy, even if the sideways jumping doesn't. It's probably not worth bothering about, but it'd be good to be aware of it. I normally delete all those random dancing track-points during post-processing when I get home. Others might or might not, but it may be an endless road trying to compensate for bad data. :)

Matthew, I’ve uploaded an example gpx (http://tramper.co.nz/?8580 ) - I wonder what you get for the duration. I recorded a track out on one day and back on the next. Then, in a mapping program, joined the two tracks together (haven’t otherwise edited the file). So, it looks like the track is one section only. Actual walking time was 3:25 + 3:18 = 6:43 hrs but my mapping software (Oziexplorer , Basecamp, Mapsource) all report 23:22 (because they include the overnight period that the GPS was off). Note : you can delete the GPX when you're done :)