17

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":

  1. 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".

  2. 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?
|improve this question
  • 3
    3. Tracks are a collection of points with x, y, z, m[] and time attributes. A CSV file containing these 5 values for each point captured is more than enough for a robust data model. If you need fancy things like <> and {} to help you organize your data - and meta data - you're doing it wrong. – nagytech Jun 20 '13 at 4:59
  • 1
    I agree with just a good old CSV, it represents everything the GPS is recording. But, the GPX format is pretty common for GPS devices. This link may be worth something as both GPS and KML are XML data formats. stackoverflow.com/questions/1820129/… – Pete Jun 20 '13 at 5:27
  • While XML is 'great' and all (for the reasons in @Pete's linked post) none of those points are relevant. If anything, the overhead does nothing but slow down the number crunching, and bloat your data storage and transmission methods. Granted, if you're a mom-n-pop operation you'll never have enough data to encounter these issues, and your number crunching is not going to be intense. Either way, you won't have the resources to sustain operation this close the metal - so XML away. – nagytech Jun 20 '13 at 11:06
  • 1
    Note that this question has much more to do with MODELING and design of data (representation of its conceptual essence) than actual implementation. The comments so far focus in file formats, which is, from what I think, yet further away, because file formats depend more on the implementation medium than the nature of data itself. – heltonbiker Jun 20 '13 at 13:58
  • 1
    In OO terms, I've used a Line class that can hold the points (lat, lng, ele, time, speed, bearing, etc). And, from there Routes that represent hand drawn or intended "tracks" and Tracks that represent an actual track with time/speed data. Conceptually I DO think they are different (hand drawn and or supplied by a cartographer, or such, versus an actual track). The terms are just semantics, sure, but using real types has been helpful (rather than just mashing it all together as a "Track"). Also, when it comes to serialization formats, I'd consider GeoJSON: en.wikipedia.org/wiki/GeoJSON. – Charlie Collins Jun 20 '13 at 14:58
4

I don't think this question can actually be answered definitively as there are many, many ways of approaching this ..

However, these thoughts may be relevant:

The data storage is relatively unimportant. Whatever mechanism you use, Database, JSON, KML, etc, it is still "flat storage".

What is important is the software you use and how you represent the data in the Software so you can conduct your modeling.

Speed is available two ways, distance x time or as an output from a GPS device, which is where you are sourcing your data from. Therefore time becomes irrelevant other than as an informational item.

Additionally, you can also consider time by using an offset from the start of the track. If you have the speed and the distance, then you can compute the times at the points. (the distance between two points can be determined by a number of different methods)

Elevation should be considered part of the Spatial Model, they are relevant to determine a whole host of interesting information about the track itself, for example, grade can be calculated which then allows you to understand speed variations along a track. If there is no grade, any slowdown or speed increase may have been due to removing the foot from the accelerator.

In terms of merging tracks and hand drawn tracks, time is of little relevance. You can apply arbitrary speeds to determine time, for example, how long to traverse a track at a given speed. If you are merging tracks several days apart, then your data will simply not make sense so you will have to reset the time fields, possibly using offsets form the track beginning.

If elevation is not known, it is not known, therefore it should not be zero. It should also not be negative, as negative elevations are valid elevations as well. (In a below sea level valley, mine pit, etc)

Yes, DEMS are available, Yes you can extract from them. Will the be accurate enough? Unlikely, unless accuracy is not an issue. GPS or barometric provided Elevations will be the best you can get.

So to try and give you an answer that goes close:

Store the data in any flat format you like, but I would recommend, PostGRES with PostGIS is a good option, it handles 3D nicely. You can then use the extensive spatial functions in PostGIS to manipulate/model your data.

If you use some form of custom program you develop, use an Object Orientated approach rather than arrays. If you use arrays, you may as well use a database.

|improve this answer
  • 1
    Thank you very much for your time and interest, I found your answer very interesting. But with one thing I "cannot" agree: that speed is the canonical variable, while time would not. This for many reasons, but primarily because speed is the derivative of distance over time. You will always get good speed, and good average speed specially (which I found to be more useful than instant speed), if you derivate segment distance over segment time. On the other hand, if you integrate speeds, integration error will give very wrong results after a short number of samples. – heltonbiker Nov 22 '13 at 14:06
  • 2
    Yes, I can concede that point . however, the use of GPS Tracks are in themselves subject to position errors. It is all a matter of what accuracy you can get. Agreed, Time is quite accurate, but you will get errors using that as well due to the GPS positional errors. One second intervals on track points are just that, one second, but inside the GPS, its algorithms may well be interpolating anyway to arrive at an estimated position. Obviously the granularity of the data will have a big impact on any analysis method chosen – Mark Cupitt Nov 23 '13 at 0:55
  • Very well put... That's why I have already given up plotting "instant speed" altogether, going for some sort "instantaneous average speed", that would be: "for every given point in a trajectory, its instantaneous average speed is the average speed of the last N minutes." It plots very nice, and gives an appropriate sense of speed variations along a trip. But the proper calculation can be tricky and is most probably a bit computationally intensive. – heltonbiker Nov 23 '13 at 19:05
0

As already mentioned in another answer, there are many different approaches. Since I asked for "conceptually robust data models", after a lot of research I found two great bodies of knowledge that provide two quite different approaches to the "moving objects" concept, and have a lot of overlap (in a good sense):

  1. The books from Gennady and Natalia Andrienko, published by Springer Verlag, for example the excellent Visual Analytics of Movement (amongst others from the same publisher). Highly recommended.
  2. The Abstract Specifications (conceptual schemas) of ISO/OGC (ISO 191xx norms), specially ISO 19107 (Spatial Schema), 19108 (Temporal Schema), 19111 (Spatial Referencing by Coordinates), 19141 (Moving Features) and 19148 (Linear Referencing)
|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.