744 new ranked peaks (and counting)

[JoeGrim]

Nearly a year ago, I started developing a program that would automatically identify ranked peaks. It uses the USGS National Elevation Dataset (NED), which is very similar to what we see on the USGS topo maps. I used the 1-arc-second data (~30 m horizontal resolution) and have just finished processing the entire country (minus Alaska). The program identifies any peaks that are either ranked, or nearly ranked. Then, it checks to see if there is a LOJ ranked (or soft ranked) peak within 100 meters. If there is not a ranked peak on LOJ, it outputs the information for this ranked peak candidate. I also designed it to verify the peak prominences of all LOJ peaks.

In the meantime, John Kirk has been doing the VERY tedious task of looking at the thousand and thousands of ranked peak candidates, and verifying on topo maps which are indeed ranked (or soft ranked). I'm guessing only 10% of the candidates actually end up making it (John, you might have a better estimate), because of a multitude of factors, including: summit is nearly ranked, another nearby topmost closed contours of the same elevation, large summit plateaus where the high point is off to one side, variations between NED and topo maps, etc.

Thus far, John has inspected about 3/4ers of the country and has added 744 ranked peaks and 1055 soft ranked peaks! Considering that John (and a few others) had already identified nearly 88,000 ranked peaks, this is only a slight increase in the total number. It is also a testament to John's diligence, that he had already identified nearly 99% of all the ranked peaks.

I wrote the program in FORTRAN 90 and NCL (a meteorology-centric language). If anyone else wants to use it for another country or region, I am happy to share it, as long as you give me and LOJ credit. However, you will need to be a relatively knowledgeable programmer to adapt it to other areas; though, I have designed it to be rather flexible and could help you set it up.

[JoeGrim]

I should also note: I kept the peak data in binary files for all the topmost closed contours with at least 20'/40' of prominence in the country. Data include: lat, lon, interpolated elevation, interpolated prominence) If someone is ever wanting to use it for another personal list (e.g., 250'+ prominence Indiana peaks), you're welcome to have it. You'll still have to go through the peaks on topo maps visually, but at least it gives you a mostly complete list of candidates.

[lukePlumley]

Fantastic work Joe and John! Keep those peaks coming!

lp

[TWorth]

Nice piece of work Joe. I've been following your guys progress.

The contour finder function within your NCL software package is a big improvement over trying to find prom figures and key saddles strictly from a tiled elevation grid. That's where I got bogged down.

Programs similar to what you've written have been done before, but they are either properitary and unavailable, difficult to use, or produce unreliable results.

Eventually I am going to run steepenss figures again for all the western states to 1) include all these newly found peaks, and 2) make use of updated digitial data sets. Already reran UT, WY, and CO, which can be found at ned-files.com.

The national map site(formerly USGS seamless server) has changed quite a bit and downloading NED data has gotten slower. They removed some of the smaller file formats I used in 2009 and now the file retrieval drags on and on. Also, since returning to full time software design for a paycheck, time and motivation for outside projects is low. But maybe this winter.

[DSunwall]

How long did it take to crunch the data for the entire U.S.?
How big is a NED file for say the entire state of Colorado?
this may be going off topic but your post has roused my curiosity.
Would it be practical to develop an app that used a GPS reading to lookup the elevation of your current location using NED files? Would it be a more accurate altimeter than a GPS elevation reading? I suppose Topo! on your computer does this when it shows the elevation where your mouse pointer is, but I don't think Topo! is available as a smartphone app.

[JoeGrim]

It took 8 months to process the entire USA. However, I think now it could probably do it in about 2 months, because I have developed techniques along the way to make it faster. I also had to stop it along the way to fix a few bugs.

The NED data I have is stored in 1 deg x 1deg netCDF files that are 50 MB in size. I first downloaded the data for free as binary files from the USGS: http://viewer.nationalmap.gov/viewer/ Then I converted it into a format that was easier for me to work with (netCDF). What the program did was process a 1 deg x 1deg square, expanding it by 0.5 deg in each direction to make sure it got nearly all line parents for any ranked peak it found.

From my experience, the NED files are slightly less accurate than the raw topo maps, as it seems that the NED mostly just interpolated between contours. For example, at a spot elevation marked on a topo map, it typically didn't exactly match the value in the NED file. There are a few places where the NED is more accurate, such as for quarries or landfills, where the topography has been recently updated in the NED but not on topo maps. (For example, the NED helped me discover that the highest land point in Florida, albeit artificial, is a landfill that is still growing taller.)

It would be neat if they made a GPS that used NED to determine an initial elevation, instead of using the altimeter and triangulation, which can frequently be a few hundred feet off (at least on my Garmin GPSMAP CSx.) I know nothing about making apps; my programming knowledge is in extracting information for weather forecasting from huge meteorological datasets.

[drdickie]

Wonderful!! shows great dedication. It explains how a new peak popped up in Taos County (8780) that I didn't know about. (See my previous post on 8780). I climbed it today ( a surprisingly tough little bushwhack because the area is steep and rocky with lots of little ravines bisecting the route.) Two Minor queries: 1. the actual high point is about 110 feet beyond the listed coordinates. Is that just normal margin of error or enough to merit a correction? 2. should this peak be added to the Sangre de Cristo custom list for NM?

Thanks!

Dick Oestreicher

[TWorth]

Some altimeter apps claim to use USGS elevation data already, like this one:

https://play.google.com/store/apps/deta ... .altimeter

Haven't seen any mention using NED specifically. But there are tons of altimeter apps out there.

[DSunwall]

Some altimeter apps claim to use USGS elevation data already, like this one:
.

I feel like a dummy, didn't even look. Thanks Tim. looks like DS altimeter is the only one that claims to use map data from what I see at the play store.

edit. Default altitude source is Satellites, you can choose maps but that requires an internet connection. I guess they didn't want you to have to download a crap load of data. Micro SD card can go to 64 GB, wouldn't that be sufficient?

sorry for the drift Joe. I always wondered if something like what you accomplished couldn't be done, sounds like it took a big effort and some inside knowledge.

[TWorth]

Good info Dwight, I hadn't looked enough to see that it requires internet connection. Not very useful in the mnts.

I write apps for android, this doesn't seem like it'd be hard to do, and storage for a single state would be well under 64GB. When I get some time I'll have to piece together something crude(no map, just a el reading using NED data) for you to test, then if it works, stick it on the app store at google play.

[DSunwall]

I write apps for android, this doesn't seem like it'd be hard to do, and storage for a single state would be well under 64GB. When I get some time I'll have to piece together something crude(no map, just a el reading using NED data) for you to test, then if it works, stick it on the app store at google play.

that will be great Tim, you would be the man for this task. I sent them an email asking the question here is their reply.

Hello Dwight,

The databases we use are not available as a whole or partial database
download, so you would have to individually query for every coordinate
pair in the area you will be traveling in and that would be a daunting
task! If you are aware of any elevation databases that can be downloaded
in part for a specified geographic area let me know and I'll see if we can
use them.

Sincerely,
Jordan

I did not reply.

[RyanSchilling]

Amazing work, guys! Any examples in CO?

[Peter J Barr]

Do you have a list of the 744 new ones? Would love to see if any new ranked peaks popped up in the southeast!

[Jeremy Hakes]

Wonderful!! shows great dedication. It explains how a new peak popped up in Taos County (8780) that I didn't know about. (See my previous post on 8780). I climbed it today ( a surprisingly tough little bushwhack because the area is steep and rocky with lots of little ravines bisecting the route.) Two Minor queries: 1. the actual high point is about 110 feet beyond the listed coordinates. Is that just normal margin of error or enough to merit a correction? 2. should this peak be added to the Sangre de Cristo custom list for NM?

Thanks!

Dick Oestreicher

I think an email to John to slightly adjust the coords would be worthy. Although I think he has mentioned to me that a range of somewhere around 150' on a GPS vs. coords is probably within sampling range/errors.

[Jeremy Hakes]

And good work on this! A couple of extras popped up in some counties I have completed.