I have an elevation certificate to do and unfortunately, no established benchmarks within a reasonable distance. There is a county GPS monument that was placed when the aerial photography was updated in 2008 about 1.5 miles away (3rd order).
I set a point with network RTK at the site and then occupied it for 3.5 hours to post process with opus. Set another point nearby and occupied for 4 hours with a different receiver.
I also used the base/rover setup to collect data on the county gps monument.
So far, all the elevations are within .15'.
I expect the LAG to be pretty tight to the BFE so I'm sweating this one a bit.
When I go back to collect the data, I will do a Rapid Static session for one more check.
I'm open to any advice. Thanks.
Your approach looks sound to me.?ÿ I'd say you've met the typical standard of care, and then some, with the results you've given above.
You will be fine.?ÿ Don't sweat the small stuff.?ÿ Save that for things that are truly critical.
Was the county mapping used to develop the calculations that created the flood plain data?
If so, I would suggest locating the benchmark set by the county even if it's 1/5 miles.?ÿ
See if there are red flags between the network and the base flood data.?ÿ
The process I've seen would be mapping paid for by the county, topo data from that mapping created sometime in the past (2008), then cross-sections run by someone using GPS units to help create BFE's.
That process leaves lots of room for "interesting" results since there are so many changes over a very short time with Geoid Models, GPS upgrades, ect.?ÿ
If those two data sets mesh it would be a good thing to have to solidify your elevations. BFE's to the tenth are always an iffy thing so it's good to have all the backup possible if any questions arise.?ÿ
?ÿ
?ÿ
@mightymoe Thanks.
I??ll reach out to the county engineer who is the administrator for our county. There were no FEMA linked flood studies for this flood map.?ÿ
Is the "county gps monument" a benchmark? You never clearly say.
Did you occupy the 2 new set points simultaneously for the 4 hours? That's not clear either.
Using as many sessions as necessary to directly observe and connect your new points/benchmark(s) would probably be best. Not sure if that's 3 points or 4 points at this stage.?ÿ
We would typically set the base receiver on a known benchmark and locate the benchmark with nRTK. Then start an RTK survey (logging base data) on the benchmark, set and shoot the new points with RTK & logging (5-30 minutes, depending). Finish all the other field collection with total station. Lastly, occupy the 2 new set points for 5-30 minutes, depending, to close the figure.
It seems to me that static/rapid static GPS/GNSS should be better than 0.15' at 1.5 miles. Are you post processing the data yourself, or just using OPUS on all the sessions?
Another thing to consider is dumping the short observation network RTK in favor of the long duration static. In my experience, mixing the two will degrade the overall result. It makes sense to have that nRTK position for continuity of fieldwork, but can be questionable to keep it with the other results which are likely better.
In my little corner of the planet the difference in the two elevation datums is very close to 0,42 feet higher using the "new" datum.?ÿ The 2010 revision to the FIRM took that into account and the RM1 was converted as well. Tle lines didn't move but the BFE did by that 0,42 difference.
In my little corner of the planet the difference in the two elevation datums is very close to 0,42 feet higher using the "new" datum.?ÿ The 2010 revision to the FIRM took that into account and the RM1 was converted as well. Tle lines didn't move but the BFE did by that 0,42 difference.
We have a local town where they did a similar calculation,,,,,,,,,,,only they went the wrong direction.
The difference was 2.5' and they are now 5' off. You can build in the normal high water line in some spots.?ÿ
?ÿ
?ÿ
@michigan-left The county monument has a county published elevation. My initial nRTK elevation differs .15 when shot with base/rover from a new point set at the job site. The initial opus return is within that .15 also but I am resubmitting now that it has been 48 hours. The two static sessions were staggered about 2 hours so there is some overlap.
Always flow from the knowns to the unknowns.
Using nRTK/RTK backwards for elevations (ortho heights) creates gaps/overlaps (that can be fixed/accounted for) if you know to look for them and fix them. Chasing down 0.15' seems reasonable, but it could be any number of things besides measurement error.
Your local (1.5 miles) RTK & rapid static processing results are (should be) likely tighter and closer than independent OPUS solutions on multiple points.
Since you're flowing backwards from an unknown point (new nRTK position(s)) to a known point (benchmark), it's pretty easy to fix the ortho (ellipsoid?) height(s) on the benchmark and software will compute the vectors backwards.
Static/Rapid Static takes care of this easily. If you're going to continue to use RTK, it's best to flow from the knowns to the unknowns.
The other thing you could do is do a 1 point vertical site calibration on the benchmark.
With a receiver on your site BM, at the same time your other receiver is on the County monument for half an hour, will give you much better data than OPUS.?ÿ
@oldpacer Would setting the base on the county monument and the rover on the site BM accomplish this or would the data need to be post processed?
@david3038?ÿ ?ÿNo, you would only be providing your site BM with the correction. Your vertical component would still be terrible. Do you not have post processing software?
@oldpacer No post processing software. If we have needed SPC in the past we have used OPUS for post processing.
?ÿ
You can download ??RTKLIB? and process two simultaneous sets of vectors with all of the constellations you have available and add the height difference to the county benchmark. Or if you really really like OPUS, set your receivers to collect ??RINEX??; simultaneously collect an hour of OPUS data on each; submit data; subtract height difference from the two vertical elevations and add it to the County??s elevation.
Although most on here would disagree. I have found the error numbers at the bottom of the OPUS results page to not be accurate. Simultaneous vectors will eliminate the largest of OPUS??s vertical errors. You still won??t have a good site benchmark nor will you have a check. At least hit each one with Network RTK before and after to see if you are close to your local geoid. Good Luck.
1.5 miles. Set base on bm use published value for elevation. ?ÿRtk site bm wait a couple hours repeat. Post processing would be better. But opus position might not match published by the .15. Or more or less. Oldpacer is correct your baseline from bm to site will be a lot tighter relative doing a post processing of that baseline. Fix published and let it flow. Another baseline as a ck. Is the difference of bm with nrtk and opus in the same direction or do we have .15 from nrtk to bm. And from opus -.15 to bm. ?ÿ
Although most on here would disagree. I have found the error numbers at the bottom of the OPUS results page to not be accurate.
I'm not most, but I would not disagree with you. I've always used OPUS as a horizontal check only.
Also didn't know RTKLIB did all that. Going to have to check that out now...
@michigan-left?ÿ ?ÿ RTKLIB will process a single set of multi-constelations data very easy, process a base-rover pair after you get everything just right and process multi sets after you have pulled every hair out of your head. Best thing it does is let you run a not-smart receiver out your office window while you collect rover data with only one data collector.
@olemanriver Opus differs from the nRTK by only +.045'. Base on site BM to County monument is -.12'.
If Opus elevation is used, I'm closer to .07' difference.
Opus el on site BM 687.02, nRTK 686.97. County Monument shot with Base/Rover from nRTK point is 772.26. Published elevation is 772.38 Published elevation is Geoid03 Opus is geoid18, same as my nRTK