MTBGuru blog

In the previous post we compared GPS elevation data to elevation data from topographic maps - the latter giving you generally more averaging than the former. Something similar is going on when you compare GPS distance data to bike odometer distance data - but the roles are inverted here: the GPS averages more than the odometer.
Let’s look again at the snippet of Garmin Edge 305 data from the Tahoe Rim Trail:

The distance between a given datapoint and the previous one is now plotted in blue. The GPS device records longitude and latitude, from which this distance can be calculated using fairly simple trigonometry; we use the haversine form of the great circle distance, which works well (in terms of rounding errors) for points relatively close to each other.

Let’s now consider the data you would get from an odometer. First, we assume that the circumference of the wheel is properly set up in the odometer, in which case it can be considered quite accurate. The odometer essentially takes a datapoint for every revolution of the wheel; for a 26 inch wheel and a speed of 5 mph (hey, it was a tough technical climb at altitude), there is about 1 second in between datapoints. For higher speeds, there is less than that.

Compare this to the GPS: the Edge at its fastest takes 1 point per second, and usually much less, as you mostly want to use it in its ’smart’ or adaptive mode (to limit the amount of data recorded and make economic use of memory). On the graph below, this is illustrated by the higher density of (red) odometer datapoints than the GPS points:

The odometer of course doesn’t really record all these points, but the figure shows what they would look like if it did. It does record a cumulative (total) distance number though. How does it get this? By simple adding the lengths of all line segments between the points. This is done for both GPS and odometer in the figure below. The odometer will almost always give you a higher total distance reading than the GPS (in particular on fairly bumpy or technical rides) because all the red (odometer) line segments add up to a higher total than all blue (GPS) segments - this is so because the odometer simply samples at a higher rate than the GPS (see also the ‘length of a coastline’ problem). You could of course try to compensate for this effect by doing lots of wheelies ;).

Update (12/30/06): as ragetty observes in the comments below, the latter paragraph isn’t entirely accurate: the odometer doesn’t give a better number because it samples at a higher rate than the GPS, but because the wheel tracks all features of the trail (at least, those features with size in the order of the wheel diameter). What I tried to say is that if the GPS would sample at a higher speed, it would be in better agreement with the odometer.

One of the perennial points of discussion when talking about GPS elevation profiles is the accuracy of the elevation measurement. Total elevation gain and loss on a given route can significantly deviate between various devices and from what you would calculate on a topographic map.

On our FAQ page we try to delve into this:

Most GPS devices use either the GPS signal (using triangulation), a built-in barometric altimeter or a combination of both to give you an elevation reading. The latter will generally give you the most accurate results, but unfortunately in many cases there will still be significant errors – for instance, the barometric pressure may change during your ride for other reasons than elevation change (i.e. weather changes), or the sensor itself can get out of calibration.

That being said, the devices with barometric sensors will usually give you reasonable results. There is however a problem that typically occurs on technical trails: all the tiny ups and downs of the trail result in minute elevation changes that are being recorded. These accumulate and on longer rides it will generally result in overestimates for the elevation change numbers compared to what you’ll see on a topographic map.

Accuracy is generally measured with respect to what your route mapped on a high resolution topographic map would read - this can be obtained by downloading your GPS track data and mapping the track on for instance National Geographic’s Topo! tool. Of course, the cumulative elevation numbers you will get this way are depending on the spatial resolution of the topographic elevation data - effectively resulting in some averaging. which numbers are best is in a way a mattter of taste: the topo value gives you an averaged and ‘reasonable’ looking number, but on the other hand, you did ride all those tiny bumps up and down (the problem statement is somewhat similar to the ‘length of a coastline’ problem).

We chose to apply some averaging in calculating the total elevation gain and loss from the GPS track data, in order to get fair agreement with values that are typically obtained using topographic data.

The best you get with a barometric sensor is probably a relative accuracy of half a meter or so. ‘Relative’, because in order to obtain absolute accuracy you would certainly need to recalibrate the sensor frequently.

The figure below shows some elevation data recorded on the Tahoe Rim Trail (fairly technical) using a Garmin Edge 305 in the ’smart recording’ setting (in this setting, the sampling speed is adaptive), and it illustrates some of the minute, sub 1m elevation changes mentioned before.

A new feature, and we like to think it’s a real cool one: you can now easily publish maps on your own website or blog. It just takes a second or two and a copy and paste operation.

If you have a trip on MTBGuru that you’d like to share using your own website or blog, insert a snippet of code and tadaa - the map, including the GPS track and clickable picture thumbnails magically appears on your site!

Let’s try it for instance here, using our ride in Annadel; this is the code:

<iframe src="http://www.mtbguru.com/trip/iframe/88?width=500px&height=500px"
width="510px" height="565px" frameborder="0" marginwidth="0"
marginheight="0"></iframe> 

and this is the result:

(doesn’t work yet in Safari but it does in most other browsers)

The map is fully zoomable, can be dragged etc like a regular Google map. And clicking the camera icons shows the picture thumbnails (if you then click on a thumbnail your browser will point you to a higher resolution version of the photo).

You can just copy and paste this code; it’s on the bottom of each trip page in MTBGuru, look for the item that says ‘Publish Map’. It even works for posts on forums, for instance see this thread on mtbr.

Right after raving about our Google Earth feature, we discovered a bug in our ‘Google Earth Download’ feature… o, Murphy! Or is it the demo-effect?
Either way, we’re actively looking into the issue; the problem is that for some trips a crash will occur when you try to download the Google Earth file. Our apologies and we’ll try to resolve this asap…

Update (12.30pm): bug squashed and issue solved!

We love looking at our trips in Google Earth, it’s one of more entertaining things to do on the net after having gotten tired of watching Youtube video’s ;). So we thought to write this post in an effort to share the love.

To enjoy this too, you’ll first need Google Earth on your computer, and the free version is all you need. It works on Windows, Mac OS X and Linux. ‘Using Google Earth‘, the blog of John Gardiner, author of the Google Earth user guide, will give you plenty of pointers and howtos that will help you get familiar with Earth, but everything works fairly intuitively.

Now if you’re looking at or have created a trip in MTBGuru, say a hike to the summit of Half Dome in Yosemite National Park, you’ll see on the Control Panel in the sidebar of the page a menu item saying ‘Download Google Earth File’. From your GPS data we have generated a .kml file (the native format of Google Earth) that contains both the track information as well as thumbnails and links to your geotagged photos, and clicking this menu item lets you download the .kml file and open it in Google Earth (you can also set up your browser to automatically open it in Earth).

In Earth you’ll then see something as shown by the screenshot below:

Your MTBGuru trip is added as an item under ‘My Places’ in the ‘Places’ window, as indicated in the left sidebar (see blue arrow). A folder ‘mtbguru.com’ is created that has subfolders containing the track and picture information. Your track is displayed as a red solid line, and the various picture stops are indicated by the camera icon. Now the fun can begin - Half Dome is obviously an appropriate and willing victim for 3D manipulation - play a bit with the perspective and click the camera icon and you can compare the rendering in Earth with your photo:

And if you click the photo thumbnail, you’ll be pointed to the picture in full resolution at MTBGuru in your browser.

I wrote an article about how to use static page caching with Ruby on Rails. While this covers basics that have been covered many times before on other blogs and websites, it also explains why all parameter validation checking should be done before an action method is called, otherwise Bad Things Will Happen.

At the time, I didn’t know this, so I didn’t search for or stumble into articles that warned against this. Hopefully this is article will help prevent Rails beginners from running into the same problem.

The article can be found here.

Tom

We’re experiencing intermittent outages this morning (morning in the Pacific US, evening in Greenwich/Europe) - we’re working on it and investigating the possible causes. Our apologies for any inconvenience!

Update: everything should be running fine now, we’re still investigating the causes of the problem. Note that absolutely no data has been lost, this was strictly a problem with the web server.

Update 2: the problem seems to have reoccured - we’ll keep you posted when we got everything sorted out! Sorry for the down time.

Update 3: the problem seems related to picture processing. We’ve suspended picture processing for the time being. Everything else should be working, but please be aware that you temporarily won’t see any new pictures that you upload - thanks for your patience and we’re trying to fix things as soon as possible.

Update 4: we should have stuck with our first thought - it is more than likely a problem with the web server and web host, an acute case of growing pains. We have found a patch for it and everything seems to be working again - picture processing is up and running again. We’ll continue to test and monitor things, please bear with us in case the problems would resurface.

You’ll notice a new box in the sidebar, right under the control panel: ‘Search MTBGuru’. Yes, this finally allows you to search our whole site and trip archive - a few notes though:

• We’re using a custom Google search engine, set up for the www.mtbguru.com domain.
• At present, our whole site may not have been indexed completely by the GoogleBot so search results may be incomplete for the time being.
• We’re still looking at offering a search engine of our own that directly searches our database.

Thanks for your patience and hopefully this helps browsing and searching for trips and trails.

Ben Barren (’RSS’ing down under’) illustrates most of his writings with photos of either beautiful women or nice cars - so we were honored to see our little splashscreen image liven up this post, in which he writes some kind words about us. He mentions being a fan of ‘hyperlocal’, the general lack of localized photo communities and efforts in that area such as ours and Plazes.net.

Thinking about it, this lack was indeed something that was central at the conception of MTBGuru - we wanted a quick, easy, intuitive way to share our photos, GPS data, maps and descriptions/comments of the outdoor trips (biking, hiking) we were undertaking with our friends - in the context of the *trip*, i.e. a location and time, because that defines what we’re sharing. The whole thing would then become something like a living memory of that trip. Our web app intends to be the glue that keeps all the stuff together. We are now hosting all photos on our server, something we decided to do more out of practical considerations than anything else, but we are looking into integrating photos from Flickr/Picasa - it shouldn’t really matter where the photos are stored.

In completely unrelated news, these yellow magnet cards to tag drivers who come obnoxiously close when you’re on the bike are really cool. It would almost make cycling on narrow and busy roads entertaining again.

We had the opportunity to play a bit with Google Earth Pro and create 3D flyover animations of MTBGuru trips - below is an example that we’ve uploaded to YouTube - the quality of the original .avi file is of course much higher, but this gives you a nice idea of what you can do. We may do more in this area in the future so stay tuned.

The ascent of Mount Tyndall: