I may never have noticed in the past but is it usual for an OPUS ortho height error to be 70% greater than the elliptical height error?
This is for an EC so height becomes the critical factor.
Did not have the greatest sky view on this project so we ran a level loop from a FIRM Reference Mark to the project. By holding the RF NGVD 29 elevation in my post processor the project BM is within 0.01' of the level run.
Converting OPUS ortho 88 to 29 with VERTCON puts elevation with 0.09'.
Wondering why OPUS is so unsure?
Paul in PA
I have noticed this same thing in the past. I thought it was a statement as to the quality of the geoid for the area?
All GPS processing solves for ellipsoidal coordinates (XYZ and using the reference ellipsoid parameters: latitude, longitude and ellipsoid height). OPUS (static) reports the peak-to-peak error that is merely the differences in coordinate components.
As all should know, we approximate an NAVD88 height from an NAD83 ellipsoid height via a model of the ellipsoid-geoid separation. In the US this is GEOID2012A. This model is obviously not perfect.
It follows that the OPUS solution reports an inflated uncertainty in the NAVD 88 height to reflect the fact that in addition to the uncertainty in the ellipsoid height we must account for the geoid model uncertainty.
Also note that OPUS uses the geoid model to solve for the separation at the solved geographic position. It does NOT model or otherwise do any fitting to derive a better separation value.
Determining an accurate NAVD 88 height using GPS involves network observations and adjustments including accurate NAVD BMs in the network.
I do not know how the FIRM reference mark was derived. Comparing a NAVD 88 derived from it requires such knowledge. Using VERTCON is also problematic when performing comparisons given its uncertainty.
I do not know how the FIRM reference mark was derived. Comparing a NAVD 88 derived from it requires such knowledge. Using VERTCON is also problematic when performing comparisons given its uncertainty.
Just a quick overview to explain how one FIRM was created. I was hired to do ground control and set up a control point for a GPS unit to occupy during LIDAR flights. This would be a rather extensive mapping job to cover the city and areas outside. One foot contours were generated from this mapping which is getting almost 10 years old now. This mapping is what was used to generate data for the new FIRM maps. To supplement the topo data creek cross-sections were also run, those were done by other parties and I have no idea when they were done or what the elevation control was for those only that it was "GPS".
Panels were set for ground control and additional photo ID points were later added when the photo people asked for more. These were all controlled with static GPS holding the first order bench mark system monuments for elevations, HARN for horizontal, and GEOID03. Redundant measurements for each panel and photo ID point were taken and then the values adjusted.
All this data was given to the client and they must have somehow given it to the FIRM people to use to create the flood maps, but no one ever asked me how the data was collected beyond a metadata statement sent in with the coordinates.
On the FIRM the only elevation points shown are the available bench marks from NGS, some still there some not, none of the panel points are shown.
If you use those bench marks, their NAVD88 values and GEOID03 you will be on the elevations that created the mapping. Of course the LIDAR points have error in them like any LIDAR and there is the issue of how the heck were the GPS surveys for the cross section data collected and what elevation basis did they use.
All in all the maps using the topos look "pretty good" to me, it's the FEMA maps outside the topo areas that are such a disaster.
If you use OPUS and Geoid2012 you will not match the FIRM because you will be higher than the bench mark system. Why that is difficult for some surveyors to realize is beyond me (apples to apples guys), you do better if you tie the nearest CORS point and reduce your own elevation, if OPUS is applied the elevation shifts a bit up from the Single CORS point solution, but neither works that well.
Geoid models are much better than they used to be, but they aren't perfect. You need to decide with each survey just what you need to hold, bench marks or GPS derived elevations, they are probably going to be different. At least in my part of the country they sure are. For the FIRM maps I don't have to think about it, I already know the proper system to use and it sure isn't OPUS and Geoid 2012.
I Have An EC/LOMA Coming Up...
...at the junction of 4 FIRM Map Panels. The only reference mark is an NGS monument about 1.5 miles from the site. It has very clear sky as does the site. I am about 4 miles from the nearest CORS, so I expected no GPS problems. Confidence in the conversion to NGVD 29 is a concern.
The problem site on Friday was also about 4 miles from a CORS. With the trees there my point to point solutions were problematic (satellite commonality), so I relied on CORS to each point independently. I have done that in the past with good results, but I had traversed through the points. That is not the case for the Friday observation as no traverse was done, only the 1/4 mile level run.
Paul in PA
I Have An EC/LOMA Coming Up...
You are getting much better verticals than I do. Opus results vary from .25' high to .6' high. CORS results, if I process myself from the nearest CORS points, are better but not great.
So I don't use them and use only the bench mark control, then I know I'm good when it comes to the FIRM maps, and no I don't check OPUS each time, it is too exhausting to pick through bad data on every job.
