Optimizing and visualizing GPS data

Extracting Tours

The code in Listing 2 defines a tour by reference to the first entry (start) and the last entry (end), as well as a whole bunch of track points (points) with geodata and timestamps in between. It iterates through the YAML data arriving via the standard input, assigns the data to the current tour, and starts a new tour if a break of more than 60*60*5 seconds (line 10) (i.e., five hours) occurred in the meantime.

The if construct in line 34 checks to see whether the script was called with the --tour option, including a tour number; if so, it prints the YAML output for this tour. If no command-line options exist, the script jumps to the else branch in lines 38-46 and outputs the metadata of all tours – as shown in Figure 5.

Now, a tour is definitely not restricted to just mountain climbing activities. If you forget to switch off your navigation device after completing your conquest of the summit, it will simply keep recording your movement while you are driving home. Claiming that this was a physical activity would obviously be very unsportsmanlike, and it would mess up the display if you wanted to enter the data on a map later, because automobiles tend to cover longer distances in a shorter time than a hiker on foot.

Ditching the Drive

Another filter in Listing 3 thus finds the first hike from the track data of a tour. Using the CPAN Geo::Distance module, it determines the distance between two consecutive track points in the Track data. It uses a little geometry to determine the distance between two points on the surface of the earth defined by their longitude and latitude and outputs the results in feet (as specified by the foot parameter in line 16). If this distance is greater than about a half mile (2,600 feet), line 26 discards all the values recorded previously to concentrate on the entries that follow.

Listing 3

hike-find

 

Line 31 computes the current speed of the hiker by dividing the distance covered between two consecutive track points by the time elapsed between these two measuring points in seconds. If this value is greater than 15 feet per second, it is unlikely that the hikers covered the distance on foot and more likely that they are sitting comfortably in their car and driving home. In this case, the last command in line 33 terminates, and the Dump function at the end of the script in line 40 prints all the track data collected up to that point in the @markers array in YAML format for the next stage in the process.

Drawing Maps

To visualize the track data, two further scripts generate two different views: Listing 4 uses the Google Maps API to enrich an HTML view of a satellite photo with colored track points; Listing 5 uses the Google Charts API [2] to draw an elevation profile of the hike.

Listing 4

map-draw

 

Listing 5

elevation-chart

 

Figure 7 shows the result of the Google Maps API [3] drawing the navigation device's track data on the satellite photo. All told, the data went through four filter scripts until the final HTML data was generated, which you can then showcase by pointing a browser at the map.html file that was created:

gpx2yaml *GPX | tours --tour=18 | hike-find | map-draw >map.html
Figure 7: Tracks on the Bright Angel Trail in the Grand Canyon.

In the DATA area in the second part of the map-draw script (Listing 4), you can see the HTML text with JavaScript code that communicates with the Google server and, in this way, centers the satellite image on the starting point of the trip while at the same time entering the track coordinates.

The overlay google.maps.Polyline then connects all the coordinates with red lines in the color defined in line 59, #f9290c, a luminescent red. All of this happens in the JavaScript initialize() function in lines 44-65; the browser triggers this asynchronously with addDomListener once the page is loaded.

The Perl script uses the CPAN Template::Toolkit module to patch the dynamically calculated coordinates into the static HTML JavaScript block, replacing the [% center %] placeholder by the first track point object and [% mappoints %] by an array of all points collected, each after creating JavaScript objects of type google.maps.LatLng for them.

If you only want to play around with Google's Map API and send in fewer than 1,000 requests per day, you do not need to register; however, for more, you do need an account with an API key. If you take a close look at Figure 7, you will see the short straights that connect the discrete points recorded by the tracker, making the path look a little jagged. If you take an even closer look, you will see that the outgoing and return journeys take the same path and that the two diverge slightly in places.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • GPS Tools

    Almost all manufacturers of GPS devices use proprietary formats to save routes, tracks, and waypoints. Vendors unfortunately rarely offer Linux software for uploading and downloading or processing the data. Four GPS editors keep Linux users on the right track.

  • Perl: Plotting GPS Data

    Perl hackers take to the hills with a navigation system that provides a graphical rendering of a hiking tour.

  • Prune

    Have more fun with your GPS data with this easy-to-use Java-based tool.

  • Google Earth

    Google Earth lets you view the world from space and zoom in on towns, roads, and buildings. We’ll show you how to travel our planet’s surface, its cities, and even the sky from your desktop.

  • Min

    A simple design, efficient performance, and a built-in ad blocker are reasons for a closer look at the Min web browser.

comments powered by Disqus

Direct Download

Read full article as PDF:

Price $2.95

News