Community Forums

Community Forums

Share:
Notifications
Clear all

switching from geoid 12b to geoid 18  

Page 1 / 2

casualsurveyor0192
Posts: 17
(@casualsurveyor0192)
5+ posts
Joined: 2 years ago

Hello all. I recently worked with a surveyor who let me know that geoid 12b is being phased out for geoid 18. I am beggining to start this process but have a few general questions on repercussions. My workflow is essentailly, Do a static survey that is corrected with opus in with a 12b geoid, design a plan based on those coordinates in autocad (i dont think geoid is relevant in cad for this purpose but i could be wrong), put my design points in my controller and stake it in the field. 

1.) what do i do with all my old data that is in geoid 12b? If I have a design elevation at 800.3 feet that was based on 12b, and I update my controller job settings to 18, wont that through off my elevations? 

 

2.) Can I get a general overview of how NAVD and geoid 12b/18 interact with regards to elevation? I work in napa county and use their contours as a reference for projects where I do not need to be very precise (I topo a site myself for more exact jobs). their meta data is here . http://gis.napa.ca.gov/giscatalog/viewXML.asp?Name=maingis.GIS.cont_02_200&meta_style=fgdc Their altitude datum is the north american vertical datum of 1988, how much difference is that elevation relative to geoid 12b and 18? 

3.) How do I stay up to date on these changes? I also heard that the US survey feet may be going away and a new coord system is coming out in 2022. 

25 Replies
SPMPLS
Posts: 351
Member
(@spmpls)
250+ posts
Joined: 4 years ago

The differences in geoid heights between 12B and 18 vary by location, primarily because of the densification of available data used for GEOID18 resulting from the GPS on Bench Marks campaign(s). You can use this tool to compute a GEOID18 geoid height (N) for your project location, then compare that to what the geoid height was for 12B. The difference will be the amount your derived orthometric height will change depending on which geoid model you apply to the ellipsoid height(s).

https://www.ngs.noaa.gov/GEOID/GEOID18/computation.html

The area where you work has almost no NAVD88 bench marks, so it is unlikely any GPS on BM observations were done that would have changed the geoid heights in your area between 12B and 18. 

Reply
5 Replies
casualsurveyor0192
(@casualsurveyor0192)
Joined: 2 years ago

5+ posts
Posts: 17

@spmpls i got an output N of -31.095 M, or about 102 feet for a random spot on my drawing where i inserted a point. what does that number represent? elevation? Because both in the contours provided by napa county and our seperate survey data, the elevation we have is around 112 feet. both use navd88 i believe

 

Reply
SPMPLS
Member
(@spmpls)
Joined: 4 years ago

250+ posts
Posts: 351

@casualsurveyor0192

H (NAVD88 elevation) = h (NAD83 ellipsoid height) - N (geoid height).

Your computation returned a GEOID18 geoid height for your entered location of -31.095 meters. You need to compare that value with what the 12B geoid height was for the same location. The difference, if any, will be the change in your derived NAVD88 orthometric height (elevation).

 Here is the GEOID12B computation utility:

https://geodesy.noaa.gov/GEOID/GEOID12B/computation.html

 

Reply
casualsurveyor0192
(@casualsurveyor0192)
Joined: 2 years ago

5+ posts
Posts: 17

@spmpls thank you very much. Lastly, is there a magazine or publication I can use to stay up to date on changes? I heard that opus may stop processsing data for 12b, is there any truth to that?

 

Reply
Rover83
Member
(@rover83)
Joined: 4 years ago

250+ posts
Posts: 283

@casualsurveyor0192

OPUS has been returning GEOID18 on results for a while now - as of September, I believe.

Keep tabs on the NGS homepage, they will always post up changes to products and services, often long in advance.

Or, if you don't mind being notified by email, I highly recommend signing up for NGS alerts.

 

 

Reply
Surv3251
Member
(@surv3251)
Joined: 3 years ago

20+ posts
Posts: 47

@spmpls Thanks for the link. I have been trying to convert multiple points from a .txt and .csv file but it doesn't return a solution. Their examples aren't helpful either and ambiguous, so I'm obviously not following the format. Would anyone know what's the proper input format for multiple points?

 

Reply
SPMPLS
Posts: 351
Member
(@spmpls)
250+ posts
Joined: 4 years ago

The best place to stay informed on these issues is right here:

https://geodesy.noaa.gov/

 

 

Reply
2 Replies
casualsurveyor0192
(@casualsurveyor0192)
Joined: 2 years ago

5+ posts
Posts: 17

@spmpls thanks again. Looks like depending on my location, I tried one on the valley floor and one up on our highest project, the difference is about .08 ft (valley floor) and .12 feet (higher EL.) does this change in geoid height directly correlate to what the change in elevation would show had i been using geoid 18 in my surveying equipment?

 

Reply
SPMPLS
Member
(@spmpls)
Joined: 4 years ago

250+ posts
Posts: 351

xyHt Magazine -- Still absolutely free!

Dave Karoly
Posts: 10884
Member
(@dave-karoly)
10,000+ posts
Joined: 10 years ago

-----------Ellipsoid

^

|

N = a negative distance in most of California

|

-----------Geoid

Reply
1 Reply
SPMPLS
Member
(@spmpls)
Joined: 4 years ago

250+ posts
Posts: 351

@dave-karoly

Actually, negative in all of California and the rest of the Conterminous U.S.

When grading the California PLS exam years ago, one of the questions was something like "at your project location, which is higher, the ellipsoid or geoid?" An examinee answered "ellipsoid", which was correct, but then went on to state "Because the geoid is below the ellipsoid in all of the United States", which is not correct. Last I checked Alaska is in the US. They got zero points for that answer because of that incorrect statement. I always told people taking the exam to just answer the question and move on. Don't spend any time fortifying your answer and I used that situation as an example. All risk and no reward.

 

Reply
MightyMoe
Posts: 6674
Member
(@mightymoe)
5,000+ posts
Joined: 10 years ago

When I apply Geoid 18 in my area to NAD83 (2011) ellipsoid heights I tend to be closer to NAVD88 elevations than using Geoid 12b.

I normally correct the ellipsoid height to NAVD88 elevations with which ever flavor of Geoid I'm using.

In other words I fix my elevation and let the Geoid model move the ellipsoid height up or down.

Most people use the ellipsoid height and shift the elevation which causes you to have different elevations for each Geoid model, 90, 96, 99, 03, 09, 12, 18. So there would be at least seven different elevations for the same point through the last 28 years of GPS usage, or a change every four years or so. Of course each Epoch also changes the ellipsoid height and that adds to the number of elevation changes, 86, 93, 01, 07, 11. So mixing the seven Geoid model heights with the five ellipsoid heights can produce a large number of different elevations for the same point. 

Basically, you need to stay on top of the changes, if you have an ongoing design like many engineering designs are, keep good records of how you derive elevations and let the next guy know where it all came from. 

 

 

 

Reply
6 Replies
casualsurveyor0192
(@casualsurveyor0192)
Joined: 2 years ago

5+ posts
Posts: 17

@mightymoe do you know where i could find what ellipsoid my geoid is even referencing? right now in my trimble r10 tsc3 controller it is set to nad 1983, cal state plan II, and it ggives me the option to use a geoid model which i have checked, and it is set on geoid 12b. I don't see anything about an elliposide. 

 

Reply
Rover83
Member
(@rover83)
Joined: 4 years ago

250+ posts
Posts: 283

All NAD83 realizations use the GRS80 ellipsoid, but latitudes/longitudes/ellipsoid heights changed with each new realization.The NGS had to effectively compensate for the change in ellipsoid heights, i.e. ortho heights remained the same, so the geoid separation had to change.

@SPMPLS beat me to it and posted an article about which geoid to use with which NAD83 downthread. It's a must-read for anyone who does work using geoid-derived heights, especially if you work on legacy projects:

 

@casualsurveyor0192

 

Reply
GeeOddMike
Member
(@geeoddmike)
Joined: 10 years ago

1,000+ posts
Posts: 1099

@mightymoe

The practice advocated by this poster does not make sense. While in a perfect world the three heights: ellipsoid (h), orthometric (H) and ellipsoid to geoid separation (N) should sum to zero (i.e., h - H - N = 0 if all were perfectly determined), in the real world they generally do not.

 

Looking at an NGS data sheet, one sees that the source for each height type is annotated. The data sheet does NOT force any of the heights into agreement with the relationship h - H - N = 0. Take a sampling of data sheets and run the equation, most likely they will not sum to zero.

 

Using a CORS solution as an example, the NAD83(2011) ellipsoid height at the unknown represents the best determination for the day of observations with respect to well-determined positions of the CORS as well as well-determined positions for the satellites. I still like the “classic” static OPUS solution as the “peak-to-peak” differences provides a realistic estimate of the quality of the determination of the unknown’s position.

 

On NGS data sheets the vast majority of NAVD88 orthometric heights determined by differential leveling were determined decades ago. The NAVD88 network itself is acknowledged to have serious systematic errors especially the significant tilt from FL to WA.

 

As GNSS observations produce ellipsoid heights (in a three-dimensional datum like NAD83(2011) and differential leveling is based on the geoid (NAVD88 orthometric), there must be a way to link these two non-parallel height systems. They are linked by a model of the relationship of the ellipsoid to the geoid.

 

When using NAD83(2011) ellipsoid heights we use the current HYBRID geoid model (GEOID18) to best approximate an NAVD88 height. Note I capitalized hybrid above, I did so the differentiate it from the geophysical model.  While based on the geophysical model, the hybrid geoid model must account for datum differences between NAD83 and ITRF values and using sources like the GPSonBM observations (where N is computed from observed NAD83 ellipsoid heights and published NAVD88 orthometric heights).

 

What the poster proposes is to force agreement between the three heights holding the unmonitored, unverified, NAVD88 heights and the GEOID18 hybrid geoid model (already including a corrector surface containing the relationship between NAD83 and NAVD88) to change current increasingly well-determined ellipsoid heights.

 

To constrain the GEOID18 value as correct also ignores the relatively large uncertainties in the model. Using AH1762 values as input in the on-line NGS tool ( https://www.ngs.noaa.gov/cgi-bin/GEOID_STUFF/geoid18_single.prl ) yields a 2-sigma error of 0.031 meters. Perhaps the poster might use the tool to examine the values for his points.

 

 

 

  

 

Reply
MightyMoe
Member
(@mightymoe)
Joined: 10 years ago

5,000+ posts
Posts: 6674

@geeoddmike

Well, your procedure has been the bain of many projects in my area, it has caused hundreds of thousands of dollars of extra costs to projects that need not suffer from them. Holding the NAVD88 elevations instead of ever changing ellipsoid heights Geoid Models and resulting Orthometric heights creates stability. 

By using "New" elevations which were over .7' from the first order NAVD88 local bench marks used for the original mapping, significant unnecessary cost overruns were created on a project when an engineering company designing roads and reservoirs used OPUS to establish the "New" elevations instead of the mapping control based on first order marks.

Another project for a road, a surveyor placed "new" control based on OPUS and the latest geoid model and missed by .3' which is a huge number for the dirt work, totally unnecessary because mapping and control based on the NAVD88 first order bench mark system was available and was the mapping used to design, imagine the miss when you have .3' in the control.

Once again just a few years ago a different company did a topo and mapping inside of existing control using an OPUS solution, an add on building was designed and it missed the existing building by the same .3'. This was an awful totally unnecessary FUBAR and the footers and much of the work was completed before the mistake was discovered. 

 

With the new Geoid 18 models it looks like the NAVD88 elevations are now very close to being held. I work in the real world, not the model world, I don't want elevations bouncing up and down year to year, we need to build bridges, pipelines, flat grade highways, I don't want or will I accept elevations changing on my projects the way they do with OPUS. 

The datasheet for the main control point in this area shows a change of over 12cm for that point in the ellipsoid height over a short time frame, I can't use those large changes for my control. Elevations need to be stable over time, for that point the same elevation has held for 30 years, we all use it and other nearby first order bench marks. I also know that the elevations are very tight between these marks since I've done the boots on the ground leveling between them, and know they work. Could it be that the heights have changed 12cm over time because of global shifting, possibly, but I very much doubt that was the cause of the shifting. 

 

Reply
GeeOddMike
Member
(@geeoddmike)
Joined: 10 years ago

1,000+ posts
Posts: 1099

@mightymoe

 

Well, your procedure has been the bain of many projects in my area, it has caused hundreds of thousands of dollars of extra costs to projects that need not suffer from them. Holding the NAVD88 elevations instead of ever changing ellipsoid heights Geoid Models and resulting Orthometric heights creates stability. 

 

  1. If you have orthometric/NAVD88 heights use them. Why middle the issue my fudging ellipsoid heights? That is, use them with checks to other NAVD88 heights.

 

By using "New" elevations which were over .7' from the first order NAVD88 local bench marks used for the original mapping, significant unnecessary cost overruns were created on a project when an engineering company designing roads and reservoirs used OPUS to establish the "New" elevations instead of the mapping control based on first order marks.

 

2. Anyone deciding to forgo using a valid NAVD88 benchmark does not know what they are doing. Anyone using OPUS instead of a valid NAVD88 benchmark should be sued for any cost overruns.

 

Another project for a road, a surveyor placed "new" control based on OPUS and the latest geoid model and missed by .3' which is a huge number for the dirt work, totally unnecessary because mapping and control based on the NAVD88 first order bench mark system was available and was the mapping used to design, imagine the miss when you have .3' in the control.

 

3. See 2 above.

 

Once again just a few years ago a different company did a topo and mapping inside of existing control using an OPUS solution, an add on building was designed and it missed the existing building by the same .3'. This was an awful totally unnecessary FUBAR and the footers and much of the work was completed before the mistake was discovered. 

 

  1. See 2 above.

 

With the new Geoid 18 models it looks like the NAVD88 elevations are now very close to being held. I work in the real world, not the model world, I don't want elevations bouncing up and down year to year, we need to build bridges, pipelines, flat grade highways, I don't want or will I accept elevations changing on my projects the way they do with OPUS. 

4. Combining NAD83 ellipsoid heights with the GEOID18 model of the geoid-ellipsoid separation to derive a NAVD88 height is the reason hybrid GEOID models were created. The hybrid model takes the gravimetric model and “corrects” it to insure good fit with the existing NAVD88 network. Since the new model contains more data (GPS on Benchmark campaigns) and better modeling, the agreement is better. Remember that the GPS on Benchmark campaign was to obtain ellipsoid heights on NAVD88 benchmarks so the N can be determined for use in the modeling.

 

The datasheet for the main control point in this area shows a change of over 12cm for that point in the ellipsoid height over a short time frame, I can't use those large changes for my control. Elevations need to be stable over time, for that point the same elevation has held for 30 years, we all use it and other nearby first order bench marks. I also know that the elevations are very tight between these marks since I've done the boots on the ground leveling between them, and know they work. Could it be that the heights have changed 12cm over time because of global shifting, possibly, but I very much doubt that was the cause of the shifting. 

5. You are correct that ellipsoid heights changes can be hard to understand. Remember that until the FBN reobservation campaign ellipsoid heights were not well determined. Many unresolved issues exist in the older work making their values suspect. Rather than hiding the changes NGS shows them on the datasheets. More recent observations /determinations should (in my opinion) be considered checks.

6. Just like a new differential geodetic leveling project running through old points should not result in changes to the values for the old points unless there is a good reason to do so. Given the large gaps in the existing NAVD88 network of monuments and the failure to do releveling finding good checks between old points becomes problematic. You indicate you have monuments that work check one another; you are lucky.    

7. My comments were centered on your statement that you force adjustment on ellipsoid heights in order to agree with NAVD88 heights and the current hybrid geoid model. You never state what you do with the ellipsoid heights.

8. Following the NGS guidelines for the determination of ellipsoid and orthometric heights involves a series of adjustments culminating in NAVD88 heights. These adjustments are: a minimally-constrained adjustment, a horizontally constrained adjustment fixing all published NAD83 control, an NAVD88 adjustment constraining all published NAVD88 points a combined adjustment and then a free adjustment to compute accuracies. Debugging the network and control take place at all phases.

9. In no way, should any meaningful geodetic work be based solely on OPUS solutions. Beyond the process described in 9 above, there is the new utility OPUS Projects. Again single OPUS determinations are not enough.

 

The future vertical network will be ellipsoid height and gravimetric geoid based.

 

Reply
MightyMoe
Member
(@mightymoe)
Joined: 10 years ago

5,000+ posts
Posts: 6674

@geeoddmike

I've never said I force adjustments to ellipsoid heights, since Geoid03 I've fixed known elevations and let the ellipsoid height go where it will. In other words I have an elevation on a first order bench mark of 3500.00' I occupy that bench mark with a Geoid model and a it will automatically apply the geoid height of say 50'. The resulting ellipsoid height will be 3450.00' 

The OPUS number for the ellipsoid height may be 3450.30' or 3449.84' resulting in an orthometric height of 3500.30' or 3499.84'. These are typical of the types of elevation differences that I've seen, the later of .16' was the number on the local HARN point when the new local CORS station came on-line. It was during the days of Geoid 09 and there always seemed to be about .15' separation from first order bench marks elevations and CORS/Geoid 09 orthometric heights (not bad, it was getting there). A few years later NAD83(2011) came out and the ellipsoid heights changed again, then Geoid 12 came on line and the orthometric heights changed. But the elevations didn't. 

I've never cared much about ellipsoid heights, they bounce around anyway so I let them float where they will, I don't force adjust them, frankly they aren't important, its' the elevations that are important.

All the sewer lines in the city were built from the first order bench marks, all the flood control, all the DOT projects, all the FEMA maps the NAGD29 maps and the 2010 NAVD88 maps. The shift from 29 to 88 is 2.45' constantly in the urban area a bit different as you move away so the NGVD29 and NAVD88 elevations hold a relationship.  

All FEMA maps list the bench marks as control,,,,,,,,and they are the control for those maps as they used the local LIDAR mapping based on the bench marks, the elevations for each one are stated on the maps, you HAVE to use them, you CANNOT use something else and properly declare a elevation, and tenths matter. 

Flood control back in the 1960's set bench marks all over the city, the sewer system was laid out and controlled using these marks, they are tied to first order control. 

DOT bridges, the highway system, the airport is built using the first order bench mark system. I'm not throwing all that out to hold ellipsoid heights to appease...…….who exactly cares about them???

I understand some don't have good first order control, some bench marks are iffy at best, some areas are uplifting or sinking making bench marks of not much value, we have a set on the face of the mountain that I believe have shifted .2' to .4' since they were set. I get it, and I understand NGS is going to a new system. But the FEMA maps, ongoing projects, all the old data isn't going to go away for a long time. We got new FEMA maps in 2010, twenty years after NAVD88. 

The OP asked if he has to change from Geoid 12 to 18 for some reason, the quick answer is of course not. And if he has an ongoing designed project, unless he can redesign it (who is paying for that!!!!) then use the existing developed elevations and control, don't change. Be sure and keep metadata for how your project was done and pass it on. 

Occupying the local HARN point applying Geoid 12 holding the elevation, I've surveyed in a number of nearby (10 miles) first order bench marks and offset points to the vertical ones and I see from .01' to .04'. That is more than acceptable to me. As I move farther away the errors get larger and second order points are not very accurate, often I will see .15' in those. But using strictly OPUS/CORS, until Geoid 18, they never match very well. 

 

Reply
Page 1 / 2
Scroll to Top