The problems with representing GPX tracks in spatial databases

This is something I’ve been wrestling with for a while, both with Spatialite and latterly with Postgis. The problems stem from the fact that a GPX track segment contains information that can be represented in two entirely different ways in these systems. A track segment as represented in a GPX file, as we know contains track points that each have attributes like latitude, longitude, elevation and time and can have more such as speed and course (both of these are calculated between the current point and the previous one). You can import these points into a spatial database (most straightforwardly through an intermediary like shape files), but the devil is in the details and it might surprise you if like me you are used to programmes that have been written to handle GPX files and visualise these rather than larger GIS applications.

The crux is – if you want to see your tracks as lines, you lose the information that each track contained and are left with the segment represented as a row in the database – if you want to retain all the information, you’d better import those trackpoints as points, but then you don’t have a graphical representation of the line each segment represents. Perhaps a couple of illustrations will elucidate the problem

gpx file represented as points in Qgis

Here you see what happens when you import a GPX file into Quantum GIS as track points. This is how it would then be imported into a spatial database. The advantage here is that if you open up the attributes of the file, all the information from the original file is there. I don’t know about you however, but I find it quite difficult to trace the individual track segments from these points – you have an idea of where the road is but no idea about how many times the street is reiterated.

gpx file represented as lines in Qgis

This is more like it – but is it? If you looked at the information each line contains, you’ll see that all the information about the individual points is lost – each line is represented by a single row in the attributes data and so information about the elevation, speed, time of each track point has been lost. Better not use this as a way of archiving your GPS data.

At the moment, other than designing your own database schema and writing your own importers (which is what I’m contemplating), there’s no way I know of in the spatial database world of representing a GPX file in one instance that retains its lines and the information about each point. Please prove me wrong.