-
Trimble Access Site Calibration
The project I posted about earlier (thanks to all for the suggestions on getting a JXL that my version of TBC can read!) is required to match existing control along a 10-mile corridor. The field guy used a Trimble R10 and Access with a nearby CRTN mountpoint to observe 5-minute RTN sessions at each of 12 control marks along the corridor, then went back to the beginning and observed another 5 minutes on each. The resulting coordinates revealed a pronounced tilt to the existing control (about half a foot from one end to the other, pretty evenly distributed), so the field guy used Access to calibrate to the existing control. That produced vertical residuals of less than 0.05′ at all 12 control marks.
I was asked to check the calibration. (Calibrations make me nervous, because there are a lot of things that can go wrong.) What I did was post-process the raw data from the receiver (thanks to rover83 for helping me find the .t04 files!) against two nearby RTN mountpoints — fixing the positions shown in the CRTN database — and compare them against the RTN vectors extracted from the JXL.
The first head-scratcher: there’s a vertical difference between the RTN vectors and the post-processed vectors of about 0.35′ (RTN is lower).
The second head-scratcher: the JXL shows a mountpoint ellipsoid height that’s 1.05′ lower than the height shown in the CRTN database.
GEOID18 was used in all cases.
Digging into the JXL, the vertical adjustment parameters of the calibration show a vertical constant of 0.44′, which very nearly equalizes the differences between the RTN and post-processed vectors.
Applying the tilted plane parameters from the JXL to the post-processed ortho heights produces essentially the same results as the Access calibration, so I think the calibration is okay. But I’m still wondering why the mountpoint height is a foot low in the JXL, and why a 0.44′ boot is applied to the ortho heights calculated by Access.
Any thoughts?
-
12 Replies
-
WOW!!
That’s terrible!!!
I do this all the time and expect to see differences <.04′ in elevation checking 10 mile corridor control for DOT projects. That’s using Geoid 18 vs. level control. Those checks are RTK and I might extend my checks up to 4-5 miles from control. Seeing .5′ would throw the entire project into re-survey territory.
-
A couple of things I thought about, bearing in mind that while I interface with my colleagues in our CA offices fairly regularly, I’m not an expert on the area:
-is the CRTN broadcasting ARP vs publishing GRP heights? (not likely I know)
-did the crew maybe choose a mountpoint that is broadcasting a different epoch? That’s what my money would be on
I’m not sure why PP vectors would be that far off from the the RTK vectors, unless there’s an epoch issue and you’re seeing the effect of the stations involved being adjusted in different directions. Are you comparing them after clearing the calibration? (Shouldn’t make a difference, but still…)
In Access, there’s no way to change a mountpoint when opening a connection and starting an RTN survey; whatever they are broadcasting is what you get, so it is almost certainly an CRTN issue. Running a calibration will modify the Local value (and then project to Grid), but not the Global that is transmitted by the RTN.
As far as the tilt + elevation issue….did they pick a single-base or true VRS/network mountpoint? If they were going 10+ miles away, I could see a single-base solution drifting off as they went further and further away. That being said, that distance isn’t *that* far…
As a general rule, if the values being calibrated to are good vertically, and the geoid is good in the area, just a vertical shift + geoid solution should work.
And on that note, personally I am very wary when I see a tilted plane solution for a corridor project. Lots of potential for problems. But it might be fine for your project goals, and if the parameters are not unusually large, you’re probably ok. I’ve done several when it was clear the local control we were working with had some systematic errors, and it was just not possible to change their values. Still I don’t like it.
How much tilt are you seeing?
“…people will come to love their oppression, to adore the technologies that undo their capacities to think.” -Neil Postman -
I have never like site calibration in a linear fashion. Any error in control plus error in measurements to tie compounds . I saw a 8 mile project that had a few hundreths in vertical on one end to the other get up to the .5 ft in vertical. At other end. I could hold one point vertically in the middle and let the geoid do the rest after the shift and i was under a tenth every where then.
That .35 process vs rtn. Could be just an ellipsoid error or ck the measure up. Quick connect vs bottom antenna mount va apc. If the original control was set with rtk rtn why do a calibration. Just re observe and find if it all matches or not.
-
You don’t mention how the original control was established, maybe don’t know?
The adjustment software in older versions of Trimble office software (going back to trimnet) had rotations turned on by default. This could produce pathological results on a linear project where benchmarks are nearly colinear. Any slight error in the benchmark elevations or the GNSS observations on the benchmarks, whether RTK or static, could produce large rotations in the direction perpendicular to the long dimension.
In the days before good geoid models it was always necessary to compute tilts (slope of the geoid surface i.e. deflections of the vertical). So it was good practice to spread out benchmarks in 3 or 4 directions, and to have some outside of the project area. I have seen a number of networks where they had BM’s along a linear highway, and did not pay attention to the resulting rotations and got results similar to what you are describing, or worse
Now that we have a good geoid model, at least in the US, I would recommend to always turn off the rotations, as they are not necessary. I do projects outside of the US, where there are no good geoids available, and that is a different story.
When one does a calibration, it is doing something similar, computing rotations to fit the BMs. If the project is linear, it can result in what I describe above.
That is why I am against using calibrations in the field.
Just my opinion on what could be happening…
-
Nice catch. I didn’t think of that. Trimnet. GPSurvey. Color pencils and a map planning projects and who goes where when. The days of planning now i can draw pretty lines on google earth and plan and send a kml to the guys. Times have changed.
-
I get the linear-calibration concern, that’s why calibrations always make me nervous. But the agency (Caltrans) has specified that their control values are to be used (“NAVD88 vertical values are provided based upon GNSS observations constrained to exiting Caltrans record elevations”), so we’re working with that.
The rapid-static vectors (which all fixed nicely) from two different CORS using GEOID18 agree closely with the RTN vectors regarding the amount of control tilt along the corridor. Since all of the work will be inside the highway ROW, I’m thinking that any side-to-side tilt introduced by the linear calibration won’t amount to much.
I learned this afternoon that I made a two bad assumptions:
1. I thought the field guy was using the CRTN caster, but he was actually using the UNAVCO/GAGE/NOTA/Whatever caster. Same mountpoint, but UNAVCO’s ellipsoid heightis 0.434 m (1.424′) lower than the CRTN value.
2. What I thought was a 0.444-foot vertical constant in the JXL calibration values is actually a 0.444 m (1.457′) constant. So the calibration is adding back the difference (within 0.03′) between the UNAVCO +GEOID18 ortho height and the CRTN+GEOID18 ortho height to get to the Caltrans ortho height once the tilted plane is accounted for.
I still haven’t resolved the 0.35′ difference between RTN vectors and post-processed vectors. But as long as the field guys can reliably hit the Caltrans control within spec I guess I’ll live with it.
-
So do they have some type of shift or ldp or using a different ellipsoid than grs80. I am not familiar with what is being done on datum side out there. But I assume since caltrans has a different ellipsoid height something is different than straight up nad 83 2011. Probably why yall out there have a better understanding of datum’s velocity’s etc than where i am located. Sounds interesting. I might have to just look up this and read on it for fun.
-
UNAVCO operates in ITRF, or at least all of the static data I have ever downloaded contained an ITRF position in the RINEX header. Causes headaches for us when someone new or inexperienced grabs a UNAVCO download in TBC, rather than the corresponding NGS CORS download for the same station. Had a few projects that were inadvertently processed using ITRF values rather than NAD83.
Still doesn’t explain why the LL would be the same but the height different…that makes me wonder if there actually is a ground mark.
“…people will come to love their oppression, to adore the technologies that undo their capacities to think.” -Neil Postman -
Man, I love that I can find a couple monument cases using street views, grab their LL, transform, and hang my calculated plats/subdivisions/ROS off of it in C3D, and get the crews to within a foot or two (often less) of every other monument in that area.
I still see surveyors sending 5000/5000 calcs to crews (cogo points rather than lines, no less) and telling them to calibrate or translate/rotate in the field…but my crews seem to like being able to just walk up to a calculated position and find each mon without any fuss. Saves time and $$$.
Not to mention they can look at aerials or street views right on their controller, with the calc lines overlaid, and simply stake to the lines/vertices.
“…people will come to love their oppression, to adore the technologies that undo their capacities to think.” -Neil Postman -
@rover83 ohhhh now i see. ITRF Now I see . So i guess yall have to open Rinex in note pad to ck headers often then. To edit etc. I am trying to remember now the tilt globally between wgs84 and itrf but that was many years ago now and it was a headache. Its where science and politics meet sorta issue. I reckon once the new datum comes out except for older on going projects might solve some of the issues. Yall have some interesting things to deal with. Here its not near the issues. Mostly grid ground and scaled coords vs non scaled which all look the same . LDP’s are not even discussed. Its pretty common practice that you just pick a point in center of project and scale to ground and break out the gun. I mostly keep crews on grid for everything. I work the magic at office side. So they can use gnss or robot for everything and don’t have to switch back In forth between a projection and scale 1.00”””” settings in dc. A few jobs like anchor bolt layout its ll just a project coordinate system so all total station and tape work so no gnss on those. Just tie to existing building and calc it and move on.
-
@rover83 Yeah on lines vs points and translate rotate I took some shape files not long ago from county gis. Brought them into tbc. Took deed comped it up moved it close to gis. Made a gut feeling on about how off the gis was. Just from doing the same county work. Told the guys to search and made sure they understood its a guess Showed them how to move the dxf in access as they found control if the wanted but like you said it was all under a foot. So close enough for them to wave the magic yellow wand to find corner’s. Much easier for sure. I just have to harp on them to look for other evidence besides just the corner pins like blazed trees fences etc.
-
If you have a long semi-straight corridor, it would be helpful to plot the Geoid Heights along the corridor on a graph. Once that’s completed draw straight lines between points and find out if any combination of calibrated points will follow the graphed line. I suspect none of the points will accomplish a precise calibration. This is a technique I’ve used since the early days of calibrations. I never found a site locally that would work to an acceptable precision. Some longer ones produce errors in feet when pushed out miles.
Log in to reply.