Along with a huge advance in capability and interoperability, the software is now windows based.
I'm not selling the stuff ... I am just a big proponate of getting away from coordinates on a stick. Use LSA, whoever makes the software.
I have only used StarNet and SurvNet. I found SurvNet to be good, but it lacked a lot of the extras I use in StarNet ... That said, SurvNet is(was?) free with Carlson Survey.
Rich
Rich Maher > Rich MaherDecember 12, 2010 at 12:29am
I am a Civil3D user and I use its LSA tools in all of my survey/mapping projects. Unfortunately, I do have some frustations of its Survey module. Autodesk FBK does not support multi-setting, resection, local to grid transformation, and other things. I wasn't able yet to briefly browse the Star*Net manual you sent me (you're the man Rich! Thank you so much for the manuals.) Are those three items included in Star*Net LSA process? As you said, it is a one-stop-shop. Thank you Rich!
Rich Maher > Arnel M. DomagDecember 12, 2010 at 12:24am
I'm not sure what multi-setting is ... probably just a matter of different terms. Can you explain?
Resection? Absolutely. In later discussions we can talk about how to make your particular brand of data collection software work into your process with StartNet ... there are always some considerations you have to keep in mind. For example, if I have to do a resection in the field, I do one using the data collector routine (SurvCE). Unfortunately, SurvCE doesn't store my observations during a resection as true observations (this is probably the only time it does not do what it should). SurvCE then creates a result for the instrument position. Back in the office, when I convert me .RW5 file to a .DAT file to process in StarNet, I don't have all those good angles available. I believe I could manually edit the text file in a few minutes to bring the data in ... but honestly we rarely resect and need the coordinates in the field, so this is what we generally do:
Set up on an unknown point. Backsight either a known or unknown point. Then turn 2 complete angle sets with distances to 2 or more known points. Back in the office, I drop these observations in and StarNet includes this point in the processing and adjustment and we get the best possible coordinate in the end for it. If I had done a data collector resect, that's OK ... just shoot the same points again, but as observations and when I get back in the office, the unknown point is created exactly the same and I can compare that with the field derived coord if I want.
The most difficult thing about getting used to a good LSA program like StarNet is to lose sight of the coordinates you are creating on the fly in the field. Really ... forget about them. We bring in just the raw observations ... then, we seed some approximate coordinates and a direction and process the measurements to evaluate our survey. Only after our survey is examined and found to be good will be start to fix one or more control points or values.
Here is a thing that was hard to work with until a process was developed that the field crews became routine at ... Our data collector needs coords to start. As we work it creates coords for every point we observe. If at any time during the survey we observe a previously observed point, the data collector complains if we try to use the same point number. The conversion program is set up to handle this situation. Just give it the same "check shot" number you normally would, but in the description use a control code like "/" and the original point number. During conversion all observations to the check point are now coded to the original point number. It is the same point, right? So we want to end up with only one point! Not the first point and 3 check shots "almost" on it. The second option is to use the original point number. Most collectors will warn of over-writing the point. No problem. You have 2 observations and later Starnet will include both of them and use that in the adjustment. In the end, we throw all the coordinates away. In our data collector that's a .CRD file that we download and never look at.
Here is a crazy idea for those of you with data collectors like mine... Network surveying. I really don't need to know where I am at anytime during the survey. I'm just taking measurements. I can start one crew on one side of the job with assumed coords, another on the other side with more assumed coords, and have someone else taking static measurements from a base to control that either crew has set. Everyone has a system that is creating coordinates ... assumed or autonomous GPS ... but you bring it all back into the office and process the measurements simultaneously to get one homogenous set of points. This is akin to the real-world project that started this whole conversation. I have one currently being completed in the field: The crew set a local base, then collected a handful of static lines to control scattered about the project. The next few days they worked on either end of the job, just using assumed ground coordinates and eventually tying into some county GPS points conventionally. The final day they will connect the two assumed surveys in the middle. I don't even want to imagine how much work it would be to process this the old way I used to. I already processed the baselines and created a .DAT file for StarNet. Each day the crew processes their .RW5 file into a .DAT file correcting any issues they encountered (e.g. prism heights). Next week I will give StarNet an approximate GPS coord and elv for the base station. Then I will run all the data at once. If I find any blunders or questionable items I'll figure what they are an eliminate them. Once I'm happy with the measurements it's time to feed in one of the county GPS coords and any BM elevations of BMs that were shot during the survey. I'll actually put in all the control, but won't fix any of it except one X,Y,Z (that can be lat/lon or N/E and Ellipse or Ortho). One section of the report gives you the comparison with non-fixed control so you can instantly see if you're going to be honing into something good or should question your provided control and/or methods. From that point I fix one control after another with individual adjustments to watch and observe the resulting comparisons until I have my final values.
StarNet needs to work on a GPS capable reference frame if you include GPS vectors. Otherwise it can work on a local plane coordinate system. After processing, you can export in many different formats and create a local ground plane system (something we're working more and more away from).
Well, that's a lot more than I intended to type but hopefully it answers your question. Read the manuals I sent ... order the demo CD ... It took me a bit to get going on LSA and I wish I'd started with it when I first started surveying. In the beginning, I processed my GPS in it's own manufacturer LSA program and brought those coordinates into StarNet as fixed points. Since then, being able to use the vectors (measurements) I can really do some trick stuff and make efficient and accurate surveys I could not before.
Replies
I'm not selling the stuff ... I am just a big proponate of getting away from coordinates on a stick. Use LSA, whoever makes the software.
I have only used StarNet and SurvNet. I found SurvNet to be good, but it lacked a lot of the extras I use in StarNet ... That said, SurvNet is(was?) free with Carlson Survey.
Rich
http://www.microsurvey.com/products/starnet/
The new owners of the software have a pretty good page up. I haven't gone through it all yet, but I saw a video there to watch.
Rich
I am a Civil3D user and I use its LSA tools in all of my survey/mapping projects. Unfortunately, I do have some frustations of its Survey module. Autodesk FBK does not support multi-setting, resection, local to grid transformation, and other things. I wasn't able yet to briefly browse the Star*Net manual you sent me (you're the man Rich! Thank you so much for the manuals.) Are those three items included in Star*Net LSA process? As you said, it is a one-stop-shop. Thank you Rich!
I'm not sure what multi-setting is ... probably just a matter of different terms. Can you explain?
Resection? Absolutely. In later discussions we can talk about how to make your particular brand of data collection software work into your process with StartNet ... there are always some considerations you have to keep in mind. For example, if I have to do a resection in the field, I do one using the data collector routine (SurvCE). Unfortunately, SurvCE doesn't store my observations during a resection as true observations (this is probably the only time it does not do what it should). SurvCE then creates a result for the instrument position. Back in the office, when I convert me .RW5 file to a .DAT file to process in StarNet, I don't have all those good angles available. I believe I could manually edit the text file in a few minutes to bring the data in ... but honestly we rarely resect and need the coordinates in the field, so this is what we generally do:
Set up on an unknown point. Backsight either a known or unknown point. Then turn 2 complete angle sets with distances to 2 or more known points. Back in the office, I drop these observations in and StarNet includes this point in the processing and adjustment and we get the best possible coordinate in the end for it. If I had done a data collector resect, that's OK ... just shoot the same points again, but as observations and when I get back in the office, the unknown point is created exactly the same and I can compare that with the field derived coord if I want.
The most difficult thing about getting used to a good LSA program like StarNet is to lose sight of the coordinates you are creating on the fly in the field. Really ... forget about them. We bring in just the raw observations ... then, we seed some approximate coordinates and a direction and process the measurements to evaluate our survey. Only after our survey is examined and found to be good will be start to fix one or more control points or values.
Here is a thing that was hard to work with until a process was developed that the field crews became routine at ... Our data collector needs coords to start. As we work it creates coords for every point we observe. If at any time during the survey we observe a previously observed point, the data collector complains if we try to use the same point number. The conversion program is set up to handle this situation. Just give it the same "check shot" number you normally would, but in the description use a control code like "/" and the original point number. During conversion all observations to the check point are now coded to the original point number. It is the same point, right? So we want to end up with only one point! Not the first point and 3 check shots "almost" on it. The second option is to use the original point number. Most collectors will warn of over-writing the point. No problem. You have 2 observations and later Starnet will include both of them and use that in the adjustment. In the end, we throw all the coordinates away. In our data collector that's a .CRD file that we download and never look at.
Here is a crazy idea for those of you with data collectors like mine... Network surveying. I really don't need to know where I am at anytime during the survey. I'm just taking measurements. I can start one crew on one side of the job with assumed coords, another on the other side with more assumed coords, and have someone else taking static measurements from a base to control that either crew has set. Everyone has a system that is creating coordinates ... assumed or autonomous GPS ... but you bring it all back into the office and process the measurements simultaneously to get one homogenous set of points. This is akin to the real-world project that started this whole conversation. I have one currently being completed in the field: The crew set a local base, then collected a handful of static lines to control scattered about the project. The next few days they worked on either end of the job, just using assumed ground coordinates and eventually tying into some county GPS points conventionally. The final day they will connect the two assumed surveys in the middle. I don't even want to imagine how much work it would be to process this the old way I used to. I already processed the baselines and created a .DAT file for StarNet. Each day the crew processes their .RW5 file into a .DAT file correcting any issues they encountered (e.g. prism heights). Next week I will give StarNet an approximate GPS coord and elv for the base station. Then I will run all the data at once. If I find any blunders or questionable items I'll figure what they are an eliminate them. Once I'm happy with the measurements it's time to feed in one of the county GPS coords and any BM elevations of BMs that were shot during the survey. I'll actually put in all the control, but won't fix any of it except one X,Y,Z (that can be lat/lon or N/E and Ellipse or Ortho). One section of the report gives you the comparison with non-fixed control so you can instantly see if you're going to be honing into something good or should question your provided control and/or methods. From that point I fix one control after another with individual adjustments to watch and observe the resulting comparisons until I have my final values.
StarNet needs to work on a GPS capable reference frame if you include GPS vectors. Otherwise it can work on a local plane coordinate system. After processing, you can export in many different formats and create a local ground plane system (something we're working more and more away from).
Well, that's a lot more than I intended to type but hopefully it answers your question. Read the manuals I sent ... order the demo CD ... It took me a bit to get going on LSA and I wish I'd started with it when I first started surveying. In the beginning, I processed my GPS in it's own manufacturer LSA program and brought those coordinates into StarNet as fixed points. Since then, being able to use the vectors (measurements) I can really do some trick stuff and make efficient and accurate surveys I could not before.
Take care,
Rich