Here's my question: Would least squares be a good solution to a traverse like this (if so what am I doing wrong in StarNet)? Or should I just adjust the azimuths and do a compass rule adjustment in Carlson?
Here are the details: We have a 9 mile traverse up a rail trail done in Leica Viva software with a MS50 1" instrument. The traverse was run in an assumed system with a compass azimuth to start. 3-4 sets were taken at each turn.
We have 5 sets of azimuth pairs in there. The GPS was collected in RTN mode on the NYSNET network but raw data was also collected. We only have one GPS unit at the moment so each was collected individually with 45 min observation lengths. I processed these through OPUS-RS and got results that were within a couple of hundredths of my RTN results.
I know how to process this in Carlson with Compass Rule but the problem is that Viva will only export traverse data in azimuth readings not angles right. You can export sideshot data with angle right but not traverse data (at least that I have found). Normally I would just change the starting coordinates in the .rw5 file and remove the initial compass azimuth reading. Since it's angles right it will automatically just work from the new starting points. But since it is azimuth records, I will have to calculate the starting azimuth of the new starting pair then adjust each observation in the entire .rw5 file accordingly. Carlson has a pretty easy way to do this but still a pain.
I tried processing it in GeoOffice but the files from the MS50 don't seem to import into GeoOffice. I tried processing it in Infinity, but it will not let me create the traverse properly and when I try to adjust the coordinates of the starting points the observations and even a lot of the coordinates do not update. Leica's support has been useless. I've waited weeks for answers, gotten answers for questions I didn't ask, etc.
But then I started wondering if Least Squares would be a good solution here since I have 6 azimuth pairs through this traverse and a lot of sets of angles. I started playing with StarNet a bit and got a demo. I created a .dat file with all the observations by importing the leica data. I added my control points at the top of the file as "C" entries with "!!!" after. It seems to process good 2D (we obviously have a vertical bust that I have to look for) but it moves the whole thing about 1.5 feet to the southwest. I can't figure out for the life of me why...Also is it adjusting those azimuth readings to match the new starting coordinates? Could this be part of the shift problem or another issue?
SO....Would least squares be a good solution to a traverse like this (if so what am I doing wrong in StarNet)? Or should I just adjust the azimuths and do a compass rule adjustment in Carlson?
Thanks!
If you would like to email me (via SurveyorConnect) your StarNet dat file I'll run it in the morning. The process you describe is just the thing StarNet is great at. As far as your 1.5 feet, I suspect a US Foot / International Foot conversion thing.
Hello, I have lived problem years ago that like you.
Your method is possible, but may be you have a wrong in StarNET. Can you send me the .dat file, may I can help you
(My mail adress is: bingeomap at gmail.com)
(That problem is a big mistake of Leica-Geosystems company, I think that. Therefore, I don't like work with files of Leica TSs.)
You can export the angles from the instrument, you just need the right FRT setup.
party chef, post: 332468, member: 98 wrote: You can export the angles from the instrument, you just need the right FRT setup.
How? I can do it with side shots but not with a traverse.
Tom
I added my control points at the top of the file as "C" entries with "!!!" after. It seems to process good 2D (we obviously have a vertical bust that I have to look for) but it moves the whole thing about 1.5 feet to the southwest. I can't figure out for the life of me why...Also is it adjusting those azimuth readings to match the new starting coordinates? Could this be part of the shift problem or another issue?
my initial thought is what some call 'coordinate seeding strategy', a fancy phrase for deciding what to use for control and how stringent that station's coordinates are held.
rtn azimuth pairs might be better off, overall, to hold a control (as you already have), however, instead of holding them absolute with the !!! in star net, try this: use each rtn/gps station, but allow for the station's uncertainty. these numbers you can get from LGO, or OPUS. maybe try holding all of the GPS stations by their estimated uncertainties, then re-compute the given star net. try something on the order of 0.02,0.02,0.10 for each GPS station, and remove azimuth constraints.
in theory, a nine mile traverse with a 1.5 foot correction is 000å¡00'06.5", so you might be well within reason. if the whole network is being translated 1.5 feet, then you should search for other possibilities, such as usft and int ft, as mentioned above.
I am going to add in the uncertainties to the RTN points for the final process...
For the 1.5 foot shift...Mark was correct that it was listing international feet in the .dat file.
Tom
RTN positions are not perfect. They never are. So it is well to give them a reasonable standard error.
Instead of using !!! for all points, thus holding everything, use a small standard error. Replace "!!!" with "0.03 0.03 0.03". Turn on "Coordinate Changes from Entered Provisionals" in your listing file. Run it, and see which points change the most from the entered provisionals. Free up the worst of them by replacing the "0.03 0.03 0.03" with "* * *".
Right now, I've freed #199 and freed up the elevation on #57.
You have a measure up bust on the target at line 2806 of the dat file.
In spite of your gun being a 1" model, you seem to be getting an angular precision something closer to 3". Which is common with 1" guns, in my experience.
Changed your centering errors to 0.003/0.003/0.01 for instrument/target/ measure up, which is what I commonly use.
The adjustment is a good one, all in all.
Mark
Thank you! All good info and learning experience!
Tom
