A few years ago (perhaps 2019) the NGS changed the way that they computed the estimated orthometric peak-to-peak errors reported on an OPUS report.
Previously three items:
- observed peak-to-peak ellipsoid value
- estimated error for the geoid
- and (perhaps) a county wide adder
combined to build an estimated error. The new method combines the observation duration, peak-to-peak ellipsoid observation, the estimated geoid error and the solution’s RMS error:
You would be correct to assume that nearly all occupations reprocessed using this new method will report higher estimated errors.
Here is an actual example, with the location obfuscated:
I made a simple spreadsheet to compute estimated errors using the new NGS method:
Here is a link to the Excel spreadsheet:
With a data table, we can look at the results of shorter and longer occupations:
It should come as no surprise that, all other things equal, even a 48-hour occupation will not match the 3cm result from 2019.
Before I suggest a solution to this higher orthometric estimated error ‘problem’, lets take a moment to compare some of the contributions other than time to the orthometric estimated error.
Baseline (distance) from CORS to your observation
When you process an OPUS observation soon after the observation completes, the nearest available CORS stations may be a long ways distant. In the example above, in 2022 after waiting 3-years to process, every possible CORS station will have posted data and the data will have been Quality Checked by the NGS. Bad stations will have been mapped out.
Closer CORS stations will typically have better matching ellipsoid elevations which in turn will reduce the reported orthometric error.
Good and Bad CORS
There are good CORS stations and bad CORS stations that suck. There are many reasons that make stations inferior:
- nearby buildings or canopy
- non chokering antennas
- antennas without matching absolute calibrations (unlisted domes)
- bad or insanely long antenna cables on the CORS stations
- old CORS station firmware
- poor mechanical mounts
- … and many more …
OPUS (generally speaking) assumes that all CORS stations are perfect. Even if they are not. So if a station has a bad position, or has extreme multipath, then OPUS does not throw the station away. OPUS assumes the station is perfect and that all of the errors are the fault of your observation.
You should look at the short-term plots for the stations in a solution and exclude stations that suck.
Rapid vs. Precise vs. Final Orbits
While the ephemeris that are used in the OPUS solution don’t matter nearly as much as they used to, you may get a cleaner solution by waiting for precise orbits to become available, usually 15-days after the end of your observation.
Geoid accuracy
For the example above, the original solution was computed with GEOID 12B:
And the second solution used GEOID18:
The estimated error for GEOID18 is 1cm better than GEOID12B. But as you have seen, this does not translate into a smaller orthometric error estimate.
Solution: getting a lower error estimate
If your original occupation spanned longer than 4-hours, it will be possible to break it half and submit each half as a separate session into an OPUS-Project project.
While it would certainly be better to collect the raw observations on two separate days; or do morning/evening splits, with disparate physical setups; splitting the observation into two 2-hour or longer sessions will work.
Here are the results of the OPUS Project using all default settings:
with a 2.2 cm orthometric error estimate.
So, while the new OPUS-Static computation method for orthometric height estimated error may not get you where you want to be, OPUS-Projects probably will.
iG GPS 