I am going to be involved in doing some static observations on an older USC&GS triangulation station on a peak. The elevation on the point was established by vertical angle only when the triangulation was done. I do mostly flat land work and the elevations I derive from OPUS are very good when done on existing bench marks to compare. Is there any other consideration I need to have when doing static on mountain peaks? I'm still in the planning stages, so appreciate any input or advice.
depends on the mountain. If it is a large mountain, there could be unmodeled features in the geoid, and it is the geoid model that determines the orthometric height.
There is a point in western Maryland (DAN, PID=JW1512) that is an apparently stable mark in a rock outcrop on top of a mountain range (not anywhere near as big as mountains out west, but high for the eastern US).
It has been GPS'd and leveled to. I used it on several projects, including a few bluebook projects, but not recently. The GPS derived orthometric height was about 0.1 m or so different than the published NAVD88. I was about 90% sure it was a geoid problem, but the other 10% of me thought it could be a leveling issue, one way all the way up the mountain and then back down again. I haven't used it in years, so I don't know if NAD83 (2011) and GEOID12B resolved the problem.
Without any leveling or gravity measurements in the region, I don't think you'll have any way of knowing what kind of elevation accuracy OPUS will deliver. Interpolating geoid separations within a homogeneous landscape is one thing, but when you stick a mountain in the middle all bets are off.
The upside (that's a pun) is that it might not matter -- water's going to run off the mountain no matter how inaccurate your elevation is.
To get a better elevation of something like Mt Everest they will GPS it, and tie it to BM's around the mountain (usually quite far away). I have always wondered how they account for the disturbance to the geoid by the mountain itself. I guess they could take gravity readings, but that would mean hauling a gravimeter to the top and also getting readings around the mountain peak.
The NGS is doing their third and final geoid slope validation survey next year in Colorado, across a high mountain pass. Their previous surveys were in Texas (flat, boring) and Iowa (flat, but a more interesting geoid). They will do first order class II levels along a test line, extreme GPS (LONG sessions, multiple occupations), and deflections of the vertical at each point. The idea is to see how well they can model the geoid (trying to get 1 cm accuracy over the whole country). Once they are done flying GRAV-D, that should improve things in areas where there are no level lines, gravity stations, or people (i.e. in the mountains)
That Iowa line was about 10 miles from my house. I wish I'd have been able to catch them at work and watch.
Perhaps this thread is a place to ask a stupid question that's been bothering me. NAVD88 must have been computed using some (unnamed?) gravity/geoid model to apply orthometric corrections to the level data, and compute where the geoid is underground, no? So how is it still NAVD88 when you use a newer geoid model? I'd have expected datum tags NAVD88(xx) similar to those on NAD83(xx)
I have been having pretty good luck with Geoid 12 on the mountains.
The last few we did were about -0.15' low compared to NAVD88 bench marks-these were between 7500-8500 feet and in two different areas of the mountain.
At this point NAVD88 is the basis, OPUS is the rough approximation so if there are some bench marks anywhere near the mountain I would tie them in also; you would get an idea how accurate the Geoid model is.
If you tie them and you are consistently low or high you know the Geoid model is doing a good job getting the slope correct.
Bill93, post: 384633, member: 87 wrote:
Perhaps this thread is a place to ask a stupid question that's been bothering me. NAVD88 must have been computed using some (unnamed?) gravity/geoid model to apply orthometric corrections to the level data, and compute where the geoid is underground, no? So how is it still NAVD88 when you use a newer geoid model? I'd have expected datum tags NAVD88(xx) similar to those on NAD83(xx)
Bill,
Yes, NAVD88 IS based on ITS own gravity model:
http://www.ngs.noaa.gov/TOOLS/Navdgrav/navdgrav.shtml
Some years back (~15 or so), I used the above link to generate a grid (500 or 1000 meters, I don't recall), over the State of Utah. I then "contoured" the data and created an AutoCAD drawing of the results. It was a mind blowing exercise to say the least.
What would be very interesting at this point, would be to generate a "new contour map" using the most recent gravity model, and overlaying it on the NAVD88 Gravity Model (map). I will bet dollars to dog turds that the difference will blow some minds.
Loyal
Bill93, post: 384633, member: 87 wrote: That Iowa line was about 10 miles from my house. I wish I'd have been able to catch them at work and watch.
Perhaps this thread is a place to ask a stupid question that's been bothering me. NAVD88 must have been computed using some (unnamed?) gravity/geoid model to apply orthometric corrections to the level data, and compute where the geoid is underground, no? So how is it still NAVD88 when you use a newer geoid model? I'd have expected datum tags NAVD88(xx) similar to those on NAD83(xx)
They fit the geoid model to NAVD88 benchmarks that have been GPS'd, this is called a hybrid geoid model. So the NAVD88 remains the same (but each time there are more benchmarks with GPS), sometimes the ellipsoid heights change (get better), and the gravity and topo data get better.
John Hamilton, post: 384641, member: 640 wrote: They fit the geoid model to NAVD88 benchmarks that have been GPS'd, this is called a hybrid geoid model. So the NAVD88 remains the same, sometimes the ellipsoid heights change (get better), and the gravity and topo data get better.
John is spot on (as usual). The "tweaking" of the gravimetric model to "fit" the [GPS on] NAVD88 Bench Mark data has been the key to maintaining (and improving) the GEOID Models overs the years (relative to NAVD88).
Loyal
Loyal, I Imagine you have a good feel for how G12B works in the mountains....
John Hamilton, post: 384645, member: 640 wrote: Loyal, I Imagine you have a good feel for how G12B works in the mountains....
I dunno about that John...;)
I "contour" each Model as it is released, and each one "appears" to model the mountainous areas "better." As you know (and others have pointed out), there is NOT a lot of Bench Marks in the mountains, and MOST of the ones that still exist, are OLD, and often are USGS BMs that are not in the NGS database. Most of the Leveling done in my neck of the woods was performed between about 1890 and 1935. There ARE a few 1960s/70s circuits, and of course the 1980ish circuit that follows (more or less) the 1869 Transcontinental Railroad through Nevada, Utah, and Wyoming. Nevada actually has MUCH more [modern] Leveling (NGS 1980s) than Utah does, including a North-South Circuit.
Loyal
LSAW sponsored the re-measurement of Mount Rainier, the highest peak in Washington state. One of the industry rags did an article on it.
Although I wasn't personally involved, I know several of the surveyors who were and would be happy to help you find answers to any questions you might have; just let me know.
Doug Casement, PLS
I've been trying to explain to the folks of a mountain county that using GPS ellipsoid heights and geoid separations is not a good idea for floodplain certs. It only works for those stations that are control stations used in GEOID12B (hint precise levels were run through them). In other areas the lack of gravity data will give them a poorly modeled NAVD88 elevation. The western boundary of the county is the Continental Divide.
