For my GPSonBM sessions I measured 3 places around the ground plane, using the Trimble pole, at the start and at the end of he session, and was disappointed if all 6 measurements did not round to the same1 mm increment.
Consistently reading the scale is a good thing, but it doesn't translate as perfection. There are plenty of other sources of error in the system. Get the guy beside you to repeat your procedure and he will get a different number, and repeat it at 3 points around the perimeter.?ÿ And that doesn't make either of you wrong. We just have to accept that these errors are a part of our lives. Plus, the sort of care and attention you can give measure ups on a GPS on BM session is going to be much greater than what is reasonable to expect when traversing control.?ÿ ?ÿ
The original post from the other thread (Collecting-Processing static Data for DGPS) indicates you came into this project after it started.
Quick summary (paraphrasing), "a point at the start that they're holding, setting up a base on that point, running 3-4 hours of static using a rover on all their main control hubs. They're importing those T02 files into TBC, manually entering in point numbers and heights ect, processing baselines, then using TBC to adjust the coordinates to get them into a ground system."
If the original field method is as you say, the original static data collection set for the main control hubs should be golden. What they did after that, is a bit murky.
If this is a case of densifying the control network from a preexisting "ground system" (site calibration?), it may be a matter of making all your new measurements, correctly adjusting your dataset, and then fitting to a site calibration or something like that? It seems that the "working" control values already have some of these concepts already baked in, but we don't know what they are.
Not sure how they arrived at "ground", but it sounds like they may have started in some form of geodetic grid, and did who knows what after that?
In my experience, I have 2 guesses about how the vertical (and the horizontal?) may be, or became wonky in this case: 1. The original "adjustment" was performed, and they held 2 points (endpoints?) fixed vertically, which instantly gave you the slope across your project extents. 2. Somone applied an average combined scale factor for your site across the individual coordinate values in Excel, or similar.
Which is why, separately, the gnss is good, the traverse is good (hz & vt, but may indicate otherwise at the moment), and the levels are internally consistent, but nothing matches your "control".
Might be possibly mixing some random ground system (translation/rotation/scaling issues) with some new good intermediate control on some particular geodetic grid, which is why it's fubar.
I could be wrong about all that, but let's see what else you got?
The following questions might help us figure out where you came from, where your're at, and where you're going, becasue you came in during the middle and you're trying to make it match:
How many "main control hubs" are there already computed before you got there? What was the original coordinate system and method of adjustment those positions were derived from? How did those positions get transformed into a "ground system"? What are the parameters of the existing "ground system" you have to match?
Plus it's a far sight easier to measure to a round antenna with a fixed graduated rod where you can get a straight line from mark to edge of antenna (thinking the Trimble zephyer geodetic flying saucers)
?ÿ
Find with total station you end up " bending" the box tape around top of tripod head and then still can't get exactly to the dimple as battery/storage card knobs in the way (Leica/Geomax) so even if you use the onboard application that converts the slope distance measured to a vertical distance you have some systematic error.?ÿ I've taken to rounding down to nearest mm to try account for top of tripod making slope slightly longer than a direct measurement.
?ÿ
To do it properly would need to measure a slope distance from mark to top of tripod and convert to vertical distance plus measure from top of tripod to dimple on instrument but with that method even more chance for a mistake in measure up!! Wonder if Leica's auto height would fix that?
?ÿ
Only way to accurately transfer levels with total station for me is to only measure to marks with pole at fixed height and instrument not over marks; i.e traverse by resection of you also need positions
I've taken to rounding down to nearest mm to try account for top of tripod making slope slightly longer than a direct measurement.
Try doing the trig calculation on that and I think you will find you are under-compensating. Working in feet, I round down to the nearest hundredth of a foot, and then cut another hundredth.?ÿ That would equate to cutting 4 or 5 mm.?ÿ The mark on the instrument that I'm measuring to is about 2mm wide.?ÿ
Bottom line is that the vertical centering error I use in StarNet starts at 0.01' and I'll dial it up to double that without undue concern.?ÿ
Constrain to ONE POINT (you can have one H and one V). Set a Bearing to the another station.
After you have everything working from that, then you can warp it and constrain as you like. But MINIMAL constraints is critical to getting having the software tell you what you need to know. You can have great "results" by constraining willy nilly...
Of coarse there will be many more redundant measurements made, but I'd like to figure out what is going on first.
What do the station reports reveal? You can examine what is happening at each station, and that allows you to refine the issue that you are looking at. Sometime inconsistent measure ups are revealed in the reverse shots from station to backsight. Also, this can show if you are missing something or if your approach is creating some sort of issue in the data.
My suggestion to let all the coordinates float a tenth is my step before holding ONE POINT, to test the measurements vs. the given coordinates. If one of the given "control" points is off, no point in holding it fixed. Star*Net allows holding or giving a standard error to multiple connected points in place of specifying a fixed bearing.
Find with total station you end up " bending" the box tape around top of tripod head and then still can't get exactly to the dimple as battery/storage card knobs in the way (Leica/Geomax) so even if you use the onboard application that converts the slope distance measured to a vertical distance you have some systematic error.
That's the precise reason why Trimble instruments have the notch measurement method. No wrapping the tape around the instrument. Doesn't stop some of our crews from trying, though...
IMO, your horizontal centering errors could be tightened to 0.001m, and your vertical centering loosened to maybe 0.004m. That simple thing?ÿ might be enough to normalize your statistics.
I have found that Measure ups are a real weak point. Get several guys to measure the same measure up independently and you are going to get a surprisingly large range of results. Half a centimeter, maybe more, is totally reasonable. One thing about doing a lot of LS adjustments is that it educates you about what your errors actually are.?ÿ ?ÿ ?ÿ ?ÿ ?ÿ
With regards to holding the GPS points fixed - as others have said in different ways - those coordinates are not perfect. I understand that, nevertheless, project management considerations may oblige you to hold them fixed. But that just means that their error must be distributed into the measurements. Doing so means that you may have to dial up the error settings of those measurements unnaturally to get statistics to "pass" chi-square.?ÿ My favorite way of dealing with that is to mess with the centering errors.
Also - the vertical component of a GPS determined coordinate is always the weakest. A couple of tenths of a foot in each point is very possible. Better can be done but it isn't guaranteed at all.
Good point on the centering errors, I made that adjustment along with my vertical angles the chi values for zeniths is about spot on with the rest now.
I think I should steer this conversation back or track a bit with some observations I've made. Lets forget horizontal for now and focus on elevations.
?ÿ
1. The GPS observations have nothing to do with the problems I'm seeing.
My GPS observations have no common ties to my conventional ties at this point. Just to be 100% sure I have deleted the .gps files out of the adjustment and removed the GPS control points and as expected, my check coord (822) hasn't changed.?ÿ
2. If I run the exact same data with the exact same project settings but change the coordinate system to local (vs UTM)?ÿ and use my scaled local coordinates (vs UTM) I get results that agree very closely to the old levelling data I was provided.
This tells me this must be the source of the issue. That's literally the only differences between the two projects. They are using the exact same .dat files. And on the east side of the traverse (extended with todays data) im seeing a difference in elevation of about 0.16m between the same point in each project.
Ok I'm getting closer. So when I check the box for geoid modelling when ONLY processing my GPS data, I get good results. When I add in my conventional data, the geoid is being applied to that and thats causing it to drop down.
When I uncheck the box and dont apply a geoid and ONLY processing my conventional data, I get good results. When I add in my gps data, the geoid isnt being applied to that and it causes my GPS data to go out of wack.
But this is when there are no common ties between my GPS data and my traverse. When I start using the same point numbers and create common ties everything starts getting sucked together. Now I should be able to start playing with observations and getting a better idea of what to hold and where redundant measurements are needed.
?ÿ
So to summarize it appears the issue I was having was caused by applying geoid modelling while not relating my conventional observations to GPS observations. Does this seem right?
?ÿ
This is where I'm at now. Not great, but I have alot of work to do yet.
If you perform geoid modeling and your network includes conventional data, it is highly recommended that you also perform vertical deflection modeling (or at least specify constant deflections if the geoid plane is at a somewhat constant tilt). Vertical deflections affect zenith angle, turned angle, direction and azimuth observation computations in grid jobs. These computations rely on knowing the relationship between gravity (plumb line) at a point and the normal to the ellipsoid at the same point.
Vertical deflection modeling is particularly important when combining conventional observations (gravity based) and GPS vectors (ellipsoid based) in the same adjustment.
2. If I run the exact same data with the exact same project settings but change the coordinate system to local (vs UTM)?ÿ and use my scaled local coordinates (vs UTM) I get results that agree very closely to the old levelling data I was provided.
This tells me this must be the source of the issue. That's literally the only differences between the two projects. They are using the exact same .dat files. And on the east side of the traverse (extended with todays data) im seeing a difference in elevation of about 0.16m between the same point in each project.
Been almost eight months since I have used StarNet heavily...thinking this might be a vertical deflection issue, possibly geoid or earth curvature too?
I am unfamiliar with vertical deflection modelling, how does one go about finding the correct .vdf file?
When I run the conventional on its own for a check point I get 15mm off the given value. When I run the GPS on it's own I get 30mm off the given value (which can be cleaned up with more observations).
But the weird thing is when I run them together I get about 50mm off the given value. I guess that's because the geoid is now affecting the conventional measurements? And I'm not performing vertical deflection modelling? Which I don't fully understand what that is.
I am unfamiliar with vertical deflection modelling, how does one go about finding the correct .vdf file?
When I run the conventional on its own for a check point I get 15mm off the given value. When I run the GPS on it's own I get 30mm off the given value (which can be cleaned up with more observations).
But the weird thing is when I run them together I get about 50mm off the given value. I guess that's because the geoid is now affecting the conventional measurements? And I'm not performing vertical deflection modelling? Which I don't fully understand what that is.
A good graphic of the deflection of the vertical is here.
From the NGS: "The deflection of the vertical is the departure of a plumb bob's actual pointing from the ellipsoidal normal direction. Deflections are used to relate the orientation of a locally-leveled instrument, such as a theodolite, to a spatial reference frame. Important uses of deflection values are corrections to zenith distance (vertical angle) measurements, and the conversion between astronomic and ellipsoidal azimuths (the Laplace correction)."
However, unless the geoid slope is sharply inclined in the project area and/or there is a LOT of elevation change through the project, its effect on this size network should be minimal, well below the raw errors in your actual observations.
A big thank you to everyone that responded. I finally got it sorted out.
So the geoid was affecting conventional data, vertical deflection modelling is used to compensate for this. I've been told by the creators of StarNet that unfortunately with Canadian Geoids, vertical deflection modelling is not possible. The work around is to process the GPS data, pull out the residuals from the listing file and bring those observations into the network and process the conventional with the geoid off.
Unless it is a large area and/or long sights, the deflection of the vertical is not significant to the conventional vertical results.?ÿ
I always include a geoid model in my adjustments, even if there is no GNSS.?ÿ
If you adjust with geolab, and include a geoid model, it will compute the deflections for each station and apply deflections of the vertical corrections to the data. I like geolab for larger (in area) networks as it does the computations in ECEF. Starnet will give weird erroneous results if, for example, you are in the wrong zone. I do like starnet for smaller networks and combined GPS and conventional networks for the wealth of information in the output. I consider geolab to be "more correct" (i.e. more rigorous), but for small (in area) networks the difference is negligible.?ÿ
"I think I should steer this conversation back or track a bit with some observations I've made. Lets forget horizontal for now and focus on elevations.?ÿ 1. The GPS observations have nothing to do with the problems I'm seeing."
To be fair, it most likely is ALL about your GPS observations. GPS is always 3-D, and the various "heights" (ellipsoid/geoid/orthometric) are always the fly in the ointment.
Tying into a published "national" system with GPS technology has certain requirements that go along with it to make all the terrestrial data sources happy with each other and with GPS data sources. Mismatch anything not specificaly meant to go together, and you can get answers that are very close to the variation we're seeing now, or something so obvious we don't need to spend days going down a rabbit hole of minutia to figure out what the problem is.
You never shared the metadata associated with the sources of your record survey data, data collection, or desired final output. That information is probably the first and one of the most important pieces of information to identify and consider for planning and execution.
For example: You shared a screen shot showing the StarNet Project Options Adjustment tab, and it had a greyed out Coordinate System of "UTM83-11", because you were adjusting to "local". Okay, fine. (UTM 11 North NAD83(CSRS) v7-2010 appears to be the most current, but "UTM83-11" isn't detailed enough to know if they are the same.)
In UTM Zone 11 (N), there are at least 11 published horizontal datums (each being slightly different for various reasons) for Canada, there are at least 7 published geoid models for Canada (and a heights transformation tool), and there are at least 2 published vertical datums to consider as well. That's a lot of things to dial in correctly to get all this fancy tech to spit out meaningul answers.
This note is also prominently displayed on the 5 benchmark datasheets, and the 1 CORS datasheet I could find (that was within about 250km of your site): "The CGVD2013 height reported in the Vertical Data table is approximate because it is calculated from historical levelling data and not from the combination of GNSS and a geoid model."
Why might all of this matter? It appears as though you may be using the wrong vertical datum with the wrong geoid model (with/without the height transformation tool?) and the wrong geometric datum that links all these things together so they work properly. All of these compounding factors will likely cause the the LSA to blow up when combining all 3 data sets in a homogenous single adjustment.
Basically, your terrestrial optical data sources will coincide with each other no matter what the vertical datum because it's all local, and it appears that they do by what you've shared:?ÿ "2. If I run the exact same data with the exact same project settings but change the coordinate system to local (vs UTM) and use my scaled local coordinates (vs UTM) I get results that agree very closely to the old levelling data I was provided. ...And on the east side of the traverse (extended with todays data) im seeing a difference in elevation of about 0.16m between the same point in each project."
"I am unfamiliar with vertical deflection modelling, how does one go about finding the correct .vdf file? When I run the conventional on its own for a check point I get 15mm off the given value. When I run the GPS on it's own I get 30mm off the given value. ...But the weird thing is when I run them together I get about 50mm off the given value.
What vertical datum is/are your level run(s)? The vertical datum difference between GCVD28 (leveling) and CGVD2013 (leveling) is in the -0.457m range for the benchmarks. The vertical datum difference between GCVD28 (leveling) and CGVD2013 (GNSS) is in the -0.132m range for the 1 CORS. Those numbers were fairly close to the differences causing the problem(s), no?
If this simple mistake (which we've all made) is the culprit, adjusting the various error estimates in an attemp to feather out a blunder/systematic error is not really the appropriate way to go about it.?ÿ You can polish a turd, and put lipstick on a pig, but they both still stink.
Everyone on this message board has been burned exactly once with mismatching data types/sources before they learned never to do it again.
So, despite the uncertainty between the numerous combinations of reference frames, epoch dates, vertical datums, geoid models, and no source(s)/date(s) of your survey/record data, you received a nice crash-course in geodesy and a lesson in Least Squares Adjusment.
