Combining dini level data and GPS data in TBC

Not sure what you want to accomplish. Why not processed the GPS using default ellipsoidal ht as z values then compare ellipsoidal with level values?

Just hold 1 of the GPS point as base.

I would process the GPS data in a file with the projection that you want without a geoid model, the dini data I would import to a different file.

Then combine the xy of the GPS with the z of the dini into a file setup with the projection and geoid model you want to use, compare the ellipsoid heights of the two files, I would want to see the heights be "off" consistently between the two files.

I would not process them together.

I do this all the time, maybe there is a way to throw them together, but I like to look at the good real world data (levels) compared to the modeled world data (geoid) before they get combined.

Thanks for the advice, I believe if you use the same point numbering system when you do the level run as you used for the GPS run , when you combine both files in TBC, it will automatically assign the dini levels to the GPS control points and discard the GPS derived heights .

I wanted to do this on the fly in the field.

You can do what I describe in the field, I don't think TBC allows constraining e for adjusting GPS vectors, maybe I'm wrong about that, I've only fixed h to do that.

If you name both your GPS & DiNi points the same name the DiNi data overrides the Z in TBC.

> If you name both your GPS & DiNi points the same name the DiNi data overrides the Z in TBC.

That doesn't make sense. Why wouldn't the TBC adjustment module perform a least squares adjustment using the standard errors of the observations?

I would not adjust them together, h and e are two different things. Let the program work through the h adjustment then apply e.

I am not a TBC user but back in the early 90's, I did the following several times. We set our marks and ran levels through the with a digital level complete with some cross ties for a network and adjusted the network with Star*Lev. Then we did static GPS observations on the points, with lots of redundancy. We were using Ashtech Z12 receivers and WinPrism to post process. This was before the GEOID models were released. Then we load the GPS Output files into Filnet to do the network adjustment. We used 2 triangulation stations for horizontal control. One of the triangulation stations was also a benchmark. When I ran the free adjustment, I fixed that triangulation station only, in latitude longitude and elevation. Because I did not have a GEOID model, I used the elevation as the elepsoid height. I compared the GPS derived heights to the leveling data, and the position of the other triangulation. Everything was close so I fixed both triangulation stations horizontally and selected 3 points that would almost surround the site with vertical control and fixed them in elevation only. Then I ran the adjustment again and compared the elevations. The worst any of the points were off in elevation was 0.017 M. Then I fixed the rest of the points in elevation and ran the adjustment again. The Standard Error Unit Weight was near zero and all of the residuals were small. Ideally you want the SE Unit Weight to be 1. If it is less than one, your weighting scheme is too loose. I messed with the weighting until I decided that I was chasing millimeters when I only needed a centimeter so I published the results.

> I would not adjust them together, h and e are two different things. Let the program work through the h adjustment then apply e.

That's the NGS way, and it makes sense for large-scale projects and those for which a decent geoid model isn't available. It's awkward, though, and for surveys of limited extent - at least in my area - the h differences track the e differences very closely, such that a single adjustment combining GPS and leveling is practical. (A minor elevation shift to to fit local bench marks might be necessary at the end.). The advantage is that the leveling serves as a check on both the GPS observations and the geoid model accuracy.

If the statement that TBC ignores h and relies solely on e is correct when leveling is included - I haven't looked into this, as I use Star*Net for combined adjustments - then it's taking a tool out of the user's hands.

The problem is adjusting the e can really mess up the control, particularly if the e is along a line. Think of the adjustment at that point as being similar to a calibration. And we all know what happens when a file is calibrated vertically along a line of bench marks, which this probably is since it sounds like a dam monitoring project.

Doing it quickly isn't always the best thing for control. I spend almost no time anymore adjusting surveys, it has become so simple and trivial, but spending a couple of extra minutes seems reasonable.

> The problem is adjusting the e can really mess up the control, particularly if the e is along a line.

Agreed, but leveling observations can be treated as h differences, and if those "mess up" the control, there's something seriously wrong with the survey.

(May not pertain to large-scale projects.)

Agreed, but leveling observations can be treated as h differences

I think that would be a bad idea, they need to be connected with a geoid model to the h value, I see areas where there is over .5' per mile of differences, what that may do during adjustments, I'm just not sure, never tried to do it, but........

Perhaps I'm spoiled by working mostly in an area where the geoid model is very consistent. It tracks the ellipsoid very well.

Lol, maybe I'm jaded. I was looking at my local control file and the northeastern point had a geoid height of 47' and 20 some miles southwest it was 36'. Of course, it isn't a consistent slope in between.

> Lol, maybe I'm jaded. I was looking at my local control file and the northeastern point had a geoid height of 47' and 20 some miles southwest it was 36'. Of course, it isn't a consistent slope in between.

Does the geoid model accurately reflect these slopes?

Short answer: NO

Long answer: It's getting better, there are some pretty easy checks to do across the models without even going to the field to show that they can't all be correct.

I was working with an engineer on some oil field locations, I set control for him and he did his topos while I located section corners. He was using Geoid03 while I was using Geoid09. In six miles the geiod slope difference was .2 to .3 feet, because he is an engineer it upset him that we couldn't match and wanted to know which one was "correct". So I asked if he was willing to pay us to run levels along the 8 miles of road connecting the sites to find out. When he found out what that would cost he didn't care anymore;-)

This was a "flat" Geoid area, but still differences showed up in the models. They can't both be right is the point.

I've run lots of levels over the years and tested geoid models against them and published bench marks in my area and I've figured out that the old levels were good, that the absolute values from GPS are not good, but that the models are getting closer to the real geoid slope and if I apply the models to e and not to h things work much better.