Does anybody use a software package that will process both GPS data and conventially measured terrestrial data at the same time?

Starnet will do both.

To clarify, Star*Net Pro will adjust both GPS and conventional data. Star*Net does not do baseline processing; you must first export the vectors from your GPS processing software into a text format readable by Star*Net.

TGO v1.5 will process baselines and adjust them along with conventional data, but I found incorporating the latter so cumbersome that I upgraded my copy of Star*Net to the Pro version so I could handle the adjustments in a more (much more) user-friendly environment.

P.S. Star*Net Pro handles the Ashtech baseline export format without complaint.
Modified By Jim Frame on 2/16/2002 at 11:44 PM

Thanks guys for the replies.

What is TGO?

Trimble Geomatics Office

Kelly,

Process your GPS observations in Ashtech Solutions, export the O Files, and adjust the GPS Vectors and your Terrestrial Observations together in StarNet.

Just my humble non-licensed opinion.

Thanks Mike, I very much appreciate your opinion and others.

After Jim's helpful reply, I went looking for StarNet on the web. Unable to find their web site, I've emailed an inquiry to them at the address listed in their P.O.B. advertisement.

In particular, I want to know if StarNet Pro can directly read in files produced by CEFB and WinCMM to process together with GPS data collected using Ashtech's ProMark2s.

I am also concerned about the price.

I've used CEFB and CMM (and WinCMM) for almost 10 years and have found that package to be quite excellent.

If StarNet Pro can't read CEFB generated observation files and /or it is too pricey, I imagine that I'll import the adjusted AS coordinates into WinCMM and assign a reasonable error estimate to the coordinates produced from GPS observations.

I'm not familiar with the CEFB data file format, but guess that considerable conversion would be required in order to get the data into Star*Net input format. There may be a conversion program already available; I'm sure Ron Sawyer will let you know when he responds to you e-mail.

As to pricing, Star*Net ain't cheap -- I believe the Pro version is in the $1600 neighborhood.

When I first began combining GPS and terrestrial measurement data, I went the "assign a reasonable error estimate to the coordinates" route, but soon found that it didn't provide the kind of statistically-supportable comfort level that makes least-squares adjustments so attractive. I bit the bullet and upgraded to Star*Net Pro, and have been quite pleased with the decision.

Kelly:

I also use Star*Net-GPS on very nearly every job to make a rigorous adjustment of the combination of GPS vectors and conventional measurements that I bring in from the field.

In my particular case, I import GPS vectors in native Trimble format, but Star*Net will import a whole variety of manufacturer's formats, including Ashtech.

As for being stuck with input files in CMM format, it sounds as if what you might think about doing is writing a utility to reformat the observations. The Star*Net input is an ASCII file, so the problem is just one (I assume) of ASCII to ASCII.

My own opinion on the cost of Star*Net-GPS is that, like many other extremely useful things, it simply costs too much not to have it. When I first bought GPS equipment, I quickly realized that while the manufacturer's vector processing software (Trimble's GPSurvey 2.35) was easy to use, the network adjustment module (TGO's predecessor, TrimNet) was funky and clunky and I'd be money ahead just to set it on the shelf and upgrade to Star*Net-GPS.

I've never regretted that decision. The ability to do a rigorous adjustment of GPS vectors in combination with conventional survey measurements takes both GPS and conventional surveying to a different level in everyday work.

Best regards,
Kent McMillan, RPLS Austin TX
Modified By Kent McMillan on 2/17/2002 at 10:31 AM

Kelly:

I am suprised that CMM won't function with the GPS data also. Ray Hintz who wrote CMM is really big on combining GPS information with conventional data. The last time he gave us a seminar on least-squares adjustment he told how he always takes a few GPS locations to strengthen his network of conventional data.

I am glad you asked this question as I have had the same one. I own Star*Net and I am about to upgrade. I am also about to purchase some GPS gear, probably the PM 2 system. So I was wondering if I needed to buy the GPS version or not. It is rather expensive for just doing adjustments. I must say that regular Star*Net has been really easy to use and very useful so I guess I'll buy the GPS version. The one down side of Star*Net is format conversions, raw data and coordinate files have to be converted back and forth.

T.Wilson - MA

I share my colleagues accolades about StarNet (it is an excellent program).

I agree with Jim Frame about TGO version 1.50. While it does everything, learning how to do a combined GPS / conventional data adjustment in TGO is not for the faint of heart. It took me quite a while to master it's black arts and I allegedly know what I'm doing. It would certainly have been simpler if there had been more examples in their documentation. But... it does work. And as it turns out, it works very well.

But, I will agree that StarNet has a MUCH shorter learning curve.


Modified By Scott Partridge on 2/17/2002 at 6:06 PM

Wow. Its sounds like StarNet is pretty much the consensus here. Thank you everybody for your comments.

Jim, Kent & Tom, CEFB is a great data collection set of programs developed by the BLM and the University of Maine. The development of CEFB ran from about late 1992 through about the end of 1998. Because of many reasons, one of which being short sightedness, the feds pulled the plug on CEFB development and have been working on NILS. The conversion factor may have already been addressed by Ray Hintz, but I am doubtful that he has written any routines for getting CEFB data into StarNet since CMM, an excellent least squares package, is where CEFB data was originally intended.

My (3) PM2s will arrive on Wednesday. Even before placing the order I was concerned about when will there be one software package that will be built with the understanding of what the surveyor needs to do with all of the different data types measured and collected?

Just by everybody's responses here, it seems that there already is market for a single, least squares package that could process GPS data, EDM data, differential leveling data, hip chain and compass data and even record data from plats and deeds - have I left anything out?

Wonder if the designers of AS have considered incorporating this blend of terrestrial data processing?

Kelly Bellis wrote:

it seems that there already is market for a single, least squares package that could process GPS data, EDM data, differential leveling data, hip chain and compass data and even record data from plats and deeds

Depending upon your definition of "process," Star*Net is an adjustment package that already does all that.

However, if by "process" you mean "produce vectors from raw GPS data," then I think the problem is that attempting to incorporate two complex and very different functions into a single piece of software almost guarantees that one or both will be less than top-drawer.

TGO v1.5, for example, can (with the appropriate modules) process baselines and adjust both GPS and terrestrial data, but its handling of the latter is dismal.

I personally prefer AS 2.5 for baseline processing, even though it's a bit less flexible than TGO. (If Trimble ever fixes the annoying proliferation of browser instances, I'll like TGO a lot better.)

Kelly:

The down side of Star*Net is that it is only an adjustment program, no COGO. I know that there have been suggestions to add COGO which has been considered.

Ron Sawyer has really done a good job with Star*Net. I have never heard anything but praise for the program, everyone who has used it likes it. I have several other least-squares programs inside my software suites but none are as easy to use and none seem to have the power of Star*Net.

Ron has never been thrilled that the government is in competition with him, giving away CMM. The fact that Star*Net is still considered a "must have program" for least-squares just shows how good it is.

Good luck with your PM 2 system. Please let us know how they work out.

T.Wilson - MA
Modified By Thomas Wilson on 2/18/2002 at 1:52 PM

Jim Frame is right in mentioning that the GPS version of Star*Net can indeed perform the functions that you mention. It does not, of course, process raw GPS data into ECEF vectors, but I'd think that it is unrealistic to want to incorporate that function into a survey adjustment program for exactly the reasons Jim Frame mentions.

I've discussed the COGO addition with Ron Sawyer before and finally decided that his take on it was quite right, namely, that most surveyors already have a COGO program that they use and think is great. It is enough simply to export adjusted coordinates to it.

I've never used CEFB, but I do have a learned friend who is a district surveyor with the Texas Department of Transportation and who is constantly telling me that it is an extremely quirky and unsatisfactory product compared to the familiar commercial data collection software.

The sad fact about the Department of Transportation involvement is that the sums of money that Texas DOT plunks into the kitty to acquire white elephant software would be more than adequate to buy TONS of good commercial software that is ready for prime time.

The great lesson that I think I've gotten from what my colleague has told me of the CEFB experiment is that commercial products will nearly always be better since they have the larger user base and competition between developers works to continually improve them. How would you like to use the NGS PAGES software to do your GPS vector processing, for example?

Note: I disclaim that I personally have used CEFB or have examined any version of CMM other than an early DOS version.

Best regards,
Kent McMillan, RPLS Austin TX


Modified By Kent McMillan on 2/18/2002 at 11:21 PM

First, a reference frame:
AASHTO SDMS

Kent McMillan wrote:
"I've never used CEFB, but I do have a learned friend who is a district surveyor with the Texas Department of Transportation... "

Your learned friend is not so learned. If he was, he would be up on the development of the AASHTO products -- SDMS (data collector) and SDMSP (field book processor. The SDMS data collector was developed by private industry, very poorly supported, and extremely expensive. Once the contract between the vendor and AASHTO expired, they came to the UMaine. Dr. Ray Hintz now supports the new, improved SDMS. (and yes, its still a commercial product and expensive).

The SDMSP (processor) is born from Dr. Ray's EFBP of florida highways department and married with WinCMM. It has a similar look and feel (nearly identical).

Two individuals from the Texas DOT are on the SDMS(p) development technical advisory committee, also represented are: Arkansas, Wisconsin, Maine. Interested in learning more? Visit this site: AASHTOWare Community

Kent McMillan wrote:
"The sad fact about the Department of Transportation involvement is that the sums of money that Texas DOT plunks into the kitty to acquire white elephant software would be more than adequate to buy TONS of good commercial software that is ready for prime time."

These "sums of money" for CEFB? Not in this reality. Not a dime. The sums of money went to a Boston firm (Cambridge Systematics) who originally did the SDMS collector mentioned above. And BTW - the only product which has the rigorous statistical analysis, least squares, import & export to casey, handles feature coding according to SDMS (national AASHTO standards), provides for SDMS calibration file, control file, and alignments is SDMS(p) -- which are actively being worked on. Not CEFB. One last thing, these Huge sums of money also provide TRAINING for DOT officials, which is the primary reason that Ray's schedule is so full.

Best regards,
V. Kelly Bellis, PLS Ellsworth, ME

Kelly:

Like most evolutionary processes, the future does decide whether a product will be around or will be another exhibit in the software museum. Somehow, I don't think I'd bet any money on SDMS, CMM, or CEFB. If I'm wrong and there is a long line of eager users for these creations five years from now, I'll buy you lunch.

If you have any interest in getting a detailed description of the shortcomings of SDMS, SDMSP, CEFB and the other suite of software that Texas DOT has gotten roped into, I'll gladly put my colleague in touch with you. I believe that while I may not have listened very carefully to the acronyms, my colleague is indeed as sharp as they come and can give you a very satisfactory explanation of why the software effort fails at the practical level.

Best regards,
Kent McMillan, RPLS Austin TX