SELECT InitSpatialMetaData();

Now we can use the Longitude/Latitude values in the waypoints table to create actual geometries. First call the AddGeometryColumn function:

SELECT AddGeometryColumn('Waypoint','geometry',4326,'POINT','XY');
UPDATE Waypoints SET geometry = MakePoint(longitude, latitude, 4326);

and Waypoint becomes a point layer ready to be opened in QGIS, for example, or exported to a shapefile.
But what about the tracks? Here we need an additional step. We make the Track and TrackElement tables spatial, then use the TrackElements to create LINESTRING features in Track geometry column:

SELECT AddGeometryColumn('Track','geometry',4326,'LINESTRING','XY');
SELECT AddGeometryColumn('TrackElement','geometry',4326,'POINT','XY');
UPDATE TrackElement SET geometry = MakePoint(longitude, latitude, 4326);

and now do the update on the Track table:

UPDATE Track SET geometry = (SELECT MakeLine(te.geometry)
FROM TrackElement as te
WHERE te.trackID = Track._id
GROUP BY te.trackID)


and you’re done. The Track table is now a true line feature, and can be exported as a shapefile, etc. The column names above are as they appear in the sqlite tables created by this particular app, so you might have to replace some of the ingredients. But the recipe should be similar. So get out your spatial mixing bowl, and your phone becomes a handy GIS tool.

I pulled the data from my GPS using gpsbabel but you can also choose the Quantum GIS GPSTools plugin to download GPS data in GPX format. Now to move these layers straight into a Spatialite database I use the ogr2ogr utility. This is part of the GDAL toolset, the “Swiss Army Knife” of spatial data formats. It allows me to move vector data from one format to another, with several options to filter or alter the original data along the way.
Here’s how I start:

$ ogr2ogr -f SQLite -nln ride -dsco "SPATIALITE=YES" -t_srs "EPSG:4326" bike_rides.sqlite bike_rides.gpx tracks

The first option sets the output format ‘-f‘ as SQLite. Next I use ‘-nln‘ to choose a “New Layer Name” for the table to be created. The ‘-dsco‘ options means “DataSet Create Option” and here we dictate Spatialite. The next flag ‘-t_srs‘ sets the spatial reference system for the data layer. While not strictly necessary (GPS data is always Lon/Lat WGS84) it’s a good policy to always set the SRS explicitly. Now pay attention to the order of the next parameters: the target database is first, and the source (gpx file) is second. This is backwards from many other command line tools. Normally we expect first the “from” followed by the “to”. For ogr2ogr it’s: “destination” first and “source” following. And finally at the end of the above command we choose to bring only GPS tracks into the database.

If our GPX file contains several tracks (perhaps from previous bike rides) we can filter those out with a simple -sql option such as:

$ ogr2ogr -f SQLite bike_rides.sqlite bike_rides.gpx -nln amazia_ride -dsco "SPATIALITE=YES" -sql "SELECT name, number FROM tracks WHERE name='Amazia-2' " tracks


Next, I need to get the stops along the way, which were captured as waypoints. Similar to above:

$ ogr2ogr -f SQLite bike_rides.sqlite waypoints.gpx -nln stops -append waypoints

Now, I don’t user the ‘-dsco’ parameter since the database already exists. What’s more, I must specify ‘-append‘ to instruct ogr2ogr to add this layer as a new table in the existing sqlite database.

OK, how long was the whole ride? The built in Spatialite function GeodesicLength() calculates lengths of Lon/Lat features in meters, along the WGS84 ellipsoid.

spatialite> SELECT GeodesicLength(r.Geometry) AS “Total Length” FROM ride AS r;
Total Length
—————
9696.2803124924

But I want to know how much each section of the ride was. In other words, I want to see the accumulated distance at each of the stops. We have in spatialite a function ST_Line_Locate_Point() which returns the distance along a line feature for points near the line. (It actually finds the nearest point on the line for each of the input points). So we do:

spatialite> SELECT s.name AS "Stop name",
...> ST_Line_Locate_Point(r.Geometry, s.Geometry) AS "Stop Locations"
...> FROM ride AS r, stops AS s
...> GROUP BY s.name ORDER BY s.OGC_FID;
Stop name   Stop Locations
----------  --------------
start       0.0
rest 1      0.124783450768
water stop  0.361703783084
rest 2      0.562004941906
rest 3      0.712163267248
overlook    0.850818111308
end         0.996608235043


The OGC_FID field is automatically created by ogr2ogr as a primary key. So doing “ORDER BY” on that field insures that the stop points are displayed in the correct order. But the numbers above are not distances, but rather the fraction of the total line length where each point falls. Now multiplying these fractions by the total length from the first query above, I get:

spatialite> SELECT s.name AS "Stop name",
...> ST_Line_Locate_Point(r.Geometry, s.Geometry)*GeodesicLength(r.Geometry) AS "Accumlulated Distances"
...> FROM ride AS r, stops AS s
...> GROUP BY s.name ORDER BY s.OGC_FID;
Stop name   Accumlulated Distances
----------  ----------------------
start       0.0
rest 1      1209.93531700926
water stop  3507.18127087581
rest 2      5449.35745373272
rest 3      6905.3346675029
overlook    8249.77090219153
end         9663.3928087156

Nice. One last step, let’s put these distances permanently into the “stops” table.

spatialite> ALTER TABLE stops ADD COLUMN accum_dist float;
spatialite> UPDATE stops SET accum_dist=(SELECT
...> ST_Line_Locate_Point(r.Geometry, s.Geometry)*GeodesicLength(r.Geometry)
...> FROM tracks AS r, stops AS s
...> WHERE s.OGC_FID=stops.OGC_FID);

We use a subquery to UPDATE the stops table. Take note of the WHERE condition: the OGC_FID values from the stops table outside of the subquery must match the values from the same column inside the query.

spatialite> SELECT name AS "Stop name",accum_dist AS "Accumulated Distance" FROM stops;
Stop name Accumulated Distance
---------- --------------------
start       0.0
rest 1      1209.93531700926
water stop  3507.18127087581
rest 2      5449.35745373272
rest 3      6905.3346675029
overlook    8249.77090219153
end         9663.3928087156

There we are: accumulated distances for waypoints along a GPS track.

I’ll present three methods and point out the advantages and drawbacks of each. The first and second for those with “CLI phobia”, and the third – easier in my opinion – a command line option.

The QGIS method

We begin with a straightforward “copy – paste” process right in Quantum GIS. You DO have QGIS installed already, I hope… First activate the GPS plugin in QGIS (this plugin should get installed automatically with QGIS), and click on the GPS icon to open the GPS Tools window. Go over to the “Load GPX File” tab, and browse to find your GPX file. Click “Open” and you’ll see the waypoints or tracks from your GPS on the QGIS canvas.

Now in the QGIS menu, choose “Layer”->”New”->”New Spatialite Layer”.  You’ll need to:

• Select the spatialite *.db file
• Enter a name for the new layer
• Be sure the SRID is set to 4326 (The Lon/Lat WGS84 based spatial reference system used by all GPS instruments)
• Click to add an autoincrementing primary key
• Add any other attribute columns you’ll need

Then click OK to add the new layer into into the Spatialite DB, and into QGIS. Now comes the copy/paste dance: choose the GPX layer in the Table of Contents, and using the Select tool, select all of the features (so that they all appear yellow) and click the “Copy Features” button on the edit toolbar. Now Choose from the TOC the new empty spatialite layer, and click the “Toggle Editing” button to begin editing this new layer. And finally click the “Paste Features” button, again from the editing toolbar, to paste all the selected GPX features into the new spatialite table. Simple and elegant, but…

…if you open up the new layer’s attribute table you’ll see it’s emtpy.  ”So what”, you might ask. Well every GPS captures, along with each point location, at least a waypoint name, and elevation. In the original GPX file these appear as XML elements. If this additional information is not important then the above method should be fine. But if you want to keep the waypoint numbers and elevation, you’ll need a better method.

The intermediate CSV method

For our second try, we need two GUI tools; the spatialite-gui binary and GPSbabel GUI. GPSBabel is traditionally a command line program, but there’s a “Front End” for Windows users. This program reads and writes practically every GPS file format in use on the planet. The steps to importing a GPX file with attributes are as follows. Using GPSBabel we convert the original GPX to the “Universal CSV” format. Then in Spatialite we create a VirtualTable based on this file. And then, using an SQL insert within spatialite we transfer all the GPS locations to a permanent table, and finally create the requisite Geometry column for this new table. Here are the details:

The GPSBabel command to convert to Universal CSV format reads (assuming the original GPX file is waypoints.gpx):

gpsbabel -w -i gpx -f waypoints.gpx  -o unicsv -F waypoints.csv

Alternatively, Using the GPSBabel GUI should be intuitive, choose the input format as GPX (or whatever format you downloaded from your  GPS), and output format Universal CSV. Select the files and check waypoints or tracks, whichever is appropriate. Then run the conversion.

Now fire up spatialite-gui. On the button bar, locate and click the button “Virtual CSV/TXT”. Browse to your waypoints.csv from the previous step and click Open to select the file. In the next “Creating VIrtual CSV/TXT” window change the table name to something like  ”waypoints_tmp”, be sure to select “Comma” as the Column Separator. and click OK. You now have access to the CSV file from within spatialite. You can examine the table structure by right-clicking on it’s name and choosing “Show Columns”. The data is viewable by right-click and “Query table”.

It’s now time to create a new, permanent table for the waypoints. In the query window type the following:

CREATE TABLE waypoints (

long DOUBLE,
lat DOUBLE,
elev DOUBLE,
wpt TEXT );

At this point we want to insert all the rows from the GPX table – waypoints_tmp – into the new waypoints table. Here’s the required SQL.

INSERT INTO waypoints (long, lat,elev, wpt)
SELECT Longitude, Latitude, Altitude, Name FROM waypoints_tmp;

That should leave us with a fully populated, permanent waypoints table. At this point a word of explanation is in order. Why was it necessary to leap-frog over that Virtual CSV/TXT? Why not just import the CSV table directly into a permanent Spatialite table? The reason lies with how numeric columns are recognized by the CSV/TXT importer. If numbers appear as negative values, i.e. preceded by a minus sign (latitudes south of the equator, longitudes west of Greenwich, or below sea level elevations like at the Dead Sea) then these numbers get imported as text, and they are then useless for creating the Geometry column. When we hand crafted our permanent waypoints table as above, we set the long,lat,elev types to DOUBLE. Then, when inserting the values from the virtual table, the “text” with its minus sign got coerced into true numeric values.

We have yet one more step to complete. So far this new table is NOT a spatial table. The Longitude and Latitude values appear as attribute columns but we haven’t yet added the necessary Geometry column. Two more SQL statements complete the job:

SELECT AddGeometryColumn('waypoints','Geometry',4326,'POINT',2);
UPDATE waypoints SET Geometry=MakePoints(long.lat,4326);

The first Spatialite function adds the additional Geometry column, the metadata and constraints, and the second command populates that column based on the longitude/latitude values. Now we have a spatial table with attribute values, imported from a GPS file.

Yet one additional method is available. For those tired of reading such a long post, don’t worry, this final one is short.

The OGR command method

The ubiquitous GDAL library includes a sometimes overlooked, but powerful tool for handling vector format conversions. It’s called ogr2ogr. Since OGR can read and write both GPX formatted files and Spatialite database layers, we can concoct a one liner ogr2ogr command to push GPS locations from a GPX file directly into a Spatialite database layer, and including their attributes. SO, without further ado here it is:

ogr2ogr -append -f "SQLite" \

-dsco SPATIALITE=yes -dsco INIT_WITH_EPSG=yes -t_srs epsg:4326 \
spatial_data.db waypoints.gpx \
-nln waypoints

Just a few words of explanation: -append allows you to add a table to an existing Spatialite database. Based on this maillist thread, it seems that adding the -dsco (dataset creation options) and the target spatial reference system is a good idea. The -nln parameter is the new layer name – that is the new Spatialite table. Pay attention to the unusual order of the files on the command line: First is the destination database, and after the source (in this case) GPX file.

That’s it, the whole procedure distilled into one command. Now who still thinks the CLI is old fashioned or clunky?