1-point vertical ca...
 
Notifications
Clear all

1-point vertical calibration accuracy

101 Posts
33 Users
0 Reactions
26 Views
(@duane-frymire)
Posts: 1924
 

algallop, post: 368370, member: 8394 wrote: My boss, a licensed surveyor for many years, taught me that in order to get accurate vertical readings while performing an RTK survey, you have to calibrate on four or more points with good vertical solutions. However in practice, I have done RTK surveys calibrating on only one point vertically and checked it with a level and/or total station, and found that the WGS '84 projection (both in SurveyPro software and Trimble Access) works pretty well establishing an accurate vertical plane.

I would like to perform topographic surveys with our R10 equipment using a 1-point vertical calibration, but first I have to convince my boss that it is accurate... Can you guys give me some convincing feedback that it's safe to do this?

I'm sure it's not as simple as I am making it sound, and I'm not an expert in GPS technology or anything. I just know that in my experience, a RTK 1-point vertical calibration is just as accurate as a level or a total station (at least when you are only working within a relatively small area, maybe not over miles and miles).

Thanks in advance,

Arthur

I'm not sure all are using the same terms in the same manner in this thread, but could be. Here's a short paper that may be of use. Of course 2008 is a long time ago in GPS technology terms. Maybe there's an update to this. NYS DOT survey guidelines 2009 are similar to this.

Attached files

guidelines gps derived ortho elev NGS592008069FINAL2.pdf (562.6 KB) 

 
Posted : April 21, 2016 2:48 pm
(@loyal)
Posts: 3735
Registered
 

JaRo, post: 368640, member: 292 wrote: Loyal,

Is this map available for the state of Texas that you know of? It sure would be handy for instructional purposes.
Just googling "geoid contour map texas" I found a few but nowhere near the detail of the Utah map.

James

Not that I know of.

The "image" that I posted above is just a "screen shot" of a 3D AutoCAD drawing that I created as follows:

I Generated a NAD83 UTM grid (500 or 1000 meter spacing, I don't remember off hand).
I then converted the UTM coordinates to Lat/Lon and saved it to a NGS Type 2 ASCII file (file A).
I then ran the Type 2 file through GEOID12a which produced another ASCII file (file B)
Then I wrote a simple BASIC program to read files A & B, (combining the two) into a QuickSurf .qs file.
I then used QuickSurf to generate a 0.1 meter Contour Map in AutoCAD.

I created "file A" back in the GEOID99 days, so each time the NGS releases a NEW geoid model, I simply run that file through the new NGS program, and create a NEW AutoCAD drawing.

So the AutoCAD file is expressed in UTM (Zone 12) coordinates in meters, both horizontally and vertically.

Loyal

 
Posted : April 21, 2016 3:01 pm
 jaro
(@jaro)
Posts: 1721
Registered
 

Loyal, post: 368646, member: 228 wrote: Not that I know of.

The "image" that I posted above is just a "screen shot" of a 3D AutoCAD drawing that I created as follows:

Loyal

Now that is what I call dedication to knowledge.

For those discussing SCS900, in version 3.21 you can enter a state plane coordinate zone and a geoid but not a scale factor. You can add the scale factor in TBC and then sync it to the data collector using SCS900. You can also do it in Access or Survey Controller, export a .dc file and then load it in SCS900.

James

 
Posted : April 21, 2016 3:42 pm
(@eddycreek)
Posts: 1033
Customer
 

JaRo, post: 368658, member: 292 wrote: Now that is what I call dedication to knowledge.

For those discussing SCS900, in version 3.21 you can enter a state plane coordinate zone and a geoid but not a scale factor. You can add the scale factor in TBC and then sync it to the data collector using SCS900. You can also do it in Access or Survey Controller, export a .dc file and then load it in SCS900.

James

Reading through all these responses I haven't seen a single mention of the requirements for machine control, specifically Trimble GCS900. I do a bunch of these files, and the Trimble guys will tell to do a site calibration and do not use a geoid. The calibration is loaded into the equipment as a cfg file along with the design and line work. Keep in mind you have a dozer or grader in constant motion in all directions controlling a cutting edge instantly. I suspect using a simple calibration allows all that to happen. And it's mostly to make sure the elevations match whatever control is provided. Really doesn't matter how dead nuts correct that is, if it was used for the design you're stuck with it. Jobs are bid using the earthwork from the plans. So if the equipment is using a calibration, the grade checker with the rover using SCS900 needs to be using the same thing. Of course if the control is good, the calibration should be good. When the grade gets within a tenth or so, you better get out the robot or level if it's gotta be closer.

 
Posted : April 21, 2016 4:16 pm
 jaro
(@jaro)
Posts: 1721
Registered
 

I always use a geoid in my files except for one that was apparently done before geoids were common, it was about 1999 +/-.

I will setup on one of the points and shoot as many control points as I can, then move my data up or down to best fit the elevations given on the control. I usually do this by changing the elevation of the first point I setup on.

Since the machines running trimble don't like a geoid, I do a calibration inside the data collector without ever taking a shot. This is Survey Controller or Access, not SCS900. I copy the file to a subfolder and then change the name by adding "cal" to the original name. Then I store 4 - 6 points as LLH at an even minute of latitude and longitude and an even height that is about average for the sight. This creates a box that entirely encloses the jobsite. The points are usually stored as G1 to G6. I export them as N E Elev and edit the point name to C1 thru C6 and import them as N E ELev. Then I calibrate G1 to C1, G2 to C2 ect. and take out the geoid. This gives me a tilted plane that best fits the geoid without having the geoid in the file. Four of the points are the corners of the box with the other two being somewhere in the interior just as a check. If I had a long, narrow job, it may be necessary to add more points inside the box just to make sure there's not any major undulations inside the job area, I haven't found any where we work.

Any work I do on these jobsites is still with the original file using the geoid. I never use the cal file again.

James

 
Posted : April 21, 2016 7:12 pm
(@dmyhill)
Posts: 3082
Registered
 

FL33404RTK, post: 368642, member: 11610 wrote: FWIW

I usually localize to 2 points from NGS.

I think 2 pts are fine for horizontal, but pick one for the vert

 
Posted : April 21, 2016 7:32 pm
(@shawn-billings)
Posts: 2689
Registered
 

For those that know, does your software allow for multiple points for vertical in a localization without tilting? Basically applying an average translation.

 
Posted : April 21, 2016 7:44 pm
(@steven-carper)
Posts: 13
Registered
 

dmyhill, post: 368417, member: 1137 wrote: What makes a level loop the gold standard for vertical? When you run the loop, you get a check. It CLOSES.

What makes the total station elevation only a silver standard? It isn't precision, I have tons of data that would indicate it is as precise as reading a rod on a level loop. It is because you have not turned through the stations. That hub set for that minimum slope sewer, it isn't CLOSED.

"Safety" is found in the checks, the closure, etc.

So, that being said, you can actually do this in the office. Your office or data collector should be able to apply localizations, and then update the coordinates by applying the localization after the fact.

You should be able to turn on and off points, generating coordinates at each saved change in the localization.

Do the localization for the 4 points. Then look at a point in the middle.

Now do a single point, using WGS 84, and compare the point in the middle, and the as shot values on the 4 points (if you shot them with RTK).

Now do a single point using the appropriate GEOID model.

Now you can see the difference, for the same shots, the same observations, etc. Now run a level loop. I will tell you what you will find. Your VRMS, double it, and that will be about the size of your random placement from the gold standard. Likely it will be about .2' (.1' up and .1' down).

Yup, it's all about checks and balances. Use whatever tools you wanthave to measure, but for the love of Pete, check, recheck, cross-check your stuff in the morning, in the afternoon and again before you leave the site. Make sure you build redundancy into your data; you've got to outsmart yourself!!!
I crunched somebody else's GPS static and RTK survey data recently that they spent an entire week collecting but the crew built NO CHECKS into their dataset in the field. They collected everything from WGS 84 "Here" positions to be proceesed later. Great, until i start to crunch said data.... Wouldn't you know it, but the sessions were busting each other, as in excess of 0.15 between RTK sessions. Long story short, I asked that they revisit the site and re-observe those outliers. I crunched numbers again and now I had another crappy set of residuals. Long story short, one of their primary RTK rover poles was not at 2m as they had attested in their field notes!
Back to equipment, here are my 3 primary vertical rules:
1. A Level is THE GOSPEL - it never lies
2. You can trust a total station with trig levels somemost of the time
3. RTK is the devil - it can be smack on or float like a wandering sea vessel

So, using combos of the above three tools, knowing the limitations of each and applying checks upon checks throughout your project can prove to leave you a few brain cells. Or as a brilliant person once said, "The X's and O's they haunt me"...

 
Posted : April 21, 2016 8:38 pm
(@kevin-samuel)
Posts: 1043
 

I

Shawn Billings, post: 368684, member: 6521 wrote: For those that know, does your software allow for multiple points for vertical in a localization without tilting? Basically applying an average translation.

I am not aware of that as an option in TDS Foresight or TDS Survey Pro. Maybe I just don't where that option resides... it could be there.

 
Posted : April 21, 2016 8:41 pm
(@loyal)
Posts: 3735
Registered
 

Shawn Billings, post: 368684, member: 6521 wrote: For those that know, does your software allow for multiple points for vertical in a localization without tilting? Basically applying an average translation.

I'm NOT absolutely sure, but I believe that Trimble's Survey Controller (v10.7) allows you to setup a project (SPC/UTM/LDP) and ENTER an offset (constant) to be applied to the computed NAVD88 Heights derived from the NAD83 Ellipsoid Heights and GEOID12a/b.

I don't (and never have) run Trimble Equipment, but my associate does, and most of my [surveyor] clients do as well.

Loyal

 
Posted : April 21, 2016 8:57 pm
 jaro
(@jaro)
Posts: 1721
Registered
 

Shawn Billings, post: 368684, member: 6521 wrote: For those that know, does your software allow for multiple points for vertical in a localization without tilting? Basically applying an average translation.

This is Survey Controller 12.50 although I can't really confirm that each is available when doing a site calibration since I don't really do a site calibration in the sense that Trimble expects us to do.

Edit: Shawn, to answer your question, yes it does. Either as Constant or Geoid/Constant. It's the Geoid/Inclined Plane that has me confused. Why in the world would someone want to do that?

 
Posted : April 22, 2016 4:49 am
(@mightymoe)
Posts: 9920
Registered
 

JaRo, post: 368706, member: 292 wrote: This is Survey Controller 12.50 although I can't really confirm that each is available when doing a site calibration since I don't really do a site calibration in the sense that Trimble expects us to do.

Edit: Shawn, to answer your question, yes it does. Either as Constant or Geoid/Constant. It's the Geoid/Inclined Plane that has me confused. Why in the world would someone want to do that?

It was an attempt to merge calibration points with a geoid, i tried it and didnt have much success, but that was probably using Geoid96 which had lots of issues anyway. Once 03 came out it all became moot as far as i was concerned.

 
Posted : April 22, 2016 5:55 am
(@bill93)
Posts: 9834
 

Seems to me (not a user of any of the software discussed) that either the manufacturers are not providing enough information about what their software does, or the users aren't studying their information enough to learn it. The confustication demonstrated by this thread shouldn't exist and users should be able to definitively state the merits and deficiencies of each procedure for their particular software.

 
Posted : April 22, 2016 8:05 am
(@loyal)
Posts: 3735
Registered
 

Bill93, post: 368770, member: 87 wrote: Seems to me (not a user of any of the software discussed) that either the manufacturers are not providing enough information about what their software does, or the users aren't studying their information enough to learn it. The confustication demonstrated by this thread shouldn't exist and users should be able to definitively state the merits and deficiencies of each procedure for their particular software.

Absolutely...

Good post, and excellent observation Bill.

I haven't used my personal RTK system since about 2008 (Carlson SurvStar), and I can tell you that it not only didn't have the option(s) that we are talking about, but didn't have the capability of used a Geoid Model at all... It worked fine for my purposes (retracement), but anytime I needed "elevations," I had to process the data after the fact (no real time).

Considering how many folks (surveyors) seem to be baffled by Ellipsoid Heights, Geoid Models, NAVD/NGVD, and the need to actually tie their work into BOTH Horizontal and Vertical CONTROL (OPUS, HARN/HPGN, and especially BENCH MARKS), this issue is important.

Loyal

 
Posted : April 22, 2016 8:22 am
(@mightymoe)
Posts: 9920
Registered
 

Bill93, post: 368770, member: 87 wrote: Seems to me (not a user of any of the software discussed) that either the manufacturers are not providing enough information about what their software does, or the users aren't studying their information enough to learn it. The confustication demonstrated by this thread shouldn't exist and users should be able to definitively state the merits and deficiencies of each procedure for their particular software.

The best thing is to test what your equipment will do, vertically that means testing against leveled elevations and for most NAVD88 bench marks would be the gold standard.
That should not be too difficult, try out your calibration, test it against 10 bench marks, try using the geoid models, see how they work. Test, check, compare, don't just blindly go out and use a system.

 
Posted : April 22, 2016 8:57 am
(@jim-in-az)
Posts: 3361
Registered
 

Bill93, post: 368770, member: 87 wrote: Seems to me (not a user of any of the software discussed) that either the manufacturers are not providing enough information about what their software does, or the users aren't studying their information enough to learn it. The confustication demonstrated by this thread shouldn't exist and users should be able to definitively state the merits and deficiencies of each procedure for their particular software.

AMEN Bill! When an attorney reads this they will quickly realize that few if any of us have the faintest idea what we are doing or the ability to explain it. Not to be rude, but I don't see a coherent understanding of proper procedure or understanding that would stand up for more than a few minutes in a court of law. I could be wrong, but I don't see it.

 
Posted : April 22, 2016 9:10 am
 jaro
(@jaro)
Posts: 1721
Registered
 

Hey Now, Give me a break! I had a wisdom tooth pulled yesterday! How was I supposed to know that the wisdom went with it!

I claim diminished mental capacity until I can eat solid food again. 😀

 
Posted : April 22, 2016 10:04 am
(@lee-d)
Posts: 2382
Registered
 

Shawn Billings, post: 368684, member: 6521 wrote: For those that know, does your software allow for multiple points for vertical in a localization without tilting? Basically applying an average translation.

I've never tried the other options in Trimble (other than tilted plane). If you don't use a tilted plane how does it do that, interpolate between the points? To oversimplify, if I have 0.1' difference at a control point A and 0.2' at another point B 100' away, would it apply 0.16' if I was 60' from A and 40' from B?

If you really want to know exactly what Trimble does, pages 281 - 286 of the Access manual discuss it in detail.

 
Posted : April 22, 2016 10:25 am
(@rlshound)
Posts: 492
Registered
 

leegreen, post: 368494, member: 2332 wrote: I agree with Moe. There is no reason to calibrate or localize today with the onboard software. Usles you are trying to cheat project, and do a quick and dirty job. When I get to a construction site where control is already established by others, be it in NAD83 or local coordinates. I always setup using the current SPC projection and latest GEOID12B. My base is always storing static data. I measure the control to the best of my ability using a combination of static, rtk, total station and digital level. Then I take the data back to the office (trailer or truck) and compare my measurements with the control data supplied to me. After analysis of Pdop, location, stability, and visual inspection, I can determine which points fit best. These are something your controller can NOT do. Even if the original control is said to be on SPC, I find very often it is not. Vertical control does need to be verified with on site benchmarks and seldom agrees with NAVD88 from an OPUS. Horizontal is usual closer to NAD83. Last week I was in southern Jersey where a project control was å±2ft north of NAD83 as per my check with a 4 hour OPUS and verified with post processing with CORS data. Had another project in central Georgia, again å±2ft from NAD83. In Georgia, the original surveyor explained to me they were using control from 30 years ago, and never checked it with OPUS or CORS data, until I brought it to their attention. In these cases I do have to stay on the local datum. Therefore I manually create the shift from local to WGS84 or grid. I can manually create a calibration or localization file using WGS84 lat/lon/ell and the residuals will be 0.00 as a result.

This method also allows me to remotely verify control on my clients base station, by collecting static data to be checked with OPUS and CORS on a a daily or weekly basis.

Hello Leegreen, I try to follow the same methods and like others stated earlier test your results....I believe in independent surveys giving comparative results....attached is a recent survey. I do not claim to know everything and am always interested in learning. My results showed agreement within the coordinates but when I compared my static baseline distance at grid and ground with the same distance between the observed control points at grid and ground they were different. Can you please explain the possible reasons for this?

Attached files

20160422111936.pdf (210.4 KB) 

 
Posted : April 22, 2016 10:35 am
(@bill93)
Posts: 9834
 

If you are talking about the handwritten numbers at the bottom of the pdf, they are less than 2 parts per million different. Is that significant in your project?

A likely reason for them to differ is the elevation factor which is used in calculating the combined factor. How well do the elevations match? Was there confusion between orthometric elevation and height above the ellipsoid? How well did the projection point scale factor compare between them?

EDIT: It looks like ellip-ortho does not match the discrepancy.

I note this is an ultra-rapid OPUS solution. I wouldn't pin anything critical on an ultra-rapid solution, but if possible wait a few hours for rapid or even the precise solution you can get in a couple weeks.

 
Posted : April 22, 2016 11:28 am
Page 3 / 6