Announcement

Collapse
No announcement yet.

Tabletop and Phelps 12/01/16

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Makwa
    commented on 's reply
    Thanks TB. Great stuff as always.

  • Trail Boss
    replied
    Originally posted by Makwa
    ... The kmz file that I download from GIS.NY.GOV that is all of the NYSDEC hiking trails represent a pretty close approximation of where the hiking trails are.
    "Approximation" is the key word. In practice I've found the DEC's trail data to be highly simplified and, occasionally, wrong (I guess due to being outdated). A long time ago I mentioned the trail to Ampersand is shown to run up the wrong slope. However, I feel the DEC's data is, normally, a reasonable approximation of the actual route.

    ... When I overlay that in Google Earth and look at an elevation profile for a section of trail I'm assuming that the trail is drawn in the right spot. The elevation data points that are used to create that profile, I assume, come from points along that line. What I meant was if the line is drawn poorly, the data points are crummy, and thus produce a result that is inaccurate. Does this make any sense?
    ​If the trail drawn runs up the wrong slope (i.e. Ampersand example) then, sure, it's a lousy representation of the actual route and whatever distance or ascent it claims is likely to differ from what you measure when you hike the actual trail. On the other hand, even if it runs <50 feet off to one side or the other of the actual route, that's not going to significantly skew the calculations (unless 50 feet to left puts you over the edge of a significant change in terrain, like a cliff).

    ... On caltopo when I use the USGS 7.5 Topos for planning a hike I know the trails are off. You can see this when you attempt to measure distance or profile and adjust for it. The light gray lines that pop up when using these functions appear to be the actual locations of trails and I assume are using more accurate data points to draw the profile. ...
    ​Those gray lines that "pop up" are trails sourced from OpenStreetMap (OSM). A significant number of OSM's High Peaks trails now have my fingerprints on them; I can vouch for their accuracy.

    ... For my own edification I just took a recent tracklog from Wakely Mountain. The track in Garmin Basecamp said 1712' of ele gain. In caltopo it was calculated at 1861' and Google Earth it was 2006'. However, for prepping the hike I used the DEC trail info from the kmz file I got at GIS.NY.GOV and it said the hike would be 1696'. I now understand that each manipulates the data differently ...
    ​ ... and that's what accounts for most of the discrepancies: "each manipulates the data differently"; they either use different Digital Elevations Models (DEM), or use them differently, and/or use different smoothing algorithms. Very few mapping tools report "raw ascent" and employ some form of massaging.

    ... if the DEC trail info I typically use is drawn in the wrong place then the ele profile will be inaccurate.
    ​Yes but only if it is waaay wrong and not just a little bit off to either side of the actual route. The way the mapping tool calculates ascent is far more likely to influence the results.

    For example, import a tracklog into Runalyze. It offers you a choice of three DEMs, the size of the threshold ("step height") and to use/not use smoothing. When you start tweaking all those "dials" you discover you can produce an ascent to Allen that varies by (worst case) hundreds of feet. Basecamp, Garmin Connect, Caltopo, Strava, etc don't let you tweak the values and simply enforce their own secret recipe for calculating ascent. That's why each app is likely to report a different value for ascent despite given the same tracklog (although they're usually in agreement for distance).

    So far,I've only found only one mapping tool, Suunto's Movescount, that exclusively reports "raw ascent" (sums up each incremental increase in elevation). Its liable to report an impressive result for total ascent because it doesn't smooth out (erroneous) transients (and vertical accuracy for a GPS is only 20 meters). Garmin Connect lets you choose (use a DEM or "raw ascent") because should your tracklog's elevation data be based on a barometric altimeter, you'll want "raw ascent" because an altimeter is more "vertically accurate" than a GPS (~3 meters)

    ​I consider the "gold standard" to be the average of several ascents recorded by a temperature-compensated barometric altimeter. Then I tried to find a mapping tool that produces results identical to Joe's data. So far none of them are "dead on" but two come awfully close (usually a little bit lower than his results). Both Garmin Connect and Runalyze (using 3m threshold, Google DEM, and no smoothing) produce realistic ascent values (i.e. close to Joe's data).
    Last edited by Trail Boss; 12-03-2016, 02:06 PM.

    Leave a comment:


  • Thomas
    replied
    Originally posted by JoeCedar View Post
    What kind of device were you using to get that ridiculous elevation gain, 4400 ft?

    The simple elevation differences are:
    Loj to TT; 4427-2180 = 2247 ft
    Ph jct side trail to Phelps: 4161-2900 = 1261 ft
    Total = 3509 ft
    Add for small ups/downs about 200 ft

    Real" total ascent of about 3700 ft
    My average of field measurements from two hikes - 3650'.

    Natlife - I don't know if you're familiar with this useful resource, but here is a measurement of water levels on the Hudson River in Newcomb:



    Had you proceeded with your Haystack/Basin plan, it's possible you may have been turned back at the crossing of John's Brook.

    Leave a comment:


  • Makwa
    commented on 's reply
    I am woefully ignorant how the results of the elevation profiles are calculated but what I'm driving at is the data for that calculation has to be taken from whatever section of terrain the line for the trail is drawn over. The kmz file that I download from GIS.NY.GOV that is all of the NYSDEC hiking trails represent a pretty close approximation of where the hiking trails are. When I overlay that in Google Earth and look at an elevation profile for a section of trail I'm assuming that the trail is drawn in the right spot. The elevation data points that are used to create that profile, I assume, come from points along that line. What I meant was if the line is drawn poorly, the data points are crummy, and thus produce a result that is inaccurate. Does this make any sense? Or am I totally missing the point? I'm only talking about planning out a hike. I don't mean taking a tracklog after a hike, laying on Google Earth and seeing what the elevation profile looks like. On caltopo when I use the USGS 7.5 Topos for planning a hike I know the trails are off. You can see this when you attempt to measure distance or profile and adjust for it. The light gray lines that pop up when using these functions appear to be the actual locations of trails and I assume are using more accurate data points to draw the profile. You get totally different results for the ele profile if you attempt to hand draw the profile by tracing over the trail drawn on the map. Get what I'm driving at?

    For my own edification I just took a recent tracklog from Wakely Mountain. The track in Garmin Basecamp said 1712' of ele gain. In caltopo it was calculated at 1861' and Google Earth it was 2006'. However, for prepping the hike I used the DEC trail info from the kmz file I got at GIS.NY.GOV and it said the hike would be 1696'. I now understand that each manipulates the data differently which brings us back to our main discussion but all I was attempting to say is that if the DEC trail info I typically use is drawn in the wrong place then the ele profile will be inaccurate. For Wakely there were a few places on the upper half of the hike where the drawn trail diverged quite notably from the track. This is true on nearly every trail I look at. Just curious how much the small inaccuracies of the input affect the information I'm seeking pre-hike.

  • Natlife
    commented on 's reply
    Context matters. So, no.

  • Trail Boss
    commented on 's reply
    Not sure I follow you. Google Earth's inflated values for ascent are a result of how it uses Google's Digital Elevation Model (DEM). For example, when calculating elevation profiles, both Runalyze and Caltopo report lower, more realistic, ascent values despite the fact they also use Google's DEM. Three apps relying on the same DEM yet one (GE) consistently reports higher values.

    The trails shown on USGS topos of the ADKs are typically outdated.

    The accuracy of a trail depicted in OSM depends on who drew it and what they used as a reference. Ideally, the author should rely on several tracklogs. Strava's heatmap is a good source. It also demonstrates why a single tracklog is only an approximation of the "true" route. Get about a half-dozen and now you've got something good.
    Seward and Seymour: http://labs.strava.com/heatmap/#15/-...16902/blue/run

  • moosebeware
    replied
    Originally posted by Natlife View Post
    That all changed once I reached the tabletop path. There was no more path, there was a brook. I can deal with an inch of running water, but not 3-4 and more in flatter muddy areas. So I whacked a few hundred yards until the running water in the path became manageable. I felt thankful that happened before spruce trees became so thick that I would be left with no good options.

    Why do people feel the need to always walk around obstacles?
    No incongruencies here, right??

    Leave a comment:


  • Makwa
    commented on 's reply
    Trail Boss... how accurate do you find the trails in OpenStreetMap on caltopo? I generally just use the USGS 7.5' Topos and find that my tracks diverge quite a bit from the drawn trails. I think that's where most of the erroneous cumulative ups & downs come from. A poorly drawn line can give the illusion of a lot of rolling hills when the actual trail just follows a contour line and gains no elevation. Whether it's caltopo or Goggle Earth if the line is not correct all that planning data is bad too. GIGO.

  • Trail Boss
    commented on 's reply
    In addition, most of that 400 feet of ascent occurs in the first mile after departing the trailhead (~300 feet).
    http://caltopo.com/map.html#ll=44.18...&z=15&b=om&a=c

    Beyond the junction with Calkins Brook Truck Trail, it's almost level (just rolling terrain with minimal cumulative ascent). Not until you pass the Seward Trail junction does it begin to ascend again (~100 feet). GE's estimate of ~1000 feet implies the rolling terrain has so many undulations that it contains 1000-400=600 feet of ascent! Haha! Not a chance.

  • All Downhill From Here
    commented on 's reply
    HDR is a plague.

  • Makwa
    commented on 's reply
    I just came up with about +1000 from Seward TH to Seymour HP in Google Earth. It's at least +400 as the elevation is around 1700 at TH and over 2100 at the HP. I suppose that's barely noticeable over nearly 5 miles of walking.

  • Trail Boss
    commented on 's reply
    I agree. "Hairballs" will definitely inflate the final results (hairballs: drifting GPS measurements, while standing still, producing phantom mileage and ascent) . They must be eliminated to avoid inaccurate values for total distance and ascent. Google Earth does its best to remove hairballs and other spurious trackpoints (and apparently so does Strava, according to your post). The problem is most tools don't tell you if they massage your data; you discover it when four tools report four different results for the same tracklog!

    BTW, the production of "hairballs" can be minimized but that's a topic for another thread. FWIW, my GPS app doesn't produce them at all because it pauses recording when I'm not moving.

  • Trail Boss
    commented on 's reply
    FWIW, I rarely play games with a photo's color palette. I'm not a fan of the current craze for pics with a surreal, often lurid, appearance. The photo above is what my camera saw without HDR or filters or color-tweaking in post.

    Having said that, it is guilty of registering a bit too much blue which is a common problem in winter (white snow reflecting blue sky and scattering blue light everywhere). Marcy's summit probably looked a bit whiter to the naked eye than it appears in the photo. It was a "bluebird" day but with some atmospheric haze so the left side looks like "Azure Blue", transitions to "Brandeis Blue" and finally, especially the upper right, to "Persian Blue".
    http://www.commonground191.com/journ...blueshades.jpg

    There's also the camera's (automated) attempt to set the right exposure level. For example, the sky in this shot is almost "Ultramarine" as a result of properly exposing the snow-encrusted tree.
    https://www.flickr.com/photos/948111...7663176295481/

  • Natlife
    commented on 's reply
    The nearest Timmy's takes care of that since the Saeco is a little too noisy for a 3am latte when my better half is sleeping.

    Talking about views, yesterday I was wondering where the best quiet place would be to set up a hiking chair and marvel at grand views of the great range for hours.

    And I'm going left and right here, but when I was on phelps I noticed the northeastern peak next to tabletop probably was higher than 4000 feet with more than 200 feet of gain on the col of the parent peak. I validated on USGS topo that is rises between 270 to 300 ft to 4304 ft. Why is it not counted as a separate peak? I must have the rules wrong.

  • greatexpectations
    commented on 's reply
    JC / TB - while far from certain, i have a hunch that some inflated measurements are a result of a factor which your hiking styles don't create much opportunity for and so you probably haven't encountered yourself. that is, taking long breaks. when the gps is left on during long breaks i think that the tiny differences of measurement error could possibly add up to a surprising amount. as an example, an extended stay of 1h10m at the flowed lands recently netted me a free ~.35 miles of hiking according to garmin. that long break plus others led to over a mile extra in the end with elevation totals which to me seemed high by about 400ft for the trip.

    getting strava's take (which appears to focus only on moving times) they also awarded me that free mileage. but whether it is some sort of smoothing to pull out non moving time or a different map service most of my phantom ascent was erased by strava.

    estimating from OP's report they had 1h20m or so of down time. if they left their gps on in in that time it might account for some of the discrepancy. just my two cents.
Working...
X