Erroneous Peakbagger lidar?

Items that do not fit the categories above.
Forum rules
  • This is a mountaineering forum, so please keep your posts on-topic. Posts do not all have to be related to the 14ers but should at least be mountaineering-related.
  • Personal attacks and confrontational behavior will result in removal from the forum at the discretion of the administrators.
  • Do not use this forum to advertise, sell photos or other products or promote a commercial website.
  • Posts will be removed at the discretion of the site administrator or moderator(s), including: Troll posts, posts pushing political views or religious beliefs, and posts with the purpose of instigating conflict within the forum.
For more details, please see the Terms of Use you agreed to when joining the forum.
Post Reply
User avatar
Eli Boardman
Posts: 664
Joined: 6/23/2016
14ers: 58  1  15 
13ers: 18 1
Trip Reports (16)
 
Contact:

Erroneous Peakbagger lidar?

Post by Eli Boardman »

I was looking at Peakbagger today, and I noticed that a lot of the peaks now have lidar-based elevations and prominences (nice). However, most of these values are completely wrong, often in really bad ways that change whether peaks are ranked and/or included on particular lists (not so nice).

Case in point: Peakbagger no longer counts Black Tooth Mountain as a Wyoming 13er, giving it a lidar elevation of 12,998 ft., while the correct elevation is 13,002 ft. based on painstaking manual analysis of all available data (i.e., the point clouds from multiple different surveys). https://www.peakbagger.com/peak.aspx?pid=5321

Other peaks have erroneous prominence values, for example Goat Flat is barely ranked with 305 ft. of prominence, but Peakbagger gives it 299 ft. of prominence. Peakbagger always underestimated the prominence of many peaks because of the choice to use clean instead of interpolated prominence, but at least the database historically acknowledged this uncertainty by giving a range of prominence values. Now, it lists the prominence of Goat Flat as exactly 299 ft. (clean and optimistic), which is just flat out incorrect. https://www.peakbagger.com/peak.aspx?pid=72033

I'm assuming the Peakbagger values are based on some sort of automated program using the 1 m DEM instead of the actual point clouds. This is a fine way to identify peak candidates that weren't detected by hand, but I'm concerned that applying this type of blanket automated analysis to a public-facing database will only lead to confusion and distrust of lidar-based methods, e.g., when Lists of John (correctly) shows Black Tooth as a 13er but Peakbagger disagrees. IMO it would be better to retain the old uncertainty ranges except in cases where the point cloud has been analyzed in detail, by hand, using the process we developed as a community.

So in conclusion, does anyone know what's going on with the erroneous Peakbagger lidar values? What are the possible solutions that make sense here?
seannunn
Posts: 67
Joined: 3/6/2024
14ers: 43 
Trip Reports (0)
 

Re: Erroneous Peakbagger lidar?

Post by seannunn »

Peakbagger isn't as good a website as 14ers.com.

Sean Nunn
"Thy righteousness is like the great mountains."

--Psalm 26:6
User avatar
madmattd
Posts: 274
Joined: 12/2/2017
14ers: 38  14 
13ers: 86 4
Trip Reports (2)
 

Re: Erroneous Peakbagger lidar?

Post by madmattd »

I wonder if Peakbagger is unaware of the work done by the community on the CO and WY (and likely other) lists and would be receptive to taking their data?
User avatar
Scott P
Posts: 9479
Joined: 5/4/2005
14ers: 58  16 
13ers: 50 13
Trip Reports (16)
 
Contact:

Re: Erroneous Peakbagger lidar?

Post by Scott P »

Peakbagger is a useful site, but it has always had a lot of errors (and weird entries for peaks).

I don't know the difference between the LiDAR info Peakbagger uses vs. LoJ, but if you click on the info tab it says that it is accurate to one meter so you're probably right that it's automated. The LiDAR info LoJ is using is accurate to within inches.

Even before LiDAR, prominence calcs have never matched any other site for prominence since they use a different (and inferior) method as the default.
I'm old, slow and fat. Unfortunately, those are my good qualities.
User avatar
Boggy B
Posts: 802
Joined: 10/14/2009
14ers: 58  7 
13ers: 780 76
Trip Reports (40)
 

Re: Erroneous Peakbagger lidar?

Post by Boggy B »

I believe it would be correct to say both the location of the identified highpoint is accurate to ~1m horizontally, and the elevation of that point is accurate to ~11cm vertically. That also implies if the actual highest point was not touched by a laser then both the location and elevation could be off by more than 1m / 11cm. Immune to such errors would be peaks whose highest point is at least 1 sq. m (if maths serve me, which they normally don't).

/tangent
User avatar
Eli Boardman
Posts: 664
Joined: 6/23/2016
14ers: 58  1  15 
13ers: 18 1
Trip Reports (16)
 
Contact:

Re: Erroneous Peakbagger lidar?

Post by Eli Boardman »

Boggy B wrote: Thu Jun 13, 2024 12:53 pm I believe it would be correct to say both the location of the identified highpoint is accurate to ~1m horizontally, and the elevation of that point is accurate to ~11cm vertically. That also implies if the actual highest point was not touched by a laser then both the location and elevation could be off by more than 1m / 11cm. Immune to such errors would be peaks whose highest point is at least 1 sq. m (if maths serve me, which they normally don't).

/tangent
Continuing the tangent... :) as lidar data is a big part of my current job:

This is a decent interpretation of the point cloud, but not quite right for the 1 m raster data. With the raster DEM data, each 1 m cell ostensibly represents the average elevation within that 1 m cell. If the ground is quite rough (i.e., a sharp boulder sitting on top of flat ground, which is common on peak summits), the 1 m elevation can be arbitrarily lower than the actual highest point depending on the elevations of other returns that are included in the grid cell.

An even bigger problem, though, is that the USGS 1 m raster DEMs are usually built using "ground" classified lidar returns. As per many other discussions on here, the point cloud "ground" classification is based on proprietary algorithms that usually consider a smoothness criterion using a triangulated irregular network. What this means, for all practical purposes, is that the "ground" classified points will almost always NOT include the highest point, especially if the high point is a boulder (again, quite common on peak summits). Thus, the 1 m DEM data are not only spatially averaged, the raster values are also inherently biased towards underestimating elevations by excluding rough terrain features from the ground classification.
_____________

As far as Peakbagger using the community-sourced (i.e., LoJ) lidar elevations, I think that might be problematic based on LoJ's clause about not copying exact peak stats from the database. That's why I am curious what solutions people might come up with--on the one hand, it would seem odd for a website that generates ad revenue (Peakbagger) to get free access to the LoJ data, and on the other hand, the halfway-accurate lidar data in Peakbagger seem worse than just using the topo map values in some cases.
User avatar
jkirk
Posts: 68
Joined: 7/19/2005
Trip Reports (0)
 
Contact:

Re: Erroneous Peakbagger lidar?

Post by jkirk »

I have been in discussions recently with Andrew Kirmse about plug-and-play using face-value algorithm analysis. I started to notice this back in April:
https://groups.io/g/prominence/message/9143

These are interesting, due to not being diligent about tileset bounds:
https://peakbagger.com/peak.aspx?pid=146156
https://peakbagger.com/peak.aspx?pid=146183
https://peakbagger.com/peak.aspx?pid=146420
https://peakbagger.com/peak.aspx?pid=150052
https://peakbagger.com/peak.aspx?pid=150685

Roadcuts at saddles and mining are another issue, not being handled with any further analysis.

But there are also many examples of peaks being copied to peakbagger, later demoted due to ground-points only algorithm results, and replaced with what is actually a lower, new HP that does not factor in unclassified returns from rocky features.
Example: https://peakbagger.com/peak.aspx?pid=145610 vs. https://peakbagger.com/peak.aspx?pid=39926, the latter copied from LoJ a long time ago (still the HP with unclassified summit returns: https://listsofjohn.com/peak/46634)
In fact, I mentioned some of these that were later corrected, like this one:
https://peakbagger.com/peak.aspx?pid=145582 vs. https://peakbagger.com/peak.aspx?pid=39920 also copied from LoJ a long time ago, also still the HP using unclassified summit returns, by a long shot vs. the new, now defunct listing that was created as the HP from ground returns only.

In any event, in conversations with Andrew, a possible go-forward solution on the peakbagger side, at least, is to improve the prominence algorithm results by reclassifying ground returns with a better point classification algorithm than what is delivered through the TNM interface. This would certainly be beneficial for all involved in terms of candidates for analysis. In fact, this algorithm Andrew has shared is largely what LoJ is leveraging for prioritization of analysis, though every peak is still analyzed manually in QGIS. Long story short, I don't think the human QGIS treatment/analysis standard as done for LoJ is going to make its way to peakbagger and frustrating inconsistencies will likely persist.
Post Reply