Activity Feed › Discussion Forums › Strictly Surveying › switching from geoid 12b to geoid 18
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.
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.
- 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.
- 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.
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.
@spmpls YES! I have been doing per that article for years, it takes more than a button push, so most don’t because it takes some analysis to determine a local correction.
Also depending on project requirements, I might use current horizontal realization with the current geoid model for that realization and not tie any marks. Future work would be done the same. As long as you document what was done and others can follow it, it should all work out.
Here is a part of the puzzle I haven’t quite grasped yet. Geoid18 came about based on NAD83(2011)(2010.0). Was the old realization used or the new Multi-Year CORS Solution 2 (MYCS2) Coordinates? Maybe immaterial, BUT there are some changes in NAD83(2011)(2010.0) after implementation of MYCS2 per this NGS link.
I think one needs to be extremely cautious adopting GEOID18, there are effectively two flavors of NAD83(2011)(2010.0) now, those based MYCS1 and the recent MYCS2.
FYI, pretty much all of the geoid models since at least 1999 have pretty good relative fit over a small project area, you could mix and match any geoid with any ellipsoid realization and as long as you tied to previous control you can make it work, NOT recommended, but delta geoid heights over a small project area don’t usually change much from point A to B. What does change is the geoid model and the realization it was designed for fitting in the absolute sense better to NAVD88. Newer isn’t always better if you use the wrong ellipsoid realization and try to match old control without doing proper checks.
SHG
@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?
Log in to reply.