Data aggregation

The easiest way to collect all necessary data concerning a track would be, of course, to use a GPS receiver during the tour. Also, georeferencing photos could be done automatically by using a modern camera (e.g. the Nikon D200) with appropriate accessoir. As I, unfortunately, do not possess such devices, alternative methods of data collection are employed.

Tracks themselves and the locations of photos are simply drawn on top of topographical maps. This is achieved using a Tablett PC (Toshiba Portégé M400) with QGIS. The photo tag solely consists of an id which is referenced from a database containing the photos. As some maps that are available to me are not so detailed (e.g., the Harz tracks), drawing the tracks directly on Google sattelite images is an alternative when the resolution is sufficiently high (e.g., Thüringen).

Data processing

After polylines describing the tracks are available, further data can be obtained. Height values for the track elevation profile are extracted from postprocessed data of the NASA Shuttle Radar Topography Mission (SRTM) available from the CGIAR Consortium for Spatial Information. The digital elevation model (DEM) used provides a horizontal resolution of 3 arc seconds and a vertical precision of less than 16m. The elevation and distance along the track are obtained using GRASS GIS 6.1 (usually the distance is slightly underestimated).

Due to large uncertainties caused by the drawing and the uncertainties of the DEM, the track profiles contain a huge amount of noise. To extract the significant information (after all, overview profiles for hiking do not need a precision below 50m), the profiles are filtered to cancel out height fluctuations below a certain threshold. However, when walking along a steep edge, fluctuations are not easily eliminated. This may cause the ascent and descent to be heavily overcounted (e.g., first Grenoble tour) or underestimated (e.g., first Snowdonia track).

The photo spots are assigned to the closest points of the track polygons using GRASS; their heights are interpolated from the filtered height profile.


The framework used for online display and navigation is based on the OpenLayers JavaScript library. It is extended for display of georeferenced photos, Google Maps baselayers with KML overlays, and a display for height profiles.

At home UMN Mapserver is employed to generate the overlays showing the tracks and the photo locations. However, there is no public mapserver known to me. Therefore, the track overlays are also drawn by Google Maps. Using the Google Maps API polylines in the KMZ format can be drawn. New version GDAL/OGR are capable of converting shapefiles to kmz while performing the necessary transformations (using PROJ.4) to the new projection and coordinate system.

The point layers with links to the photos, however, are generated by mapserver and some home grown scripts. The public versions are the output of these CGI programs.

Similarly, height profiles are the output of CGI scripts using Gnuplot and ImageMagick.

Projections used