Working on geo + temporal data

[Jarkko Laine]

Hi there,

I'm writing an application to work on GPS tracks and looking for some guidance/best practices on how to process/store the data.

A typical workout to store would be a GPX track. Basically it's a linestring/multilinestring consisting of location points. However, each trackpoint also contains more related information, like in this case e.g. elevation, timestamp and heart rate:

<trkpt lon="24.201857764273882" lat="61.63077590055764">
<ele>153.8000030517578</ele>
<time>2011-11-15T16:33:34.000Z</time>
<extensions>
<gpxtpx:TrackPointExtension>
<gpxtpx:hr>87</gpxtpx:hr>
</gpxtpx:TrackPointExtension>
</extensions>
</trkpt>

In this example, the workout has about 1500 trackpoints, so it's a considerable amount of data.

So, a couple of questions:

* What would be the recommended way to store the data in PostGIS? Have separate tables for tracks and trackpoints? This would mean the trackpoints table will quickly grow to a shitload of rows, but each row would be fairly simple. Would that, combined with some serious caching for complete tracks, seem like the way to go?
* Would it make sense to build on the existing modules such as RGeo::GeoJSON to provide libs for relevant formats (like GPX and TCX)? I assume none of the existing libs are dealing with the time dimension? I've already written a standalone library [1] for parsing one proprietary format. Wondering how bringing it (and the future libs for other formats) under the rgeo umbrella would benefit them.
* Any other pointers, things I should consider and/or be aware of?

Cheers,
//jarkko

[1] https://github.com/jarkko/quickroute-ruby

[Andrew Libby]

Hi Jarkko,

An issue I'm working with right now actually.

My approach to storage has been to store both a linestring
as a part of my table representing the GPS activity as well
as storing individual points.

I use the linestring for most things (when say returnning
the line to the browser in a JSON representation) for
plotting within openlayers.

The many points stored in the points table are used for
other analysis like stop detection, speed calculations, etc.

Andy

--


xforty technologies
Andrew Libby
http://xforty.com
484-887-7505 x 1115