I currently am running Carlson SurvNET that comes with my Carlson Survey software package and it works OK for the conventional stuff (standard HVD data). I notice that you can adjust GPS Vectors with it as well, but I haven't used that feature very much. Maybe I don't know all of the ins and outs of SurvNET, but it doesn't seemed to be as flexible as STAR*NET (as I remember it from the DOS days). For example, I don't think you can enter just a stand alone angle, distance or delta elevation record into SurvNET, I think it has to be incorporated into a Carlson RW5 raw file of which I don't think those are options. Also, it seems that you are restricted to the Carlson TLV leveling file format (which I don't like very much) for leveling data. Let me know if I am wrong on any of these assertions.
Anyways, I am contemplating getting STAR*NET, but at a cost of over $2000 (if you get the Pro version with the converters) it seems a bit steep. Is it worth the cost? Is it the best adjustment package out there? I have also heard that it gives more optimistic error ellipses than most adjustment packages as well. Have you noticed that as well?
Thanks,
You can write your own RW5 file from old surveys, field notes, etc.
It's certainly worth the cost over doing nothing. Is it worth the cost over the SurvNet you have already bought and paid for is the question. I have only brief experience with SurvNet - and you know I'm a huge StarNet fan - but I think maybe not. There is little doubt in my mind that StarNet is better, but only by degrees. Perhaps if you were doing a large volume of high intensity adjustments. Data format conversion issues would be a game changer, IMO. If you can't efficiently convert your data to one that can be used by the program that would kill any deal for me. In the end only you can decide. Download and give it the 10 day try out.
BTW - you should explore combining GPS vectors and terrestrial measurements. Very powerful tool.
+1
'BTW - you should explore combining GPS vectors and terrestrial measurements. Very powerful tool.'
I think it is worth mentioning that regardless the least squares program, the results should be the same. The differentiating characteristics include user instructions, user interface, data input formatting, output report and last but very significant, the terminology used. Some of the programs provide explicit information about observations that lead to locating errors and blunders.
For conventional measurements, angles and distances, the free program CMM written by Raymond J. Hintz at University of Maine for BLM will yield the same observation adjustment results as those of the $2000 Star*Net program. However, there are advantages to using Star*Net. Adjusting GPS vectors is one.
Is Star*Net "the best adjustment package ever?" If the answer is dependent upon the accuracy of the solution results, No. If some of the characteristics listed prior are, perhaps.
MLSchumann, post: 343143, member: 471 wrote: I think it is worth mentioning that regardless the least squares program, the results should be the same.
I believe that of all the adjustment programs out there, they will give you nearly the same answers concerning the final coordinates. However, I think it has been demonstrated on this forum that STAR*NET gives much more optimistic error ellipse values especially on networks with low degrees of freedom. I did an experiment on relative positional precision (RPP) last year (See the https://surveyorconnect.com/threads/relative-positional-precision-why-did-i-fail.281864/&apos ;">Why Did I Fail? post) and with SurvNET I failed the standard ALTA test miserably. However, if adjusted with STAR*NET it passed with flying colors.
The other big adjustment program out there is Columbus http://bestfit.com/ Note sure about their new web / cloud interface.
I haven't use either program, but head good things about the Columbus adjustments. No idea if either is better then your Carlson.
Also checkout "GeoLab" - it's Canadian but used to be the Gold Standard before StarNet.
OK, I got the demo version of STAR*NET to kick the tires and see how great it is.
The first test bombed right off the bat when there Carlson converter failed to convert my Carlson RW5 file. Don't know what the problem is. The file runs clean through Carlson SurvNET. I sent it to MicroSurvey to look at.
So I moved onto another Carlson RW5 and it converted without a problem.
Here is the network:
I tried to hold 103 and the azimuth between 103 and 104 fixed and this is what I got:
Any ideas why this is happening here? SurvNET does not have a problem with this. If I hold 101 and the azimuth between 101 and 102 fixed it will run, but that is not what I want to do.
Give 104 a coordinate and try again. Approximate is good enough, and let it float.
While 104 is part of the network, it might be having a problem getting started. Assign a bearing on your first course, but let it float by adding an * after the bearing, or you can assign an amount to let it float if you know what it should be, and see what happens. If that does not work, just let it close without the fixed bearing to 104 and rotate the whole thing after running Star*Net.
It is powerful stuff that likes the input data just so, but it is worth the time to figure it out.
Ken
Have used Starnet and Geolab and several others for many years. Have heard a lot of good things about Columbus but have not used it. Both Starnet and Geolab are great packages and Columbus sounds very good also. But they all work fine. I like something with an ASCII input capability, but maybe that's just me.
Jim Frame, post: 343213, member: 10 wrote: Give 104 a coordinate and try again. Approximate is good enough, and let it float.
No dice that way either...
Bow Tie Surveyor, post: 343145, member: 6939 wrote: I believe that of all the adjustment programs out there, they will give you nearly the same answers concerning the final coordinates. However, I think it has been demonstrated on this forum that STAR*NET gives much more optimistic error ellipse values especially on networks with low degrees of freedom.
I don't think that's quite right. Star*Net begins with the assumption that the standard errors of observations are known, whereas other LSA packages derive the standard errors from the adjustment. That is a very important difference in approach.
When the standard errors of observations are well characterized, they are reasonably treated as having very low uncertainties (the standard errors themselves). An example would be the standard errors of angles measured with a total station that has been tested to determine the standard errors of angles measured with it under similar conditions.
On the other hand, if the standard errors of observations are to be worked out from the adjustment itself, the uncertainties of the standard errors as derived from the adjustment will depend upon the redundancy in the survey, the number of conditions in excess of what is minimally necessary to get, for example, an angular closure. So, if there is small redundancy in a survey, the values of standard errors derived will have a very wide confidence interval and that will be reflected in the estimation of positional uncertainty.
An example would be traversing with a total station of unknown characteristics (but presumably making some assumptions about uncertainties of target and instrument centering). It is distinctly sub-pro to be surveying with instruments that don't have even a manufacturer's statement of performance behind them and trying to estimate it all from an LSA on an ordinary loop traverse.
Bow Tie Surveyor, post: 343221, member: 6939 wrote: No dice that way either...
You have 104 fixed, it needs to float. Erase the exclamation points; no need to have anything after the coordinates, Star*Net assumes no fixity if the error values are omitted.
Haven't used it in years but wouldn't it want some kinda values for 101 and 102 to get started? It seems those could be anything as you're telling it to translate to the one fixed coord and rotate about it after it's done crunching the network.
Also, Jim said to let 104 float.
OK, after adding an approximate coordinate for 101 it ran. However, I gave it enough information to solve the adjustment before. Maybe they can fix that on the next version.
Forgive the newbie question, but why are you holding 103 and B103-104? It looks like all your backsights are to 102, from which there's only a single observation to 103. Also only one observation for the 103-104 angle. If those two points have "hard" (i.e. known), coordinates, shouldn't one use those for as many other redundant observations as possible?
Jim Frame, post: 343225, member: 10 wrote: You have 104 fixed, it needs to float. Erase the exclamation points; no need to have anything after the coordinates, Star*Net assumes no fixity if the error values are omitted.
Nope. That doesn't work either. It seems to need to have an approximate coordinate on that first point or its dead in the water. They should fix that for the price they are wanting for this package.
rfc, post: 343228, member: 8882 wrote: Forgive the newbie question, but why are you holding 103 and B103-104? It looks like all your backsights are to 102, from which there's only a single observation to 103. Also only one observation for the 103-104 angle. If those two points have "hard" (i.e. known), coordinates, shouldn't one use those for as many other redundant observations as possible?
This survey is on an assumed datum. 103 is the northeast corner of my parcel that I wanted to hold my calculated coordinate position. 103-104 is the east line of the parcel I am surveying which I want to be by basis of bearing. I don't think that is an unreasonable scenario to ask of an adjustment package.