After adding a bunch of Yosemite trails to OSM, I've run out of my own GPX files to add more, yet there are so many more trails to add. Doing more hikes One way to get more is to go hike more, but that will only get me so far. Another is to get the trails from USGS Topo's (which are released in the public domain).

The USGS Topo data is often decades old, but for National Parks that's usually not an issue: nobody is their right mind is going to reroute the Mist trail, or the John Muir trail, or build a whole new trail from scratch in a National Park, so the topo maps are still very much up to date.

The accuracy of the topo's is usually spot on for POI's. Trails are not as good. A good example is a hike I did two weeks ago at Kings Canyon, where the trail on the USGS Topo is sometimes off quite a bit from a GPS recorded trail. At first, I thought this was due to the GPS unfriendly environment, but Yahoo imagery proved that the GPS was correct whereas the Topo trail was not.

That's said, there are good arguments to be made to use the topo trails:
* For generations, the topo's have been all that was available for those whohad to endure life without GPS.
* The accuracy is still good enough for hiking purposes. Sufficient to get guidance about the trail distance and where it goes and very accurate for trail intersections, which is really what counts.
* Google Maps: it turns out that the Yosemite hiking trails in Google maps are an *exact* copy from those of USGS topo's (* see below). If it's good enough for Google, it should be good enough for OSM until someone gets hold of real GPS data.
* The choice between no data at all or data that's entirely useable for practical purposes is a no brainer.

With that said, how to go about it?

JOSM and Merkaartor currently have some WMS support for USGS topo tiles. There are two problems however:
* The support is extremely flaky. That's a friendly way of saying: it just doesn't work most of the time. And if it does work, the performance, especially on Merkaartor is unbearable.
* The WMS tiles are derived from the terraserver-usa.com version of the USGS topos. They are generally ok, but, for some reason, they are a disaster in the Californian Sierra's. A quick look at Yosemite Village shows this: there are major jumps at original topo boundaries. The terraserver WMS tiles are unusable as an original source.

Here's a link with the Yosemite Village tiles:
http://terraserver-usa.com/ImageInfo.aspx?T=2&S=12&Z=11&X=339&Y=5226&W=2&qs=%7cyosemite%7cca%7c

A better solution: use the original topo tiles + QGIS

I've tried this only on a Mac, but I'm using nothing but open source tools, so it should be equally applicable for Windows or Linux.

I'm using the following ingredients:
* Original USGS topo files. Right now, I'm getting those from topoquest.com. Not the most user friendly web interface, but it allows on the download the original topo files in GeoTIFF format.
A typical filename will look like this: o37117g5.tif, which means: latitude 39, longitude -117, sub-quadrant G5. Each such file is typically around 12MB in size. You can download this particular file here: http://www.topoquest.com/map-detail.php?usgs_cell_id=50147
* GDAL: this is a library and toolset to work with raster based geographical data sets.
* QGIS: a program to interactively work with geographical data, create maps etc.

Installing QGIS is a bit of a pain (at least for Mac) in that it has tons of dependencies. You end up downloading and installing a whole bunch of libraries and frameworks before it will come to life. But with the instructions provided on the site, it didn't really give me problems doing so.

GDAL is one of those frameworks on which QGIS depends. However, I also had it installed from scratch (by downloading the source code and compiling) because some Python based script didn't seem to work out of the box.

The reason you need GDAL is to convert the USGS topo files to the correct coordinate system. The original topo files use a NAD27 reference ellipsoide and UTM coordinates. QGIS will read them in, but display them incorrectly with other, WGS84, data, so things won't line up. It may be due to my inexperience with QGIS that I couldn't get it to work, but eventually I took a different route: I converted the topo files from NAD27 to WGS84. This can be done with the following command:

gdalwarp -t_srs WGS84 o37119g5.tif o37119g5-w.tif

You can now read in those files into QGIS as a raster layer: Layer -> Add Raster Layer -> < select o37119g5-w.tif >

When you load multiple topo's at the same time, you'll notice that the white borders around each map will overlap with the one next to it. I'm currently writing a program to get rid of those borders, but for now, you can work around it by setting each topo layer as partially transparent. You will notice that adjacent maps line up exactly. MUCH better than the terraserver based WMS layers!

I wanted to make sure that existing GPX tracks of mine would line up correct. For this, you first need to enable the QGIS GPX plugin, as follows: Plugins -> Manage Plugins -> Enable GPS Tools in the list

You can now read it in the GPX file by doing: Plugins -> GPS -> GPS Tools -> Load GPX File

Your GPX data should now line up perfectly with the topo data.

What rests is to know how to digitize and how to create a GPX file out of QGIS.

For this, you first need to greate a GPX layer: Plugins -> GPS -> Create New GPX Layer.
After you've specified the file name (you have to add the .gpx suffix yourselve), you will see the gpx file appearing in the directory you specified.

By default, layers in QGIS are read-only. You need to explicitly open them for editing. Select the new gpx tracks layer and then do Layer -> Toggle editing.

You can now start tracing the trail that you're interested in. To complete editing a track, do a right click and fill in its name.

I couldn't find out how to save my changes and I had to resort to the QGIS manual to figure it out: switching the layer from edit mode back to read-only mode does the trick.

Note that saving the current project does NOT save the newly entered data. And quitting QGIS without leaving edit mode won't raise a warning that there's still unsaved data in a layer! DUH.

So that's it: you now have a GPX file with newly entered tracks.

All you need to do now is load them up in JOSM or Merkaartor to convert them to OSM format (and mark them as 'path', of course. ). You can't really upload the GPX to OSM as a trace, because the GPX file won't include time stamps. (Why this limitation?)

A fantastic improvement, maybe worthy of a Google Summer of Code project, would be to create an semi-automatic, user assisted digitizer: USGS topo's only use a limited amount of colors and black is reserved for names, roads and buildings. If a user could mark a initial point of a trail, it wouldn't be too hard to make a tool that digitizes up to the next intersection where it could then ask for further instructions. This would reduce the digitizing effort by an order of magnitude.

Have fun!

(*) To check that Google Maps data is an exact copy, one can do the following: GDAL has a really cool tool called 'gdal2tiles.py'. This takes a GeoTIFF file and converts it to a full WMS compliant tile set. It even includes a .html file that will create a browser page of the new tiles laid over a bunch of other tile (Google, OSM etc.) with selectable transparency. The Yosemite trails on Google Maps are an exact match.