Discrepancy Between VRS (Company 1) and Base Station/Rover (Company 2)

Did you check they are both using the same geoid model?

VRS would be my last choice for bringing in control. 

Too many unknowns between the two operators to be able to point to any specific potential source of the discrepancy.

Was me, two hour plus simultaneous static sessions using two dual frequency receivers on two control points at either end of the project with fixed height tripods. Process through OPUS. Use RTK to check between them afterward. Only then would I use VRS after localizing to that control.

Good luck!

I second the Geoid check. Base/Rover will generally be better than VRS dues to shorter baselines. Hard to give an answer here without more info.

- How did company 2 establish the elevation of their base point?

- How did the elevations from the level run compare to the GPS elevations from Company 1 and 2? Is there a constant 0.6' difference between Company 1 and 2?

At the end of the day, I would use the elevations from the leveling run and move on with the project. 

VRSs vary but I've never seen one be off by 0.6' in the open. That 0.6' is close to length of an adapter placed on a prism pole to make the antenna height match the prism pole graduations. 

Regarding VRS vs Base/Rover for aerial targets, it just depends on what the data is being used for. Contact the team flying or processing the LiDAR data and ask them what amount of error they typically see between their final CAD surface and elevation check points and what the final contour interval will be. 

I'd assume that anything involving a road would need to be tight, but it's possible that the LiDAR team is using a low-grade sensor, in which case you might be able to get away with some averaged VRS shots. I spent a ton of time tightening control for aerial targets just to find out that the final product was a two-foot contour interval surface. Three time separated VRS observation per target would have sufficed and would have save a ton of time.

Why not just have Company 2 set the control.  We only fly sites with control set by us, much easier to control everything that way. Plus, it seems like they have the capabilities and it gets you out of the middle of it.

You're comparing apples to oranges. One has a constant setup base/rover while the other is using VRS and your rover (and setup and input)   We use VRS alot when less than 2 miles from a station for control, when applicable, but always prefer a base/rover setup in all instances.  

As stated above, if this is the start of a mile long road project it would be prudent to set 2 or more offsite stable (in concrete) control points and complete a quick static network. 

I did the control for company 2. I don't know company 1 but I let my client (company 2) know about the discrepancy and told them I believed it was an HI problem and that company 1 could contact me at any time to discuss. I was there to set control for terrestrial laser scanning, and used some of their photo ID's. 

Here's the story...

I setup a base (Trimble Alloy GPS+GLONASS+Galileo+Beidou) at the south end of the project. There is a USCGS triangulation station with two reference monuments about 80 meters away. Second order triangulation but also second order class 0 vertical by leveling, set in 1942. I recovered all three USCGS monuments in good condition, all flush with the ground in mowed grass in a National Park, all wide open. They are concrete posts, stability C. I occupied each of these using RTK (Trimble R10-2) for 180 epochs, rotated the rod 180 degrees, and did a second observation. I then did the same again 4 hours later. 

Here are the differences from the mean values for the four occupations of each (in meters):

So the vertical agreed between the occupations by at worst 4 mm. 

The base had 5h23m of data. I submitted to Trimble Centerpoint RTX post processor and to OPUS. The RTX ITRF2020 epoch 2026.10 solution was transformed to NAD83 (2011) epoch 2010.0 using HTDP. 

Here are the NAD83 (2010) epoch 2010.0 UTM coordinates of the OPUS and RTX solutions (meters)

I also processed the base in TBC against the three nearest CORS. I then did a free adjustment of the static network holding one CORS. Misclosures in meters, the misclosure at the base 26010Z is versus the RTX transformed coordinate. 

Next I did an adjustment holding CORS1 and CORS 2 fixed 3D (NAD83 (2011) epoch 2010.0 from MYCS3 lat/long/ellip H). Misclosures in meters:

The ortho heights used for comparison are published NAVD88 orthometric heights from leveling. I used the GEOID18 model. Note that the published horizontal coordinates for the triangulation station are NAD83 (1992) from triangulation, not from GNSS. There are no GNSS derived coordinates in the NSRS for this station. In any case, that is excellent agreement from CORS ellipsoidal heights to NAVD88 leveled heights. 

I then occupied several (not all) of the photo ID's set by company 1. Note that this is an urban street, some of the ID's are very close to three story brick structures. I used the same methodology as outlined above on most, but on several I only occupied the monument once (double occupation, rotate rod). Differences in meters

The ID's above with three or four occupations were done 4 hours apart. 

For the final adjustment I constrained CORS1 and CORS2 horizontally, and the trig station and RM 2 vertically (NAVD88 ortho height). 

Here are the comparisons versus company 1 values (this time in FEET, this is what I sent to my client, I work in meters, they work in feet):

I was pretty sure company 1 used VRS, and the somewhat large spread is due to some of the points being very close to buildings and trees in an urban area. 

As you can see, the horizontal agreement is about what can be expected from VRS. 

My opinion is that they have an incorrect antenna reduction, either the wrong antenna type or a bad HI. 

As for their leveling, 0.13 feet is not a good misclosure, but I have no idea what equipment or methods they use. When we run levels for mobile lidar (not here), we use an invar rod and second order procedures. Typical misclosures are <0.01-0.03 feet (3 mm to 1 cm). The reason we use invar is that typical multi-section rods (both conventional and digital) have problems at the joints (i.e reading high rod then low rod). This tends to cancel out when leveling back to the beginning point. This particular project had elevation change of 110 feet from one end to the other. 

One other thought that occurred to me was the geoid model. G18 versus G12B would not account for this. But, EGM08 (incorrectly) used with NAD83 (2011) epoch 2010.0 might...but that difference is 81 cm. I have multiple projects going on right now where they want NAD83 (2011) epoch 2010.0 with Geoid18 and also WGS84 (G2139) epoch 2026.22 with EGM08. When EGM08 is used properly like that I have seen the EGM08 derived elevations agree with NAVD88 by up to a meter, depending on location. I also do projects in South America, I pretty much have to use EGM08 as the geoid model. When used with a relative sense with one or more known elevations it does pretty well, but using it in an absolute sense with ITRF horizontal it can be all over the place with respect to local vertical datums.

Since I use EGM08 I have it on my data collector. Every time I setup a new project it defaults to EGM08 because it is alphabetically before GEOID18

0.13' misclosure on a level loop of almost any length is pretty bad.  It shouldn't be necessary to go with invar to beat that. I'm guessing a tenth bust on a rod reading somewhere.

I prefer the base/rover system over VRS. Mainly because the VRS is akin to a black box - it reports a coordinate without documentary backup.   

It would seem that the VRS combined with other factors such as multipath, HI's, Geoid Models, ect. could each or all be factors with the botched data. 

Levels for such a short distance should be much tighter than .13'. 110' elevation change in a mile is a pretty good drop, that might be a challenge for a crew unfamiliar with running levels. Like John we went to electronic levels and invar rods some years ago and I don't remember a mis-closure level run that was anywhere near .13' since. 

For a highway project it's critical that the control is good, everything follows from there. We used to run control for DOT which included levels and GPS tied to HARN, later to CORS and OPUS. Now DOT sends us their control and we check it when doing boundary. The checks have become freak shows of accuracy.

Geoid18 and Geoid18B are the same for the lower 48, so I'm told. I've checked between them and got the same geoid heights a couple of times and quit doing it. For the areas I work in that geoid model (Geoid18) "fits" very well with first/second order bench marks. However, not so well when applied to the ellipsoid height, but when applied to the orthometric elevation published with the bench marks it's quite accurate. In other words it's modelling the topographical changes of the Geoid and doing it much better than older versions. 

I'm a bit surprised they are using aerial UAV technology for this urban project. That's been replaced with ground based mobile scanning. Aerial for nice photos, but for the data it's scanning and boots on the ground for tie in locations. Just saying; aerial mapping is kinda sloppy for downtown. 

They are lucky to have John there helping out. They need to pay attention to him. 

Thank you everyone for responding. @john-hamilton, I am sure we will be in contact with you. It may not be myself who contacts you. Thank you again for reaching out.

@mightymoe Actually, it is a combination of aerial imagery by drone and terrestrial laser scanning. Company 2 is doing the aerial and we are doing the scanning. 4750 feet from one end to the other. Over 100 scans with a TX8. I was doing control for the scans. We also take 360 photos at each scan station.

@john-hamilton 

Awesome, I wondered, the scans seem like the way to go anymore. I don't have a handle on how accurate the scans are, our work is always just boundary, but they've got to be more precise than the Aerial. 

I do have one question, how is the scanner controlled as it moves along the roadway? Is it an RTK receiver mounted to the unit and controlling the scanner?

@mightymoe This is not mobile lidar, it is terrestrial lidar. Usually we do a survey workflow, like a traverse with targets. This time we did not do survey workflow, we just setup randomly (not over a point) about every 60 feet or so (not sure the exact spacing, I was not doing the scanning). The software stitches the scans together and there are control points about every 500 feet for the scans. 

There is parking along the route, but the town bagged the parking meters in the section we would be in each day. So we were able to setup in the parking lanes, and alternated sides. But there was a lot of traffic, including heavy trucks. In the center of town there is a traffic circle and a lot of pedestrians

Posted by: @john-hamilton

↑

@mightymoe This is not mobile lidar, it is terrestrial lidar. Usually we do a survey workflow, like a traverse with targets. This time we did not do survey workflow, we just setup randomly (not over a point) about every 60 feet or so (not sure the exact spacing, I was not doing the scanning). The software stitches the scans together and there are control points about every 500 feet for the scans. 

There is parking along the route, but the town bagged the parking meters in the section we would be in each day. So we were able to setup in the parking lanes, and alternated sides. But there was a lot of traffic, including heavy trucks. In the center of town there is a traffic circle and a lot of pedestrians

Got it. The DOT here does quite a bit of instrument scanning. Usually for intersections and of course bridge structures. For the last couple of urban jobs we've been involved with they have used the mobile scanner. I suppose it doesn't matter when it's done. Could those be done late at night when traffic is mostly gone?

I saw a survey report from their data collector. They had the correct GNSS receiver type, and their HI was 2.000 m (6.562 feet) to the ARP. Since our elevations are higher, I am suspecting it was an actual HI of 1.8 meters. I have seen rover rods that have a 1.6 m, 1.8 m, and 2.0 m settings, with a pin to hold it at the selected HI. That would make a difference of 0.656 feet. 

We use a fixed height that only has 2.0 m. However, I do sometimes (rarely) add extensions on top to get the receiver above some low obstructions. But I take pictures of all setups.

It has been years since I have done field topo with a total station, but I remember changing the HI to get line of sight and forgetting to change it in the DC. Or changing it for a few shots and then forgetting to change it back. 

Posted by: @john-hamilton

↑

It has been years since I have done field topo with a total station, but I remember changing the HI to get line of sight and forgetting to change it in the DC. Or changing it for a few shots and then forgetting to change it back. 

Besides the tilt function of the AP20, the automatic rod height is great.  I wish it worked with the GS18 but that is usually kept at a fixed height anyway.

Posted by: @jbroadt95

↑

1. Am I correct in my findings that a Base Station/Rover setup is probably the better instrument for setting up this project?

2. Why are we seeing differences between the two GPS systems?

3. What are some solutions that need to happen?

1.)  Yeah, I'm still skeptical of both VRS and drones and prefer avoiding them at the moment.

2.)  Maybe the CORS are all a long ways from the site or there was some form of human error.

3.)  Figure out why company 1 can't even close a level loop.

Very briefly...

the closer you are to an actual reference receiver the better, as that minimizes any effects due to differences in the atmosphere between the reference (base) and the rover. 

If I setup a base and survey nearby with 4 constellations, I can usually get good results even with a lot of obstructions and multipath. For USGS 3DEP Lidar project we have to survey a certain number of woods checkpoints. I set a base at the location of the woods point in the open, and do regular RTK to the point in the woods. This almost always works well, although I had a recent project in FL where I could not get good results in the woods even though my base was 30 meters away. I had to set a pair in the open and use a total station. But that is rarely necessary. 

I try to restrict RTK to 15 km max distance, whereas VRS will work well (slightly less accurate than RTK) at many 10's of KM's. 

A VRS (or RTN) creates a virtual base by interpolating between physical reference stations. These stations are usually many km away, maybe up to 70 km. So the atmosphere may be different at the rover location than at the various reference stations, causing a bias. I routinely see degraded results around noon when using various VRS networks. 

A few years ago I setup a base at one exit of the PA Turnpike. I was surveying at the next exit, about 15 km away to the east. A storm was approaching, and I got terrible results when the storm front was between the rover and the base. So it is important to know what is going on around you with the atmosphere whether using RTK local base or a VRS. 

Call me old fashioned. I say never establish control with RTK. If you can do repeat observations 4 hours later, then you should be able to do a static setup or two--even rapid--and process on a computer or with OPUS/OPUS Projects. Mess up the control, then there go all subsequent surveys based on that control.

I have never trusted VRS although I understand how it works. For setting new control? Never ever. Too many variables that could glitch. I also agree with others that the level loop they did was a bust.

No one would ever know about the level run if I ran it and it was 0.13' off in a mile. I would eat the cost and re-run it, discard the first one. 

@mightymoe 

I like to set a several mag nails as turning points on the way out and then run through them on the way back.  Not that I've ever had a 0.13' misclosure in a mile, even in the olden days of the manual level, but that way you can correct for a bust without running the whole thing again.