RTN coordinate drift / variation – share your stories
For medium to long term projects, conventional wisdom in my area encourages setting multiple control monuments and calibrating/localizing to those. The weaker alternative is to trust the real time network (RTN) to be the project control for the life of the project. Wiser surveyors have spoken of occasional drift in the RTN solutions that has led to ugly consequences; thus, once burned, they now always set control monuments and calibrate. In my limited experience, I haven’t seen the drift first hand, but the CORS error data I’ve seen supports its likelihood.
Have you seen this RTN drift / variation yourself? If so, please share your story. Thanks in advance.
Todd
- 10 Replies
Early in the days of RTN here, we would sometimes see significant differences in elevation. The differences were significant enough that we stopped using the RTN, and went back to using our own local base stations with radio
In the end we put it down to our seaside location, the stations we were using (two seaside, one inland) and some poor modelling of the ionosphere along the coast.
YMMV as they say
-
This reply was modified 3 months, 3 weeks ago by jimcox.
-
This reply was modified 3 months, 3 weeks ago by
Site control monuments are critical for any construction project.
But, there isn’t any reason to calibrate to them and there’s lots of reasons to not. Any correctly set site control will have metadata containing projection parameters.
Use those, enter them into whatever flavor of control programs for your field equipment. Occupy a control point and check the others. If they don’t check then something is wrong.
If there isn’t any metadata it’s still a simple procedure to project to control points that are set with accurate geometry. That’s more advanced but still quite easy.
It’s no longer 1998 where calibration was the best way to get somewhat decent elevation control. We’ve moved way past that.
Unless your idea of “long term” is 5-10 years or more, I don’t see a problem using an RTN. Here in the PNW, we’re drifting at the rate of about 5mm/year in both N/E, but the RTN stations are drifting with it too. Local movement is the biggest potential problem, if you’re in earthquake-prone places.
Still, I’d set semi-permanent control because that’s best practices, and you’re going to need something to check into anyways.
Right now I have my hand in several projects that are 2-3+ years old, and regularly have crews check into control that was set 5+ (sometimes nearly 10) years ago on legacy projects. If there’s any “drift”, it’s well below the RTK solution error, because we aren’t seeing a clear shift in one direction or another.
I will say that we are lucky to have a top-notch RTN here in WA, though.
I’m scratching my head over the idea of setting control with GNSS and “calibrating” – there’s more likelihood for introducing error with that method than setting and adjusting control in a proper coordinate system.
“…people will come to love their oppression, to adore the technologies that undo their capacities to think.” -Neil Postman
Still, I’d set semi-permanent control because that’s best practices, and you’re going to need something to check into anyways.
Check in or regret it.
I will say that we are lucky to have a top-notch RTN here in WA, though.
Yes, we have a great RTN!
I’m scratching my head over the idea of setting control with GNSS and “calibrating” – there’s more likelihood for introducing error with that method than setting and adjusting control in a proper coordinate system.
I can see setting control with GNSS, assuming some other work is done for vertical and to verify the observations, then everyone using that as project control. We have done that occasionally, the contractor calibrates to that control. No datum issues, no projection questions, etc.
-All thoughts my own, except my typos and when I am wrong.
It is a serious concern/problem in some areas of California, especially for long term DOT projects. However, in the SF Bay Area stations can fall apart positionally over relatively short periods of time and distances. The annual velocities shown on the attached image were pulled from HTDP. The Hayward Fault bisects the stations depicted, resulting in the stations on the westerly side moving at nearly twice the rate of the ones on the east side. Additionally, several areas of California are prone to subsidence, with the Central Valley being the biggest problem. When this happens, the stations in the area don’t all “sink’ at the same rate. In what we call the “El Nido Bowl”, the ground surface displaced vertically about 2 feet between January 2008 and January 2010, which was before the major drought started. NGS CORS P565 near Delano was almost 30 centimeters lower than what the NGS datasheet reported (2010.00 epoch) in about 2016. Localized site/project control is the key to staying on the project datum. Relying on the broadcast positions is, well, pure negligence, IMO.. At least in some area of California and elsewhere.
Wiser surveyors have spoken of occasional drift in the RTN solutions that has led to ugly consequences; thus, once burned, they now always set control monuments and calibrate.
You must have something to check into. There are multiple reasons that your RTN could have a different solution…and 99.99999% of them are on your end. Regardless of the reason, if we don’t check in and verify, we will fail.
-All thoughts my own, except my typos and when I am wrong.I can see setting control with GNSS, assuming some other work is done for vertical and to verify the observations, then everyone using that as project control. We have done that occasionally, the contractor calibrates to that control. No datum issues, no projection questions, etc.
Yeah, I didn’t phrase that very well…what I meant was, if I’m setting and observing control with GNSS, then it’s going to be in a defined projection, whether published or custom, that can be set by everyone on site, so there’s no need to have the risk of multiple, differing site calibrations.
If the vertical datum is different than the RTN ellipsoid + geoid heights, I’ll publish and run with a vertical-only calibration.
“…people will come to love their oppression, to adore the technologies that undo their capacities to think.” -Neil PostmanI’ve known vendors that calibrate every day. First thing they do is take the DC and its file from the day before and calibrate over the previous calibration. Then, eventually they will call and say we have a problem with our control.
This week we are surveying a road for improvement. The survey is within our database of property monuments for the city, although it’s near the edge.
That database has a scale factor and DOT used that scale factor to set out fresh new control monuments.
The monuments are older locations and represent a mix of time from 1996-2012. Of course, the HARN, CORS, OPUS derived coordinates have some slop to them, and adding in time increases it.
From the fresh DOT points our new coordinates locations compared to our older coordinates are between .11′ to .24′ “off”. The old coordinate is always NE of the new coordinate.
It’s very consistent. And expected, not our first rodeo.
There is no expectation that this project will get built soon. Sometimes it’s more than a decade until a shovel hits the ground so those control points are essential. DOT is not going to redesign a project to make it easy to merge with some RTN. The surveyor needs to understand how to use the control correctly.
Last year, I was checking a network receiver connected to the Kentucky CORS to see what the results looked like. A nearby town has a control network published. I checked into several marks using NRTK and matched all of the published coordinates from 2010 to well within the published specs of the equipment. Several points matched within 0.02′. With a 13 year separation, the coordinates seem to be pretty close.
Log in to reply.