I am thinking about writing software to deal with GPS Tracks and Waypoints (mostly storing, displaying and calculating metrics such as speed, grade, and some simple statistics).
I wonder what should be the most conceptually robust data model regarding trackpoints, and here are some "candidates":
Considering Tracks as sequences of Trackpoints:
1.1. Tracks are considered "2D", since map projections are 2D. Trackpoints might or not have elevation, might or not have timestamp. Elevation and timestamp are consideres "extras", "optional". For terrestrial applications, elevation is a direct function of lat/lon (obtainable via DEM);
1.2. Tracks are considered "3D" since geographic space is, indeed 3D, and the trajectory of the receiver is 3D (2D projection is thus a form of data reduction). Timestamp might or not be present (the track could have been drawn by hand).
1.3. Tracks are considered "4D" (3 spatial + time). Thus, a hand-drawn map is a special case where elevation and timestamp are
null
or otherwise not present, but the Trackpoint properties are always "there".Tracks are considered dictionaries of streams, where all the streams have equal lengths. There is a list of latitudes, a list of longitudes, a list of elevations, one of timestamps, etc. This makes easy to calculate statistics of each property, and the concept of Trackpoint becomes "virtual" in a sense, since it is a cross-section of many streams.
If I understood right, GPX format adopts 1.1., KML adopts 1.2. (with no support for timestamp), and Strava API adopts 2. (in JSON format), but in the end these are just FILE formats for serialization and storage, not necessarily for modeling, computational representation and numbercrunching.
Is there any form that is preferrable, in an object-oriented sense, and why? (I believe that strong typing and sensible modelling at least would avoid operations that doesn't make sense).
EDIT: some "intriguing" additional questions:
- Is a hand-drawn track CONCEPTUALLY the same thing that a device-recorded tracklog? Should they be of different data types?
- Should it be considered "correct" that KML stores null elevations as zero? Zero IS an elevation, and if you don't know the elevation you shouldn't assign a numeric zero to it, isn't it?
- Should it matter, in a track with elevation, if the elevation is extracted from DEM data ("offline") or from GPS data or barometric data ("in the field")? Should this be flagged in the Track object? Saved to different Trackpoint properties? Ignored? Should they be different collection datatypes?
- If I edit a device-recorded track in a map editor (adding, moving and removing points), or combine tracks from different dates, how should the timestamps in the trackpoints be handled? Should they be "resetted" to null? Should an object (trackpoint collection) of a different type be created from the former ones?
<>
and{}
to help you organize your data - and meta data - you're doing it wrong.