Activity Feed › Discussion Forums › Strictly Surveying › My Least squares adjustment needs fixin’
-
My Least squares adjustment needs fixin’
jhframe replied 2 years, 4 months ago 18 Members · 46 Replies
-
Posted by: @bc-surveyor
I dont know if it matters geoid wise, but this is a traverse in the Rockies
That may be very significant. The geoid model could very possibly be haywire in such a place.
-
Thanks for some of the background info on your data, it is helpful.
I, like lots of folks here, have used various software over the years (StarNet, StarLev, LevProc, GPSurvey, TGO, TBC, LGO and any number of others from the MS-DOS days, to early Windows 95 versions). I will admit that I have not used StarNet in the recent past, but it appears to look/behave similar to the way it did years ago. StarNet was a great independent 3rd party LSA package that could accept and adjust almost any manufacturer’s data format, given the proper converter. And I agree with others that say the StarNet user interface wasn’t the most intuitive, and I could be wrong, but it appears that they have not progressed away from an ascii.txt input style, and a coordinates only .txt file “seed value” approach. (Which was both a blessing and a curse, because it was the source of it’s great ability to accept most 3rd party data formats, but also made it vulnerable to easily using incorrect/outdated “seed” values by missing a step during the recalculate/recompute phase of data reduction, or not selecting the most current .dat file reflecting those changes for subsequent processing. There were many manual steps that had to be perfect to get StarNet output correct. When everything was correct, StarNet was amazing. But all those manual steps made me less confident while reviewing the adjustment results of others when troubleshooting control issues and the .lst output file did not display a copy of the text of each file used in the sequence of calculations. You often referred to the .csv file coming out of the data collector. I’m not sure how you used that file, but hearing things like that make me a bit nervous. In my opinion, when doing this type of work, it is a big step backward to use just a coordinate file coming out of a data collector. In my experience, robust and complete raw sensor data into a full software package is key to success. To each their own.
Other manufacturers have automated/refined the processing routines such that any updates to the dataset is instantly propagated throughout the rest of the correlated data; one less thing to worry about. (Which is why I think many people commented that they’ve switched to x,y,z manufacturer software that matches their hardware.) You’ve said you’re pretty comfortable with StarNet. Cool, it’s a good software to know. But since you have Trimble hardware and the software, I encourage you to get more comfortable with TBC for data QA/QC and LSA. Once you get the hang of it, I think you’ll discover it’s a cleaner, easier, and smoother process.
Over the course of the thread, many suggested you separate your conventional and gps adjustments. This makes it easier to isolate problems. According to your screenshots, you kind of did that by using different point ranges for traverse and gps, but both appeared to be in the same StarNet project. This may be a problem because the datasets are not 100% isolated from each other and you can’t test changes in one dataset without potentially affecting the other, and vice versa. (Going through all the steps to “turn off” this gps data, or that optical data for testing iterations would drive me nuts.)
You are correct, the vertical datum should not matter when comparing just total station values to levels. If the marks were stable, and the measurements were good, the propagation of those measurments will be consistent with each other and the results will be shifted up or down based on the delta between the two datums. In this particular case, the orthometric elevations would shift by about 0.458m.
By all accounts, your field techniques appear to be effective. New level loop hits existing point = 0.016m; Traverse to existing point holding same beginning ortho. height = 0.008m. (But doing manual data entry of point id’s and HI’s for static observation processing is always a pain, and ripe with opportunity for error.)
They may have said it, but I wouldn’t hang my hat on “the Microsurvey guys said the software is incorrectly applying the geoid modelling to my conventional data.” If you’re combining levels, total statation, and gps datasets into one adjustment on a mapping projection, then there may some merit to this statement. I don’t know, I didn’t write the software.
“If I run ONLY my conventional data holding the elevation of #800 and turning off geoid modelling I get an elevation to #822 of 961.873m. Now if I turn on my geoid modelling and leave everything else the same I get an elevation to 822 of 961.752m”
If you only have optical data (levels and conventional traverse), without regard to a geometric datum (which is what you are telling StarNet to do; be on a 1.0 scale grid, 5000/5000 type system), then using a geoid model is improper, and you would be incorrectly applying geoid modeling to your conventional data. The software is not incorrectly applying geoid modelling, the user is.
In a true “local” system, your coordinate values have absolutely no relation to a published datum/projection. Good practice is to keep those coordinate values substatially different than any published datum/projection values. Your local system site is usually so far away from the real world site, any attempt to use those incompatible things will be obvious. If the software allows you to attach a geoid model to said local system, the routine will do what it can to accomodate the request. Good software should alert the user that this is not possible, or a bad idea, or similar.
In both use cases cited above, you’re fixing one end of the traverse in ortho height on a local system (no mapping projection/datum). (Think fulcrum point on a lever.) First Case: Run the traverse without a geoid model, and you hit your leveling elevation. Rightfully so; no pressure on the lever. Second Case: Run the traverse with a geoid model, and you miss by almost the exact amount of difference between CGVD28 (leveled) and CGVD2013(2010.0) (gnss) at the end of the traverse.
This is because you told StarNet to hold the ortho height of a local (non-geodetic position) point fixed, use a geoid model to compute the vertical difference associated at that point, and then try to apply that answer along your traverse. Normally, this would be nonsense. That is because when using a geoid model, the vertical componenet of your conventional data is a function of the horizontal poistion, and your local system would not fall in the realm of 3d space encompassed by the projection.
Your case is unique becuase you are using horizontal positions derived from a 3d source relative to the target geometric datum/projection as your “local grid coordinates”, which are very close (horizontally) to reasonable UTM grid coordinates. So it does give an answer, but a wrong anwer.
That’s because your “local system” technically has only one point of reference available to the geoid model for fixing the ortho height, geoid height, ellipsoid height and their position within its geoid model universe. Remember, in theory, this local system has no relation or knowledge of the geodetic datum/projection or associated hz/vt parameters in the geoid model.
Your local traverse is being rotated about the beginning fixed point (imparting a slope across the change in horizontal position along the similar orientation of the geoid model with respect to the datum/projection) such that the endpoint of your traverse is off by almost exactly the difference in the geoid model correction at your fixed point plus the measured vertical change between the two points at the beginning/end of the traverse. If you run the same process using different starting ortho heights (different vertical datum), this scenario is exacerbated by the difference between the 2 vertical datums.
In a typical GPS scenario, fixing a single ortho height of a point causes the geoid model to shift up or down to match H (ortho), and generate N (geoid). Next, does this procedure come up with a reasonable ellipsoid height that matches your gps measuement at that point? If so, great. Does this procedure compute the ortho heights of nearby points such that they are close to their leveled ortho heights? Yes? Even better! If all these factors are aligned correctly, fixing more ellipsoid heights on CORS and fixing more ortho heights for a given control network should not blow up an LSA.
I see that the site is located in the mountains, but I didn’t see a change of 300+ meters from one end of the site to the other. There’s only so much vertical relief you can design into a road per short segments, etc. Your site appears to be (effectively) flat along the route (at least as far as adjacent optical measurements would be concerned), which is probably why others commented about the deflection of the vertical being suspect as significant error source.
Obviously Canada has unique issues with topography, geoid models, projections, etc. And it appears that Canada is actively working much of the time to improve and give their CACS users the best info/data they can. I glanced back through the data sheets, but I didn’t see/can’t easily tell if #800 or #822 are either of the actual Canada leveled benchmarks. If not, hopefully, the elevation of those 2 points came from a level loop originating and closing on any number of the 5 benchmarks along your project corridor. It is more likely than not all of those remaining benchmarks (that are still present today) were included in the original level run for CGVD28 and then again in CGVD2013(2010.0).
Almost beer-thirty on a Friday!
-
I have not taken the time to read all of your post in detail. I see that you have a control point off some distance in the east direction but none from the west.
Linear projects can be very prone to exaggerating the slope because so much of the data is close to the central line of the project. Perhaps another control point removed some distance from the project to the west will allow the two distant points to act similar to outriggers on a canoe stabilizing the vertical exaggeration.
There well may be another cause that I haven’t seen for lack of detailed reading, but from experience, this jumped out to me.
Also, check your weighting. The vertical of the GNSS will not likely be as good as leveling or even good total station work. Don’t let your GNSS vertical overweigh other more precise observations.
Best wishes,
JAC -
I have had practically no processing experience to date but looking to learn. This post answered a number of questions, simple questions to most in this field I suppose, that I have been curious about. You have a way of explaining, perhaps the detail or common language, that I really connected with. Thank you for that, and will look for your future posts.
-
Thanks. I’m glad it helped.
I was fortunate early in my career to learn some valuable lessons from Alan Akman and Jessie Hummel (Caice Co-Founder and Caice/Electronic Field Book (EFB)/Florida DOT). Those two guys were a huge inspiration to me for wanting to learning the ins-and-outs of how surveying works.
Many aspects of surveying/geodesy are intense:
Learning the concepts? Okay, I’m listening.
Learning the Math? Uh, what did you say?
Learning to code? OMG, have you seen that new TikTok dance?Wanting to talk about what you do for a living with other people in the same boat because our clients and everyone else outside of our little club don’t know anything about what we do? Bingo! That’s the glue that holds us together.
There are many in this field (and related fields) that are smart, or know what they’re doing, or execute well, or effectively communicate with others. Put all of those together in a single package, and you have a winning combination.
The beauty of these message boards is that each of us is on a path, and no matter how far along the path you are, there are people in front of you and people behind you. Learning is a life-long endeavor, welcome aboard.
-
@michigan-left I don’t disagree with much of what you wrote, but though I’d point out a couple of things in reference to your Star*Net comments:
Posted by: @michigan-leftmade it vulnerable to easily using incorrect/outdated “seed” values by missing a step during the recalculate/recompute phase of data reduction, or not selecting the most current .dat file
The new version of Star*Net — which I only reluctantly bought when my v6 dongle failed — monitors the .dat file(s?) and pops up a window asking if you want to use the current version whenever a change is detected. I find this annoying, but maybe others find it useful.
Posted by: @michigan-leftand the .lst output file did not display a copy of the text of each file used in the sequence of calculations
As you probably know, including observation data in the listing file is a user-selectable option. I don’t select it, as it just makes the file larger and therefore harder to navigate, and I know where to find the obs data if I need to review it.
Posted by: @michigan-leftGoing through all the steps to “turn off” this gps data, or that optical data for testing iterations would drive me nuts.
It’s not that big a deal if your data is organized well. For small projects it doesn’t matter much, but for larger ones segregating data into separate .dat files (e.g. by field crew, by instrument, by date, etc.) makes it easy to test scenarios by just turning on or off selected files.
Star*Net aside:
Posted by: @michigan-leftBut since you have Trimble hardware and the software, I encourage you to get more comfortable with TBC for data QA/QC and LSA. Once you get the hang of it, I think you’ll discover it’s a cleaner, easier, and smoother process.
I think this makes sense for most shops. I’m not a big fan of Trimble optical gear, and as a small operator their business model doesn’t work very well for me, so I run GeoMax and Javad (except for the occasional campaign network, in which I still use a bunch of Trimble 4000SSi receivers). For pure GNSS projects I adjust in TBC, but for terrestrial and GNSS/terrestrical combinations I use Star*Net. I’d like to try TBC with terrestrial data just to see what it’s like, but I haven’t yet figured out a good way of getting my SurvCE data into a Trimble-digestible format. Maybe someday I’ll get around to writing a converter…
Log in to reply.