I was looking at another post where there seems to be distrust in OPUS solution elevations.?ÿ I wanted to share one of my experiences.
We have been working at an industrial project site for 10+ years.?ÿ There is a first order NGS benchmark nearby. ?ÿThis monument is our Basis of Elevations, and we use it for our RTK base station.?ÿ Every time we broadcast RTK from it, we collect static data for QA/QC.?ÿ A typical observation is 4+ hours.
I send this static data to OPUS on a regular basis.?ÿ In my 10+ years looking at these results on the same monument, the OPUS elevation is typically within 0.05 feet of the published ortho elevation.?ÿ Most of the time it??s closer.?ÿ It??s worth noting that this monument was used for the geoid model in our area.?ÿ
Just sayin.
I suspect that monument also has really good sky visibility, and few obstructions?
In my experience, less than ideal site conditions seems to upset OPUS results.
Always nice to have a good NGS benchmark to work with for RTK.
We had height modernization run through MI, and there are quite a few benchmarks along the interstate/main roads. Basically concrete telephone poles in the ground. Rumor was that they didn't let the monuments settle long enough before the leveling started, and the monuments have sunk a bit. But the next line out of their mouth is always, "it was good for what it was used for, and passive monuments are going away anyhow".
I always do what the NGS does:
A first order bench on a HARN point. Works well.?ÿ
passive monuments are going away anyhow
Except when they're not. GPSonBM seems to be needing them for a longer period of time than originally anticipated. Makes me wonder if the campaign might not end in the foreseeable future. I know there is a revised 2023 deadline. What OPUS and RTN networks show us is how crappy some of our passive networks are that have not been resurveyed in 80 years and GPSonBM keeps turning up new information requiring further adjustments.
?ÿ
A first order bench on a HARN point. Works well.
Yes and no. As other left mentioned it has a lot to do with stability as well. Many of our newest first order benchmarks are no longer as surveyed due to stability. I believe we'd be better off with a low number of stability A validation marks that a high number of unstable marks to confuse the issue the older they get.?ÿ
passive monuments are going away anyhow
Except when they're not. GPSonBM seems to be needing them for a longer period of time than originally anticipated. Makes me wonder if the campaign might not end in the foreseeable future. I know there is a revised 2023 deadline. What OPUS and RTN networks show us is how crappy some of our passive networks are that have not been resurveyed in 80 years and GPSonBM keeps turning up new information requiring further adjustments.
?ÿ
A first order bench on a HARN point. Works well.
Yes and no. As other left mentioned it has a lot to do with stability as well. Many of our newest first order benchmarks are no longer as surveyed due to stability. I believe we'd be better off with fewer stability A validation marks that a lot of unstable marks to confuse the issue the older they get.?ÿ
And that's why that benchmark is checked to others which verifies stability.
?ÿ
If the mark was used for geoid development, it has both good GNSS and terrestrial/level data, its geodetic position was almost certainly derived from the same process(or) that OPUS is using, and the geoid has been constrained to that mark. That it's matching published is no surprise.
In any case, when properly used, OPUS gets you good ellipsoid heights.
Whether you get good ortho elevations is entirely dependent on the geoid quality in that particular area.
And this assumes that the mark is stable too.
?ÿ
its geodetic position was almost certainly derived from the same process(or) that OPUS is using, a
I disagree...there are many bluebook projects that have been submitted over the years that used other processors to process the baselines. I have submitted many projects processed with Trimvec, GPSurvey, TGO, TBC and maybe some others that I can't remember. I will admit that some of the older projects that used single frequency receivers without any CORS or good geoid model or precise ephemerides may not be the best to use, but certainly the more recent projects are comparable in accuracy to using OPUS, especially those that cover small areas.?ÿ
?ÿ
And that's why that benchmark is checked to others which verifies stability.
This quote should go on the elevation certificate post.?ÿ
If the mark was used for geoid development, it has both good GNSS and terrestrial/level data, its geodetic position was almost certainly derived from the same process(or) that OPUS is using, and the geoid has been constrained to that mark. That it's matching published is no surprise.
In any case, when properly used, OPUS gets you good ellipsoid heights.
Whether you get good ortho elevations is entirely dependent on the geoid quality in that particular area.
And this assumes that the mark is stable too.
?ÿ
OPUS doesn't match that ellipsoid height, its about .06-.10' different depending on the CORS used.
?ÿ
OPUS doesn't match that ellipsoid height, its about .06-.10' different depending on the CORS used.
Each CORS in the NCN has two stability plots (short-term & long-term) that prove to be really valuable when doing high precision/accuracy work.
Funny how some of the CORS are just much more stable than the others. So much so that there are a few of them that always seem to cause a network adjustment to blow up. Especially with our seasonal change.
I've only encountered one published data sheet that was truly wrong by about 3 feet on an adjusted mark. It was near some new bridge construction. Everyone was baffled and the DOT surveyed the daylights out of it to confirm. I don't know what happened after that. Last I heard, I think they talked about tearing it out.
Pretty amazing that we're at the point where a regular production surveyor can pretty easily go out and get 3d positions within the size of a golf ball, if they're careful, and within the size of a baseball if it's 4:55pm on a Friday.
OPUS doesn't match that ellipsoid height, its about .06-.10' different depending on the CORS used.
?ÿ
I'd file that under "best practices". Check the time series for the CORS before using them.
Also check the network accuracy estimates:
These are a good indicator of what can be expected.
?ÿ
And check when that mark was last adjusted:
There's a wealth of information on those datasheets that can tell us whether we should expect an OPUS observation processed against stable CORS to align with its published position, and if so by what magnitude.
Geoid and Terrestrial are coincident in many places in the United States. Collecting data there is not an indicator of OPUS??s accuracy where the two are not coincident. OPUS does match elliptical heights. Just wanted to be on the same side of those two fences.
OPUS doesn't match that ellipsoid height, its about .06-.10' different depending on the CORS used.
?ÿ
I'd file that under "best practices". Check the time series for the CORS before using them.
Also check the network accuracy estimates:
These are a good indicator of what can be expected.
?ÿ
And check when that mark was last adjusted:
There's a wealth of information on those datasheets that can tell us whether we should expect an OPUS observation processed against stable CORS to align with its published position, and if so by what magnitude.
No one I've discussed that point with locally has ever matched the bench mark with that ellipsoid height using OPUS. Even the engineer who administrates the local CORS site would complain how far off OPUS was. Then it was about .15' usually, but now it's gotten much better and you can get it down to about .06' using the local CORS only, still not good enough for me. I continue to do as NGS does on their data sheet, hold the ortho elevation and apply Geoid 18.?ÿ
?ÿ
OPUS doesn't match that ellipsoid height, its about .06-.10' different depending on the CORS used.
Each CORS in the NCN has two stability plots (short-term & long-term) that prove to be really valuable when doing high precision/accuracy work.
Funny how some of the CORS are just much more stable than the others. So much so that there are a few of them that always seem to cause a network adjustment to blow up. Especially with our seasonal change.
I've only encountered one published data sheet that was truly wrong by about 3 feet on an adjusted mark. It was near some new bridge construction. Everyone was baffled and the DOT surveyed the daylights out of it to confirm. I don't know what happened after that. Last I heard, I think they talked about tearing it out.
Pretty amazing that we're at the point where a regular production surveyor can pretty easily go out and get 3d positions within the size of a golf ball, if they're careful, and within the size of a baseball if it's 4:55pm on a Friday.
Heck, it's amazing how many local CORS aren't even there anymore. In the early days there were two main good ones, those don't exist anymore, and many more have been removed.
?ÿ
@rover83 1st order also means they probably have a direct gravity reading and it was also probably held when they did airborne gravity. Opus is good but one must understand the geoid accuracy in there area. You are spot on. It??s supposed to check.
Heck, it's amazing how many local CORS aren't even there anymore. In the early days there were two main good ones, those don't exist anymore, and many more have been removed.
All procedural jousting (especially mine) aside, this raises an excellent point - in the impending Era of Active ControlTM , how will we see NSRS users cope with reference station deactivations and removals? Additions?
We've barely had any internal discussions over NATRF2022, much less how we will handle system modifications.
I think that while the NGS is doing an outstanding job preparing the modernized NSRS, and there will be "somewhat less" need for scrutiny of the active control, we still don't know exactly how it will all play out.
@rover83 They will have say I don??t remember now exactly the terminology. But say a set of primary cors stations. Owned and operated by ngs. ?ÿThey will be the backbone of the datum. Then the coop cors like we have now owned by others and submitted to ngs.?ÿ
They have on some ran levels to cors stations ?ÿi don??t know which ones or how many or if there testing showed if it was needed or not. ?ÿ
i have heard they are that a possibility of publishing a new levels guide for using passive control then levels for better relative ?ÿ Accuracy. ?ÿDon??t know much more than that and that was unofficial statement just hearing talk. There will have to be some re thinking on how and what we do as the new datum is different altogether than what we currently work on . It will be more geodesy reading lol ?ÿ
?ÿ
set of primary cors stations. Owned and operated by ngs.
Can't let that one pass. CORS stations are not owned or operated by NGS. Owners apply to NGS to have them added to the system. Some are accepted. Some aren't.?ÿ
@norm uhm if you go to ngs website and to cors you will see that ngs ownes there own . Yes network rtk providers stream and submit to ngs i have submitted several. It tells you who owns them when you download the data sheet. NGS does have several of there own. One look at corbin va the cors station there is ngs owned. Look in Georgia egps solutions own many submitted to ngs. Some owned by others from private to counties to cities. The density comes from others. ?ÿWe can thank municipality??s and network rtk operations for the density. CORS was originally all NGS. ?ÿThe name has taken on a different meaning buy network rtk providers over time. ?ÿI think the star is the legand symbol for ngs owned ones. Then you also get the color bubble or use to for epoch rate. This is all raw data from ngs cors program.
@olemanriver I stand corrected. I thought you were saying all CORS were owned by them. In the webinar today they were explaining how to include RTK vectors from reference stations not included in CORS so my mind was elsewhere.
