..or alternatively maybe I am pushing the program too hard, and I need a workaround.
First of all, the 3D stuff is absolutely fantastic!
However, I have noticed one decrepancy which may be nitpicking, and if so, I need a workaround for something.
The "bug" is that the DEMs apply their elevation data slightly too far to the west. For example, take a look at this screenshot from some of the trails we used at the
IMBA Ellicottville Epic:
http://www.trailmap.us/topo-drg-2.jpg You can see the creek on the left sitting on the edge of the hillside rather than in the valley. The switchback in the middle of the picture was laid out by the IMBA trail crew using a clinometer to get precisely a grade of 10%, but here it looks like it is on flat ground. The valleys further to the right show creeks on the hillsides, which is seen better in this screenshot:
http://www.trailmap.us/topo-drg-3.jpg This screen shot also shows a V-shaped section of a trail that is supposed to be out on a spur (and is according to hte contours) but is shown off the east side of the spur instead (with contours "draped"
over the spur!
Also, going back to
here, you can see that the track is floating above the valley on the western sides, but is hidden "beneath the surface" on the eastern sides of the valley. (note, the brown track is an export of a shape file of my map, and has no elevation information, and thus its corresponding red track is located beneath the map surface (at sea level actually).
Another, more dramatic example is this:
http://www.trailmap.us/sp-drg-1.jpg where the contours describing the west side of the stream valley are instead lying on the valley floor, with the creek halfway up the eastern wall of the gorge.
I thought this may be an artifact of the DEMs that I downloaded from the CUGIR repository at
http://cugir.mannlib.cornell.edu/, so I checked that by loading the DEMs into Arcview. A 2D image of the DEMs and the shapefile that generated the non-GPS track is shown at
http://www.trailmap.us/av-dem-1.jpg and I can see, for example, that the V-shaped section of trail is indeed on the spur as described by the DEM data.
May or may not be important: I made sure that the coordinate system I used fas the default for topofusion matched the coordinate system that the DEMs wre provided in, specifically, NAD27 datum with a UTM projection. Could there be some possible hard-coded assumption that the DEM data are in NAD83? This is just a wild guess, but I throw it out since the difference between the datums would be on the order of the error seen in these screenshots.
I noticed a similar artifact is seen with the sample data provided with the beta distribution. (See
http://www.trailmap.us/topo-sp-1.jpg ) But as fas as I can tell, the artifact is the reverse, with the DEM data being rendered too fact to the
east, but in any event, we have the "draped" contour syndrome again.
Now as I mentioned above, I may be pushing the program to more accuracy than it is set up to do, which is OK. The program still rocks! I can live with it. However, I was wondering if there was anyway to just show the "projection" of the track onto the surface, rather than the projection plus the actual 3D coordinate position. As shown in my
first screenshot, the GPS track (the one with the elevation data in the GPX file) is shown hovering above the surface on the west side of the valley while on the east side it is "underground". If I wanted to publish some screenshot images, I would like to show just the projected image of the trail on the surface.
Thanks.
Jon Sundquist
