Tim Parks writes in about Trailguru, a GPS route sharing site with an innovative approach to scalable viewing in Google Earth. It’s another post that practically writes itself:
I thought I would write and let you know about an internet project I am working on called Trailguru to make discovering and sharing route information easier by blending Google Earth, Google Maps, Wiki, and GPS technology. First off, TrailGuru enables you to visualize your exploits in Google Earth / Google Maps. For an example, have a look at a track I captured on a trek I did in Ladakh in Northern India.
By sharing your track, Trailguru also integrates it into the trail maps on the site that are accessible from Google Maps or Google Earth. For example, you can add trail maps to Google Maps by adding our mapplet.
Finally, the end goal of TrailGuru is to share route information and you can also create and share a routes from the captured trails on the site that can be downloaded to a GPS by other users. No more wandering around looking for trailheads.
For example, here is a route for a summit hike in Andalucia in Spain.
We are just over a year into the project but already have mapped over 600,000km of trails on the site across a wide variety of activities (hiking, mountain biking, road biking, mountaineering, etc.).
I had a look at Trailguru, and noticed that the Google Earth link does not lead to a series of vector-based routes delivered via a network link, as you might expect, but instead to rasterized bitmaps of the routes in dynamic overlays. I asked Tim why he chose to go that route (so to speak:-):
I chose to use graphic overlays instead of KML overlays because of scale and speed. I actually started out with KML overlays but the computational effort on the servers once you have a non-trival number of trails in the database became huge. The sheer quantity of KML also started to be an issue — for a heavily mapped section (like San Francisco which has many submissions) the resulting KML was over 10M large which 1) took a long time to download and 2) I estimated that it took 100M of memory in Google Earth to store when decoded. This resulted in sluggish performance in Google Earth. There are some workaround hacks like lowering the level of detail at higher zoom levels but in the end, even these weren’t going to enable us to scale in heavily mapped areas.
So I have switched to tile overlays using the same algorithm that Google Maps uses. The downside to this approach is, of course, that you could have to compute 4^Z (where z is the zoom level if you are familiar with that concept — a typical town level view is at zoom level 12 and street level is at zoom level 15 roughly) tiles. Fortunately, in practice, trail submissions tend to clump together and the number of non-empty tiles is about 5% of that and all that computation is invisible to the user. This method scales incredibly well (0 database lookups to find the correct tile set and then just HTTP image downloads).
Trailguru joins a growing field of route sharing sites, but it is interesting to see how they are each finding their niche, both in terms of specialization (running, biking, trekking, with/without photo support) and in terms of their technical underpinnings — in Trailguru’s case, a wiki-esque motif and a tiling solution for mapping output. (If you want to check out the competition, there is Everytrail, Bikemap.de, walk.jog.run, Wikiloc, Tagzania and Crankfire. Am I missing any?)