Reverse GPS track log

[@rt]

Hi Guys
There’s no specific programming section! But this isn’t really programming, just procedure.
I’d like to hear from anyone who uses a GPS for hiking, not just lives behind a keyboard.

I aim to implement a reverse track log feature similar to what I think Garmin call TrackBack.
Please give thought on my current idea for procedure in no specific language.

*****

The user would normally terminate the track log at the end of a hike,
but if for whatever reason the log was terminated earlier,
check that the last recorded point is within a reasonable distance of the current position.

If not, then direct to the last point of the track log, otherwise,
direct to the second last point of the track log.

It could be argued better just to direct to the closest point of the track log first,
but that assumes that anywhere on the track log is accessible by means other
than the trail that was taken to create the track log.

When the hiker arrives within a reasonable distance of either the last point
of the log, or the second last point (depending on the condition above),
direct the hiker to the track log point that was recorded preceding what is now the
closest track log point (which will for the first iteration, be either the last or second last point).

Repeat the above until the user arrives at the first point of the track log.

*****

Cheers, Brek.

[Ian.M]

I don't hike with a GPS but I do use them for marine navigation.  The constraints are a lot looser, but in areas with shallow water or other hazards you do have to stick to the navigable channels.

Without detailed terrain maps, the GPS system has no way of knowing whether a track point can be reached without backtracking through all subsequent points UNLESS the track has crossed itself at approximately the same altitude, then it can prune loops if the user chooses not to backtrack by the 'scenic' route.

Until the current position is close enough to a track point to start backtracking, the best option is to display range and bearing to a selected trackpoint. 

It then depends whether you have a graphic display that can support selection of trackpoints from a plot using an x-y cursor interface or whether its only text based. If text based, the selection list should be headed by the last trackpoint, but the closest trackpoint on any loops of the track that  are closer than the last (or first) trackpoint should also be listed in case the user can see a viable shortcut. Each trackpoint would have its sequence number and scrolling the list sideways would display bearing, range, time logged and coordinates + altitude.

Once the position is near enough to a track point, simply feed track points to your route following algorithm in either forward or reverse sequence depending on the desired direction to follow the track.   The devil is in the details as older Garmins simplify the route for trackback by skipping contiguous intermediate points that are nearly in a straight line .

[MarkF]

I wrote a program some time ago to convert Garmin routes into track logs. (i.e. I was creating a map from routes using routes for a unit that didn't have mapping capabilities.) As I remember, Garmin starts a new track log every time the unit is turned on. The track log (at least for Garmin) is not one big string of points. If you upload the track log to your computer, you will see separate files. So, the condition you describe does not exist. All the points in an individual log have points that are physically near one another.

[Ian.M]

However each Garmin trackpoint has a timestamp and a flag to indicate if its the start of a new track segment (e.g. track logging was disabled between the previous and current point, or the GPS was off or had lost its fix) and Garmin's serial interface binary protocol transfers the points in order.   You can do some post-processing to determine whether a new track segment was most likely due to a glitched fix and string together segments that have close enough ends, both temporally and spatially.

Anyway @rt wants to broadly emulate Garmin behaviour, not interface to a Garmin.  Presumably he's doing his own logging.

[@rt]

I’m doing the logging yes. Garmin I relate to because they are the units I’ve used.
Each point is merely 8 bytes (2 floats), and I only know the time stamp of each point by calculating from the beginning because of a fixed logging interval.
For loss of GPS fix I could only estimate the time of each point.

Ian, What I was thinking there, is at the end of a hike, you do know you can backtrack,
so from any point you should be able to hike relatively straight to the previous point.

The main issue in my mind is if the hiker ended logging, and then walked halfway home,
I saw it more logical to direct them to the far end of their track (wasting a lot of time),
on the assumption that they kept hiking past the end of the log out further into the wilderness.
but your suggestion seems viable. If you can get yourself closer to a point halfway home, and tell the thing you did so (or can do so).

One unrelated issue I’ll try to recognise is the drift that occurs if you take a break without suspending the logging.
Either try to bypass it on the way back, or quarantine it in the first place to possibly be written off as nonsense during the logging.