Ten basic concepts around GPS adventure tracks
At Green Elk, we want to give some order to the personal geodata that adventurers collect. When we at Green Elk created our adventure mapping software, our design decisions depended on our understanding of the underlying concepts. And even the mere usage of our software is facilitated by straightening out some ideas and terms. If you read through this reasoning, you’ll be well equipped not just to use kajgps.py, but any tracking software and gadget. Less confusion and frustration, and proper expectations of what’s doable.
Let’s start by some definitions.
Three core concepts: Point, Trackpoint, Track
- Point: Pure coordinates. Latitude, longitude, perhaps altitude and a name. Example: 60.19531, 21.91017, 0, Nagu Marina. I have started many kayaking adventures from a the dinghy ramp at one of Finland’s largest marinas, in the island of Nagu. Its location can also be displayed as 60°11′43″N 21°54′37″E.
- Trackpoint: A point with a time stamp. Example: 2015-05-01, 11:20:01, 60.19531, 21.91017, 0. That refers to starting from the dinghy ramp on first of May at 11:20:01 UTC (corresponding to 14:20:01 local time).
- Track: A collection of trackpoints describing an adventure.
Three supportive concepts: Placemark, Placetype, Activity
- Placemark: A point of interest, of persistent value, with additional characteristics. The additional characteristics may associate the point with a particular placetype (say, a marina), a prominence (priority, importance) or a particular subheader in a list of placetypes.
- Placetype: Properties of a category of placemark, such as an icon (example: an anchor for a marina) stored either online (as an URL) or locally (say, a marina.svg file).
- Activity: Sports type, or supportive activity. Kayaking, cycling, running, or logistic movement by ferry or car to get to and from the location. The activity is associated with characteristics of how to display the track (icons, colours) or how to analyse the track (parameters for identifying breaks and movements).
So far, so good. And we’d like to keep things simple. But there are some facts of life that complicate the above easy picture, when making use of tracks.
Complications involving tracks
- Time zones. Nearly all tracks come in the UTC timezone. Nearly all users think in local time. Conversion is necessary! And conversions depend both on location and on time of year. Our current way of solving this is to allow user input of time difference by date. For 2015-05-01, I would enter a time difference of 180 minutes to be added to UTC in order to get local time. Should I have another adventure during the same day in another timezone, I have a problem, but that scenario is yet to occur.
- One adventure may have several tracks. Sometimes the user records one kayak adventure split into several track files (one for the morning, one for the afternoon), either by coincidence or due to battery issues. At other times, one track is one adventure. When analysing and reporting adventures, such random inconsistencies distract. Our current way of solving this involves the Tracklist and TrackCache concepts (see below).
- One track can have many activities. Sometimes one track file consists of several different activities. Hiking up a hill on a remote island is not kayaking. Neither is getting to the starting point by car or ferry. During the adventure, there are better things to do than fiddling with a tracker or a tracking app, so adjustments should happen afterwards. The Tracklist and TrackCache concepts solve this, together with the Segment concept.
- Tracks can have lots of idle time. The recording of the track may have started well before the adventure started. Or the tracker may have been stopped well after the adventure stopped. And the tracking may either be left on during breaks in the middle of the adventure, or stopped and started again after the break. These inconcistencies have to be taken care of in order to make comparisons of adventure durations and speeds sensible. In particular, the Segment concept helps solving this.
- Tracks can have multiple recordings. You may not trust your tracker or app, and have two of them. Or your co-elk may have a recording. This type of redundancy is hard to manage and usually involves you selecting which one of the track recordings you want to use.
- Tracks can lack crucial parts. Sometimes, one forgets to start recording a track from the start. Batteries fail. Or apps for recording tracks have low usability, resulting in part of the track never being recorded. Reconstructing lost data isn’t trivial, but photos with coordinates and times help, as does manual input of coordinates.
- Tracks can have GPS measurement errors. In particular at the beginning of a track, there may be “movements” which aren’t real but due to bad GPS reception. The software should make these errors easy to find, and easy to mark as errors.
In addition to the complications resulting from the above inconsistencies in track measurements, Green Elk has also introduced some concepts to simplify usability, in particular to help manage large data volumes. The collections we call Places and Tracklist are fairly self-evident. The concepts of Segment and TrackCache require more explanations.
Two collections of entities: Places and Tracklist
- Places: A collection of Placemarks. All placemarks entered by the user, or in a particular location, or involving a particular activity. These places can best be managed in a spreadsheet. The software then converts the placemark collections into various formats, for display and computation (CSV, GPX, KML, SVG, HTML etc.).
- Tracklist: A collection of Tracks. Specifically, a collection of track source files in a directory structure on a hard disk. The software can analyse and display these tracks, and output them into various formats (CSV, GPX, KML, SVG, HTML etc.)
Segment: A stretch of a track, with a single activity
- A segment is an active part of a track. It refers to a stretch of the track where the user perceives there to have been movement.
- A segment has exactly one activity. A track may have recordings of carrying kayaks, of going on a ferry, or taking a ski lift. A segment has one activity only, be it downhill skiing, kayaking, or car transport.
- A segment may be of little interest. The car drive after a kayaking adventure ended may have been recorded just because the kayaker forgot to turn off the tracking. If the segment is marked “Car”, it is easier to disregard from comparisons with other adventures.
- A segment doesn’t have to end in a break. While a segment usually ends in a break of some duration, it may also be followed directly by another segment with a different activity. Perhaps you ski downhill immediately after disembarking the lift, without a second’s break. You may run or cycle immediately after disembarking a little ferry, with a scarcely noticeable break of four seconds. Or you want to split a cycling segment into “uphill” and “downhill” parts, even if you don’t take a break at the peak.
- The borders of the segment are up to judgement. Should kayaking around the marina while waiting for co-elks to get ready count as a segment or not? What is the limit (in time, in distance) for a stretch to count as a segment? This is up to your judgement. At the same time, few people want to spend time describing their trips up to the minute (or second). Our solution is to have sensible defaults (for break durations, for minimum movements) when splitting tracks into segments, and to allow manual user adjustments to the outcome, when mapping times onto activities.
- Identifying the activity of a segment is non-trivial. Green Elk wants to avoid putting the burden on the user to enter the activity of each and every segment. Hence, we have coded some heuristics that re-allocates impossible activities. Going for over 200 km/h for over 100 km is likely by plane. Going for over 90 km/h for over 5 km is likely by car, not kayaking, not even cycling. The guesses of the program can then be fine tuned in the next parsing of the source tracks, if, say, the user should wish to make a distinction between “car” and “bus”.
TrackCache: A Tracklist parsed into Segments, with faster response time
- A TrackCache is redundant. The data in a TrackCache is based on data in the Tracklist source files, paired with user data from the configuration files. It can be reconstructed from that input, and re-computing a TrackCache is something a user may wish to do when improving upon the quality of the configuration files (as the user learns which track file has which activity).
- A TrackCache is more compact. Tracklists refer to Tracks in formats where data is verbose. TrackCaches are in an internal CSV format, stripping away wordy GPX tags and other unnecessary information.
- A TrackCache is near-complete. When compressing the data from a Tracklist ot a TrackCache, only such data is lost that the user deems to be unnecessary, according to the user settings. The positions during breaks aren’t recorded, nor before the start or after the end of a trip. But that’s by choice. Green Elk recommends not to delete the source data, for it to be available later, should the user need the complete original data beyond what was deemed of interest when the TrackCache was created.
- A TrackCache is significantly faster to use than a Tracklist. It is partitioned by Activity, and it has a “header” like structure by which tracks in a particular geographic area can be quickly identified.
- A TrackCache uses local time. When Tracklists are parsed into TrackCaches, the UTC time stamps are converted into local time. That conversion is thus the only step at which the dates and times of Trackpoints need interpretation.
- A TrackCache has tracks separated into segments. When Tracklists are parsed into TrackCaches, the segment splitting logic is applied, and each segment is saved in a different file. Those files are later on reused as if they were tracks. Thus, the individual files of a TrackCache fulfil the criteria of both Segments and Tracks at the same time. Mainly, this means any Track of a TrackCache has only one Activity. Also, it means that one day of adventuring corresponds to many internal Track files, which for display and conversion purposes can be merged into one output file (CSV, SVG, GPX, KML, HTML etc.).
A lot of the insight in designing kajgps resides in the above concepts. We at Green Elk would argue that all of the above concepts are universal to any adventure geodata software, with one exception. The TrackCache is specific to our implementation, and is our answer to the issue of making a collection of Track files easily accessible with high usability and quick response times.
Provided our insights are the right ones, we have created a fundament upon which to attach any functionality related to analysis and visualisation of GPS tracks of outdoor activities.