At the company I've worked at in the past SOP to establish vertical control has been to check into two vertical NGS benchmarks with RTK and then set site benchmarks that will be used for on-site vertical control. Supposing I don't have an RTK setup, are static gps observations an acceptable way of establishing vertical control for a design topo project? Any guidelines or recommendations?
Sent from my XT1031 using Tapatalk
RPLS#, post: 418304, member: 12280 wrote: At the company I've worked at in the past SOP to establish vertical control has been to check into two vertical NGS benchmarks with RTK and then set site benchmarks that will be used for on-site vertical control. Supposing I don't have an RTK setup, are static gps observations an acceptable way of establishing vertical control for a design topo project? Any guidelines or recommendations?
Sent from my XT1031 using Tapatalk
"Given enough time", static GPS results are generally going to be more accurate than RTK shots anyway...
Static observations are not only acceptable, but preferred over any flavor of RTK. RTK cannot be used to establish any type of control, especially vertical, where I work, and a minimum of 3 control points are required to be used, preferable 4, and they must completely encompass the project area. Check out NOS NGS-58 and 59 for guidelines for vertical control work.
RPLS#, post: 418304, member: 12280 wrote: At the company I've worked at in the past SOP to establish vertical control has been to check into two vertical NGS benchmarks with RTK and then set site benchmarks that will be used for on-site vertical control. Supposing I don't have an RTK setup, are static gps observations an acceptable way of establishing vertical control for a design topo project? Any guidelines or recommendations?
Sent from my XT1031 using Tapatalk
It doesn't really matter all that much, so long as the vertical control, ON SITE, works well.
I have, in the past, brought in vertical control via OPUS, or with a static tie to a vertical benchmark, or with a VRS network solution. In EVERY case, all of the bench marks (minimum three so you can tell which one is wrong when some yellow painted machine hits one) are ran and adjusted so they work with an of themselves. I've never had an instance whereby the vertical datum HAD TO BE NAVD88, but in EVERY instance, the TBM's had to work.
It seems that surveyors are becoming lazy to run a level loop from a benchmark to work site.
FrancisH, post: 419012, member: 10211 wrote: It seems that surveyors are becoming lazy to run a level loop from a benchmark to work site.
And other surveyors are too lazy to learn how to use GPS and understand geodetic heighting techniques.
I love to run levels--it's probably my favorite surveying task period. But it's rarely possible to justify the cost of long level runs. If running levels saved my clients money and made me money, I'd do it.
RPLS#, post: 418304, member: 12280 wrote: At the company I've worked at in the past SOP to establish vertical control has been to check into two vertical NGS benchmarks with RTK and then set site benchmarks that will be used for on-site vertical control. Supposing I don't have an RTK setup, are static gps observations an acceptable way of establishing vertical control for a design topo project? Any guidelines or recommendations?
Sent from my XT1031 using Tapatalk
Would you process your static session at the site against the NGS benchmarks or against CORS / network solution?
FrancisH, post: 419012, member: 10211 wrote: It seems that surveyors are becoming lazy to run a level loop from a benchmark to work site.
Lazy or not, I wouldn't base any vertical control on a single bench mark without first proving it hadn't been disturbed somehow. Multiple simultaneous static GPS observations on several benchmarks would be far and away the most cost effective way to do that. One of our more prominent engineering firms took in the shorts years back basing a dam height on a single vertical benchmark, that turned out to be .6' above it's published values and led to significant property damage from the resulting flooding. RTK would be 'quick and dirty' in my book. A level loop off a bogus benchmark might close perfect and still be significantly off.
squowse, post: 419018, member: 7109 wrote: Would you process your static session at the site against the NGS benchmarks or against CORS / network solution?
I would recommend you take the OPUS projects class. You will see a flow for holding local benchmarks.
But it's rarely possible to justify the cost of long level runs. If running levels saved my clients money and made me money, I'd do it.
hey,tell you what,let's just get a topographic map off the USGS site for your client's site and save him a lot more money.
costs are costs, you either pay them to get what you need. you get what you paid for... as the adage goes.
RPLS#, post: 418304, member: 12280 wrote: At the company I've worked at in the past SOP to establish vertical control has been to check into two vertical NGS benchmarks with RTK and then set site benchmarks that will be used for on-site vertical control. Supposing I don't have an RTK setup, are static gps observations an acceptable way of establishing vertical control for a design topo project? Any guidelines or recommendations?
Sent from my XT1031 using Tapatalk
RPLS,
A lot depends on what you are trying to accomplish and eventually publish.
I often use RTK for control but it is never based on a single observation. Thats a separate conversation.
We use static GPS quite a bit. If i am bringing in an elevation fir a 1A certificate and publishing to a decimeter, its fine to run two OPUS RS solutions and call it done. If its to establish real elevations I will occupy local control and process the static campaign as a network (including a check or checks on additional control). This is in areas where the Geoid model of the day hasnt had reports of issues. In our terrain we can establish valid vertical control faster and more accurate with static GPS than most crews can with high end equipment. On the flats by the coast the reverse might be true. Might...
Of course the gold standard is closed loop through multiple benchmarks. That is completely unnecessary for most of what i do. We save it for monitoring and a few other select chores.
squowse, post: 419018, member: 7109 wrote: Would you process your static session at the site against the NGS benchmarks or against CORS / network solution?
Pick one and state what you did. I will usually go with the closest Posted Benchmark as it is the most likely to be checked conventionally. However, I see nothing wrong with an OPUS solution. Even if it may be upsetting to an Indonesian Fruit Fly.
When you mention using Posted benchmarks, I hope you are not referring to POSTED benchmarks using the NGS nomenclature. See page 8 of the following PDF: https://www.ngs.noaa.gov/DATASHEET/dsdata.pdf
Note in the screen capture below the mention to "Use with caution". Worse option than an OPUS-derived NAVD88 height. Neither is well attached to the network of leveled monuments.
Pedantically,
DMM
GeeOddMike, post: 419187, member: 677 wrote: When you mention using Posted benchmarks, I hope you are not referring to POSTED benchmarks using the NGS nomenclature. See page 8 of the following PDF: https://www.ngs.noaa.gov/DATASHEET/dsdata.pdf
Note in the screen capture below the mention to "Use with caution". Worse option than an OPUS-derived NAVD88 height. Neither is well attached to the network of leveled monuments.
Pedantically,
DMM
You are correct. That is not what I meant in posted as in NGS nomenclature. I meant an established elevation that meets the requirements necessary for the specific Project. I have no problem with an OPUS derived Elevation. I wish every reviewer that I deal with thought the same way.
Isn't the purpose of using published elevations from govt benchmarks is that you want your project elevations to conform to a national datum?
Meaning every future/past survey no matter who/when it was surveyed would match your datum if it was started from a national control point.
If you are going to use RTK/Static, you have an intrinsic error from the get go of 4-5 cm +/- 1 part/million. Now that error is the PUBLISHED error, the actual real world working man error is larger than that published error.
This error gets larger as the benchmark is located farther away from your project location.
So if your project needs accuracy to be in the 1st order level (4mm closure/km) then your rtk results won't cut.
And you know what's worse? Every time someone does an RTK check, values WILL NEVER BE THE SAME.
FrancisH, post: 419219, member: 10211 wrote: Isn't the purpose of using published elevations from govt benchmarks is that you want your project elevations to conform to a national datum?
No. It's to facilitate the use of GIS data in the design process. Close enough is good enough.
BTW, I am confident that I can get a lot closer than 4-5 cm in the vertical using RTK. More like +/- 1 cm.
FrancisH, post: 419219, member: 10211 wrote: So if your project needs accuracy to be in the 1st order level (4mm closure/km) then your rtk results won't cut.
Achieving First Order accuracy depends upon a lot more than error of closure, but that's beside the point. Very few projects require that kind of datum accuracy or can support the costs involved. Most only need accuracy with respect to some datum -- typically a local realization of a published datum -- within a relatively small area, which opens up options for meeting the requirements. GNSS positioning, in either static or RTK flavors, are often suitable for the purpose. Defining rational specifications and using the appropriate tools to meet them is the name of the game.
I would also agree that the bench marks on site must work within themselves, that's gotta happen. But unless, you're in a flood zone, the number on the elevation is mostly irrelevant.
A dozen OPUS sessions won't return elevations as good as a few RTK ties to good bench marks
FrancisH, post: 419219, member: 10211 wrote: Isn't the purpose of using published elevations from govt benchmarks is that you want your project elevations to conform to a national datum?
Meaning every future/past survey no matter who/when it was surveyed would match your datum if it was started from a national control point.
If you are going to use RTK/Static, you have an intrinsic error from the get go of 4-5 cm +/- 1 part/million. Now that error is the PUBLISHED error, the actual real world working man error is larger than that published error.
This error gets larger as the benchmark is located farther away from your project location.
So if your project needs accuracy to be in the 1st order level (4mm closure/km) then your rtk results won't cut.And you know what's worse? Every time someone does an RTK check, values WILL NEVER BE THE SAME.
I can tell
