I am a LONG time user of Trimble Geomatics Office (and GPSurvey before that, and TRIMMBP before that, and TRIMVEC before that, TRIM640, etc).
I know I am not the only one who is still using TGO rather than the newer Trimble Business Center (TBC).
I am very comfortable with the stats that TGO gives (ratio, rms, variance). A false positive (i.e. saying a baseline is good when it really isn't) is extremely rare in TGO, if there is sufficient data. I have seen it give false positive results when the amount of data (i.e. length of observation) is not sufficient for the length of line, or just plain not long enough (for example 1 minute of data). On the other hand, it sometimes flags lines as poor that in actuality are just fine (i.e. false negative), as shown by repeat baseline observations. However, they can often be improved by deleting a satellite, raising the mask, etc. In any case, it is much better to have a few false negatives than a false positive.
I am trying to switch over to TBC, but one problem I am having is that it no longer uses the same stats. It now has a horizontal precision, a vertical precision, and an rms. How reliable are these? What is a good cutoff?
In TGO, the ratio should be higher than 3, and the rms under 0.02 (most important). Variance should be close to 1, but that was the least important stat.
I processed some noisy data in TGO, and got a few float solutions. These are typical 15 to 30 minute occupations, line lengths 10-15 km, done by a client. A float solution under those conditions almost always indicates a poor solution. There were a lot of lines with rms's above 0.02, and low ratios.
I processed the same data in TBC, and only two lines were flagged as poor. One 67 meter long line that was a float in TGO came up with flagged, with a horizontal precision of 0.074 m, but it agreed with another repeat baseline.
So, my question for experienced TBC users is how reliable are the stats in TBC versus TGO? Can you hang your hat on them (i.e. false positives extremely rare?).
I am still struggling with the workflow (i.e. how to fix coordinates, rename points, etc), but I know I have to eventually start using TBC. The processor does seem to be better at handling noisy data, but I want to know for sure.
I have field verified a few sets of data between the two, TBC seems to be better on all counts. I guess it really depends on if your receivers are glonass capable, as TBC can process it & TGO can't.
The precisions it reported seemed accurate as well.
My favorite aspect of TBC is the automated data import. The one thing I have never liked about Trimble, though, is that it seems TBC/TGO/whatever never has exactly the same project/datum parameters as their own data collectors (TSC2). That makes no sense to me. Not that it's anything major, but if I tell the DC that I am in VA South, Geoid09CONUS, and tell TBC the same thing, I don't like seeing a warning box with very minor differences (the one I'm thinking about is TBC says GRS80 and says the DC has "ellipsoid from data collector") pretty annoying.
That error message probably stems from using WGS84 ellipsoid on the DC and GRS80 in the software, you can run into this in Leica's products too, annoying, but technically correct.
SHG
One thing I did notice in a past project that I was comparing (that I also sent all the data to OPUS-RS) is that TBC was closer (slightly) to OPUS-RS solutions than TGO.
You must be very careful with statistics as they are similar to a bikini. What they reveal is very interesting, however....what they conceal is vital.;-)
John,
I'm following TBC on FaceBook. That seems to be one of the places you can learn more about TBC, and also YouTube. I am told that the statistics from TGO (ala WAVE baseline processor) are not in TBC because the entire approach to baseline processing is completely different in TBC. You'll see my post requesting more to read on the processor, ie, white papers or published reviewed works by those programmers in Germany, but so far nothing has become available. I only know that the processor in TBC is supposedly the same as the RTK engine in the receivers and is somewhat based on the same approach used in VRS, but, I would like to learn much more about it.
I am a TBC convert from TGO. A couple years ago I would never have believed I would say that, but since they added better functionality for total station data, I haven't looked back. There is more to do, but, I really like TBC now.
I had a similar experience processing lines underneath huge loud buzzing electric transmission towers. I couldn't tell you the KV of these things, but from the ground those cables appeared to be 3 inches in diameter and the sound coming off those lines was loud. Anyway, TGO only fixed around half of the lines. This route was around 100 miles long and under the towers the whole way. TBC fixed all the lines. And all the lines were repeated and in good agreement. I was impressed.
I will have to look into the TBC on facebook thing. Sounds interesting. I wish they still used the ratio, though.
funny that you mention about power lines. I setup a control network in the city recently AFTER someone else had already done a bunch of surveying there. Our task was to locate underground utilities: gas, sewer, fiber optic, and leave behind a pair of mons.
While out there, I shot a couple of rebar and caps from the other surveyor. I had no idea what their values were, but I provided the entire set of coordinates to my client (federal government). Well, they came back and said our coords were off by 5' or so. No way. I tied to a local CORS and a mon on a dam nearby that I set in 2003. As a check I sent my data to OPUS. I had multiple occupations, everything was within a cm. They wanted us to translate to their coordinates, I advised against it as we were using 1 ft resolution digital imagery (that is accurately georeferenced), and it would show up as a misfit in the imagery. Finally they admitted something was wrong with their data. They blamed it on the high voltage line through the site, saying the signals must have warped around the overhead wires. I suspect they used a "HERE" coordinate.
Well, they came back and said our coords were off by 5' or so
That sounds like the difference between international and US survey feet!
I have seen it a couple of times on HWY projects. It can cause all kinds of problems.
That was the first thing I thought of (US versus International), but it didn't fit.
5' is also about the error that I get with a "here" position. They may have even corrected the here point to an OPUS or CORS adjusted number, but if you're not careful in Trimble the here number can get "stuck" as the final point. I know this because it's happened to me. 😉