GPS Track Logs

[samsalway]

We'd like a way to store GPS track logs in GUANO. For example, when users are doing a transect recording, the file could contain the track during the recording. An obvious and simple starting point would just be a comma separated list of lat/lon coordinates, but there are a few issues to consider.

1. Timestamps:
   a) Record a timestamp with each coordinate
   b) Record a start time and sample rate (e.g. once per second for most GPS units)
   c) Should they be optional?
   d) No timestamps, assume that first point was recorded at the start time of the file and ignore samplerate
2. Altitude - could probably be an optional third component of the coordinate
3. How would it relate to the current Loc Position/Loc Elevation metadata, should they be mutually exclusive, or Loc Position is required if a track is being added (and is always the first point in the track?)

As a starting point for the debate, here's a proposal:
Loc Track: list of comma separated coordinates. Each coordinate is three or four float values. The first value is a time offset since the start of the file in seconds. The next two values are lat/lon (the same as Loc Position), the optional forth float is altitude in metres (same as Loc Altitude).

Loc Track is independent of Loc Position/Loc Elevation/Loc Accuracy.

Example:

Loc Track: 0 -112.2532845153347 36.09886943729116 645,
1 -112.2540466121145 36.09919570465255 645,
2 -112.254734666947 36.09984998366178 645
3 -112.255493345654 36.10051310621746 645,
4 -112.2563157098468 36.10108441943419 645,
5 -112.2568033076439 36.10159722088088 645

[riggsd]

This seems like a useful feature for long recordings. It seems like an important constraint that the track exclusively describe points within the duration of this particular recording, however, so a complete track outside of GUANO will still be required for a mobile survey if audio isn't recorded continuously.

Because not all GPS receivers are capable of sampling at integer second intervals, time offset should be either a floating point offset in seconds, or should be given as full ISO timestamps. I think that I learn toward the former: a float offset from Timestamp, with the first Loc Track value having offset 0.0 seconds.

Your proposed format for the field is otherwise just how I'd propose it as well: A comma-separated list of tuples, each consisting of (offset in seconds, latitude, longitude, elevation in meters) separated by whitespace.

Should elevation always be required? Should it be optional? If optional, may it be both present and absent within a single Loc Track?

I think that, for simplicity in working with data, Loc Position should always be included even if including a Loc Track. Otherwise a client would be forced to search two different fields.

Let me know if you have further comments, and I'll open it to the guano-discuss email list for further comments.

[samsalway]

constraint that the track exclusively describe points within the duration of this particular recording

Agree.

time offset should be either a floating point offset in seconds

Yes that's what I was imagining, but I didn't say that clearly and my example doesn't suggest that.

Should elevation always be required? Should it be optional? If optional, may it be both present and absent within a single Loc Track?

I'm always in favour of being as flexible as possible. I would be writing the decoding software to handle all of these situations anyway, regardless of whether the specification said it wasn't allowed, because why not, it only makes the software more resilient. So I would vote for optional per point.

I think that, for simplicity in working with data, Loc Position should always be included even if including a Loc Track.

Agree. Even though data duplication is bad, I think in this case we can argue that the meaning of the data is actually different and in that way it is not duplication.