Reading RPLS is free for the whole profession. Members post, reply, and get the members-only rooms.
I typically process traverses in Civil3d. We use SurveyPro in the field. My workflow is export .raw from Ranger7 collector>convert to .fbk with c3d>edit .fbk>import into c3d and process.
My company recently purchased Star*net and I'm trying to figure it out. What kind of file should i be exporting from my dc to convert with starnet for best results?
Does anyone have an example of a surveypro file that has been successfully adjusted? I just want to see what its supposed to look like.
What kind of file should i be exporting from my dc to convert with starnet for best results?
Converting Spectra Precision Survey Pro v 5.0 raw data to STAR*NET format
OK. I've got converting down. and even some editing. I ran a traverse around a lake but the client wanted different sections at different times. Now that I'm done traversing, how do i go about putting the different files together so it processes them as one loop?
If you maintained the same point numbering system (i.e. didn't use the same point number for more than one physical point), then you can just add the new Star*Net data to the original dat file and rerun the adjustment. Alternatively, you can put the new data into a separate dat file and add it to the adjustment via View|Data Input Files|+.
If you duplicated point numbers in the second dataset (same point number but different physical point) you'll have to edit the dat file to distinguish the points from each other. Since Star*Net recognizes alphanumeric point IDs, you can accomplish this by prepending or appending a letter to the new point numbers (e.g., point 101 becomes 101A).
Similarly, if your second data set uses the same physical control points but assigned them different point numbers, edit the file to change the point numbers to correspond to their IDs in the original dat file.
Similarly, if your second data set uses the same physical control points but assigned them different point numbers, edit the file to change the point numbers to correspond to their IDs in the original dat file.
I use the inline command .alias name and make a list of the points this way my raw data stays as it was collected.
.ALIAS NAME 1 1a 1b 1c #points 1a, 1b and 1c are explicitly aliased to point 1
.ALIAS NAME 2 2a #point 2a is explicitly aliased to point 2
You can also use Adjust Network with Cluster Detection. It will find the duplicates, give you a error list on how they check and then let you combine them or not hold one or the other.
I use the inline command .alias name and make a list of the points this way my raw data stays as it was collected.
Although I had to upgrade from Star*Net v6 to v11 some years ago due to a hardware key failure, I never bothered to see what features had been added since v6. Alias is one of them, and I'll be sure to make use of it in the future. Thanks for pointing that out!
Alias is one of them, and I'll be sure to make use of it in the future.
On second thought, Alias won't address the duplication problem I encounter most often: combining data from one project with numeric point names (e.g. 1, 2, 3...) with data from another project that also uses numeric point names but in which the same physical point is assigned a different number (e.g., point 1 in file A is the same as point 12 in file B). In that scenario, aliasing 12 in file B to 1 in file A will create a conflict with 12 in file A. So I'd still have to edit one of the dat files to eliminate the duplication, and if I'm going to do that I may as well skip the Alias effort.
I think I see what your saying. Crossing between projects can be tough when your duplicating point numbers in each and then want to combine them. You would, I guess add a letter to each point number to represent each specific project. Then you could alias the points in common.
When crews shoot a control point from a different set up as in a cross tie, they will add a letter to the point and make a note in the description.
Alias won't address the duplication problem I encounter most often: combining data from one project with numeric point names (e.g. 1, 2, 3...) with data from another project
For many years I created separate dat files for each day of data collection. For the last couple years I've taken to accumulating all the data in a single file. No negatives and some positives. Would solve this problem for you.
Would solve this problem for you.
I always use a single RW5 for a given job, downloading it daily upon return to the office. Where I run into the multiple point number thing is when I later take on a different project adjacent to or overlapping the original. Since I generally run control as I'm picking up topo, control point numbers are scattered throughout, so trying to reuse the old control numbers isn't a practical option. I'm used to editing my raw data and dat files anyway to fix things like HI, HR, offset, and description goofs, so I'll just keep editing point numbers as needed.
I appreciate all the info guys. How do you report your error of closure? like normally we say it's 1:20,000. will starnet tell me that?
How do you report your error of closure?
You do not. You report station coordinate errors, typically at the 95% confidence level.
You report station coordinate errors, typically at the 95% confidence level.
That is, if you report anything. I think I can count on one hand the number of times I've been asked to report error statistics. I suppose it all depends on who your clients are and the nature of the work.
I do look at the stats, of course. Anytime an adjustment fails the chi square test on the high end I dig in to find out why, and fix the problem unless the job specs are much looser than my control net. Adjustments that exceed the lower bound -- which happens fairly often -- don't bother me much.
Adjustments that exceed the lower bound -- which happens fairly often -- don't bother me much.
It doesn't mean anything, of course. But I don't like to leave a document in my files that contains the words "failed the chi-squared test" no matter the reason. It seems like attorney chum to me. So I'll make amendment to the a priori assumptions and clean that up with one last run.
You can use the T record for your data and include a summary with closures as we were accustomed to seeing the "older" days.
Input example
Report example
You still get all the benifits and results from startnet but a more familiar reporting to help understanding the more modern reporting.
We typically run redundant rtk observations on control points, average and then scale them to horizontal ground. Then run traverses in horizontal ground between pairs. Is this a good way to do things if we plan on using starnet to adjust our control networks? Or should we do everything in grid and then let starnet scale it to ground? I noticed when I selected Grid for the coordinate system setting, it was reducing all of my distances to grid so I changed the setting to Local and then it didn't do that and it passed the chi square test. At some point I'd like someone to look at my results just to be sure that I'm doing this correctly. Which files would I need to post for a proper examination if anyone had the time to look at them? I really appreciate the help.
We typically run redundant rtk observations on control points, average and then scale them to horizontal ground. Then run traverses in horizontal ground between pairs. Is this a good way to do things
StarNet will produce a .gnd file, if you ask it to, that is a scaled, translated, and rotated version of the grid coordinates. Usually, for me, when I use it, the translation and rotation is zero. So you can combine your GNSS vectors and TS traversing in a single adjustment while automatically outputting ground scale stuff.
That said, in Oregon we have a system of low distortion projections which I do all my jobs on. So there is no need for me to engage in this scaling to ground tomfoolery. It won't be long before your state gets such a system to call its own, if not already.
Can someone explain to me the reason for calling the same point different names when you hit it again? Like 101, then 101A, etc.
StarNet will produce a .gnd file, if you ask it to, that is a scaled, translated, and rotated version of the grid coordinates.
I use this feature a lot to convert grid coordinates to ground coordinates with the orientation (basis of bearings) of a filed map. I only wish it allowed translation of the vertical as well, so I could match a local bench mark.
Can someone explain to me the reason for calling the same point different names when you hit it again? Like 101, then 101A, etc
Some data collectors will not allow reuse of numbers under certain conditions. Plus, a(n unfounded) fear of overwriting previously collected data.