Here's the situation:
Using a conventional gun, SurveCE, and TraversePC in the "office", I set out on a traverse...say an alignment, on day 1; record a bunch of sideshots, and traverse points; download the .rw5 to the office software.
Then, on day 2, go to the last traverse point, "continue last job" in SurveCE, backsight to the previous traverse point (set to 0-00-00), and repeat. Assume this goes on for days across as much as a couple of weeks.
If I try to bring the .rw5 in again, it brings ALL the points in again. If I've already translated and rotated the initial portion of the traverse, I've got to strip out all but the latest observations. I've also got to rotate, and translate the first point of the new day's work to the last point of the previous day's work.
Before you know it, I've got a mess on my hands. I want to develop a consistent routine that creates the least amount of work and chance for error. The way I'm doing it now can't possibly be the best way to do it.
So, what's the "right" way to do this? Create, and logically name new .rw5 files each day? Set the azimuth on the initial back sight and carry it all the way through to the next day's setup? Any other procedures to make this less error prone and more transparent?
Processing the file in Carlson Survey, you can keep separate files for each day's work. Begin each new day on the yesterday's last setup and shoot away. Then go into the office and download that day's .RW5 file. Go to the process area and edit the file to remove any coordinates for that initial setup. Your drawing should be open with the current .CRD file set and all of the points inserted. When you process the new file it will then reference the .CRD's values of your control points and everything should be on the same system.
The real key here is to remove any coordinate values in the RW5 file that were hand keyed or otherwise entered from a prior data session.
> Processing the file in Carlson Survey, you can keep separate files for each day's work. Begin each new day on the yesterday's last setup and shoot away. Then go into the office and download that day's .RW5 file. Go to the process area and edit the file to remove any coordinates for that initial setup. Your drawing should be open with the current .CRD file set and all of the points inserted. When you process the new file it will then reference the .CRD's values of your control points and everything should be on the same system.
> The real key here is to remove any coordinate values in the RW5 file that were hand keyed or otherwise entered from a prior data session.
Thanks. I'm not using Carlson Survey, but what I gather is that you start with a new .rw5 each day. Do you carry the backlight azimuth and coordinates of the last point into the new file?
> Using a conventional gun, SurveCE, and TraversePC in the "office", I set out on a traverse...say an alignment, on day 1; record a bunch of sideshots, and traverse points; download the .rw5 to the office software.
>
> Then, on day 2, go to the last traverse point, "continue last job" in SurveCE, backsight to the previous traverse point (set to 0-00-00), and repeat. Assume this goes on for days across as much as a couple of weeks.
The standard solution familiar to me would be to survey the control traverse without all the tons of sideshots, adjust it and bring the ADJUSTED coordinates of the control points into the data collector (if you can) as a control file for further mapping work. I assume that Carlson has the option of linking a job file to a control file so that when you, say, set up on some control point whose adjusted coordinates reside in the control file and backsight another also in the control file, the DC will retrieve those adjusted coordinates and proceed accordingly.
That way, you can make each day's work a separate project and add it to the adjustment on a day by day basis if you want or you can just download the project through that day as a backup against the DC having a seizure and then just add the "final" comprehensive version to the adjustment, ignoring the earlier backup versions that are included in it.
> Here's the situation:
> Using a conventional gun, SurveCE, and TraversePC in the "office", I set out on a traverse...say an alignment, on day 1; record a bunch of sideshots, and traverse points; download the .rw5 to the office software.
>
> Then, on day 2, go to the last traverse point, "continue last job" in SurveCE, backsight to the previous traverse point (set to 0-00-00), and repeat. Assume this goes on for days across as much as a couple of weeks.
>
> If I try to bring the .rw5 in again, it brings ALL the points in again. If I've already translated and rotated the initial portion of the traverse, I've got to strip out all but the latest observations. I've also got to rotate, and translate the first point of the new day's work to the last point of the previous day's work.
>
> Before you know it, I've got a mess on my hands. I want to develop a consistent routine that creates the least amount of work and chance for error. The way I'm doing it now can't possibly be the best way to do it.
>
> So, what's the "right" way to do this? Create, and logically name new .rw5 files each day? Set the azimuth on the initial back sight and carry it all the way through to the next day's setup? Any other procedures to make this less error prone and more transparent?
I dump it into Star-net. It handles side-shots just fine.
But, if I rotate and translate, I will start a new job, if I want all the points in the job to look at, and reference for F2F, or whatever, I simply import them into the new job. When you see the .rw5 file, it has all those coordinates listed right at the start, you can edit them, or whatever. Yes, my new coordinate file has all those points, but I only use the final .crd, with all the points and connections (since I use F2F).
Note to any Carlson programmers out there, being able to look at my control file points on the Map screen would be nice, and then I would have no need to import into my .crd, I would have all the existing points as a control file.
If I translate and rotate, I start a new file. There are lots of reasons for that, not least being that it creates a cleaner, more usable .rw5 (IMHO).
This sounds much like what Kent is saying, but I am pretty sure he runs everything into Star-net, as well, since it just makes sense.
> This sounds much like what Kent is saying, but I am pretty sure he runs everything into Star-net, as well, since it just makes sense.
Yes, I run everything through Star*Net. However, I do like to keep the basic control network as a separate Star*Net DAT file from the DAT files that may have a jillion shots that are simply for mapping topo features and what not, none of which contribute anything to the adjustment of the survey network.
If I position an unmarked station (a free station) by resection between two control points, I'll usually cut and paste those observations into the control file since they usually improve the vertical in particular.
The reasons for splitting the DAT file are that:
(a) you can turn all of the mapping clutter off completely, both in the listing file and in the plot, and deal just with the "bones" of the survey, the control network, ties to boundary markers and/or benchmarks, and GPS vectors, which simplifies debugging and
(b) in the future you can copy that basic control survey file to another job if you want to.
The reason I prefer to work off of an adjusted control network of known quality is that then when I'm setting up to resection off a couple of the points and survey a jillion sideshots from that free station, I can rely upon the resection residuals to assure me that there won't be any surprises when it's added to the overall adjustment. That and sometimes there is setting out to be done at the same time that topo detail is mapped.
Thank you, Kent. You raise several points I hadn't even thought of (nothing new there:-) ).
> The standard solution familiar to me would be to survey the control traverse without all the tons of sideshots, adjust it and bring the ADJUSTED coordinates of the control points into the data collector (if you can) as a control file for further mapping work.
Yes, I can import into the data collector either an ASCII file of the coordinates, a TDS CR5 file, or even a TraversePC .trv file (haven't tried either of the latter).
>I assume that Carlson has the option of linking a job file to a control file so that when you, say, set up on some control point whose adjusted coordinates reside in the control file and backsight another also in the control file, the DC will retrieve those adjusted coordinates and proceed accordingly.
Yes, I've seen that option and asked a question about it some time ago, but have never considered doing what you're suggesting. I'll try it.
>
> or you can just download the project through that day as a backup against the DC having a seizure...
Prescient thought there. You must have done this once or twice before. Happened Sunday. Last leg of the day; Batteries in the DC went Kaput! While I only lost the last Backlight/foresight this time, I like working in smaller file chunks in case the thing goes really bananas.
Thanks for the ideas.
I take an approach similar to Kent's, except that I maintain a single DAT file, even when there are thousands of sideshots involved. Being able to turn off the sideshots in the graphic display is enough for me when viewing the network geometry, and I untick the "Copy of Input Data Files" option to keep the listing file relatively uncluttered.
As noted in an earlier thread, I usually have to edit my raw data to fix field goofs (wrong HR, wrong OC or BS point number, etc.), so I append the day's raw data to the RWB (my edited raw data file), fix the mistakes, and use the RWB as input to my Star*Net converter. I then run the adjustment to check for blunders, and import the day's points into my drawing file. I also dump the old control from the drawing and bring in the newly-adjusted control points.
As an example, I'm currently working on a topo of an approximately 30-acre densely-improved veterinary medical teaching hospital site, and have followed this procedure. I ran the exterior control before any topo, but have established dozens of internal control points since then due to restricted sight lines. I have about 65 field hours into it so far, and am maybe 65% done, with about 3,800 points gathered to date. Drafting is about 95% finished on 15 or so acres due to client need for preliminary topo in that area, and maybe 70% on another 5 acres. I'm trying to keep the topo moving along with the field work so I'll be ready to hand over another nearly-completed piece soon.
Whenever a piece of the supplemental network looks like it might significantly tweak the overall, I sample the old versus new adjusted values to make sure something hasn't gone awry. Typically, the differences are too small to be concerned about for topo, at less than 0.01' H&V (and often only a small fraction of that).
While this isn't directly comparable to a pure traverse situation, it does illustrate that daily measurement data can be incorporated into the adjustment workflow without having to wait until all the measurements are done.
A conflict of the Great Minds?
> I append the day's raw data to the RWB (my edited raw data file), fix the mistakes, and use the RWB as input to my Star*Net converter. I then run the adjustment to check for blunders, and import the day's points into my drawing file. I also dump the old control from the drawing and bring in the newly-adjusted control points.
>
My original question wasn't necessarily regarding control networks, per se...just regular daily work that comes into the office through multiple days.
But I think I'm getting great additional information and thoughts on my question in a previous thread, wherein I asked:
>>Is it better to do LSA at a given point in time with what you've got, then carry those adjusted coordinates forward, combine them with new observations as they're taken, and run LSA again? Or, should ALL the original observations be kept un-adjusted, and run LSA "globally" with all the observations taken, beginning to end?
The only problem now is that there seems to be different opinions on the subject (adjust all at once or incrementally).
The venerable Norman Oklahoma said:
> ... ALL the original observations be kept un-adjusted, and run LSA "globally" with all the observations taken, beginning to end?
> That one. Hands down. Slam dunk. No question.
"All at once" seems easier for a grasshopper to manage and keep track of compared to Kent's or Jim's process (i.e. file naming convention, locations, etc. both on the desktop and in the DC.) Bear in mind, this is a learning situation; there are no deliverables.
A conflict of the Great Minds?
> The venerable Norman Oklahoma said:
I'm not sure how I feel about being called "venerable".:-/
Keep in mind that Kent, and I think Jim, are solo operators who collect what they process themselves. And dmyhill is the boss in his office. I'm a worker in an engineering office who has to deal with data that comes in from sources I don't have direct hiring/firing control over. IN the last week I've had the pleasure of running two different adjustments on data collected in 2012 and 2013 by people I've never met who were using equipment I've never seen. So it goes. And while a lot of my projects involve a day or 2 in the field some of them run into weeks and even months of daily files from multiple crews. It all makes a difference.
I like to have separate raw data files for each day - this, in part, to ensure that each day's data gets backed up at the end of the day - and separate StarNet dat files that correspond to each raw data files. This also allows me to review the day's work with the crew before they return to the site or carry on to the next project. In spite of all efforts to standardize procedures each crew will have their own variations.
I will sometimes split the dat files for each day into 2 or perhaps 3, control, boundary, topo. I accumulate them all under a single StarNet project, usually, and activate/deactivate those files I want for each adjustment run.
I'm often working on projects that require several days field work, or more, to complete. I want the primary control network finalized before processing any topo. If the project is going to take more than a couple of days I insist on running the primary control first, then returning to collect topo. Little side loops necessary for boundary and topo collection can be added to the primary as they come.
Finally, my procedure is intended to be both scalable - workable for small, medium, large projects - and for small jobs that turn into large jobs - and teachable to the technicians I work with. If I were a solo operator I might well modify them.
How do you create a new raw data file for an existing job in SurvCE? I don't think you can. I think you have to create a new job and then import an text file with the previous day's points.
If I remember correctly, in TDS you could simply stay in the current job and create a new raw data file and go to work.
Am I missing something? Is there an easier way to create a new raw data file in SurvCE?
A conflict of the Great Minds?
> I'm often working on projects that require several days field work, or more, to complete. I want the primary control network finalized before processing any topo. If the project is going to take more than a couple of days I insist on running the primary control first, then returning to collect topo. Little side loops necessary for boundary and topo collection can be added to the primary as they come.
I think the main difference in practice that I read in the above is that Norman has to deal with a number of unknowns in his work that those of us who are both out in the field and making calculations in the office do not. Reading between the lines, his approach would seem more oriented toward quarantining elements of variable quality work so that it can be treated separately in the project adjustment.
I've made quite a few surveys that took weeks to finish and SOP is to download the day's data and add it to the Star*Net adjustment file. This serves two functions:
(a) to identify any possible blunders that will require rechecking, and
(b) to inspect the positional uncertainties of project control points to identify any parts of the network that will require additional observations for improvement.
Usually, the control survey has three components:
- OPUS solutions,
- GPS vectors from some control points positioned, either directly or indirectly, via OPUS,
- conventional measurements between control points positioned via GPS, and
- side shots to boundary markers found and set.
You want to have the file set up so that the individual GPS and DAT files may be turned on in the adjustment in a logical heirarchy, checking each for consistency with the others as you do so.
Naturally, many control surveys will also have a leveling component. Boundary surveys typically do not.
Operationally, it is much simpler to keep:
- OPUS solutions in separate files,
- GPS vectors in another file (usually separating sub-meter mapping vectors such as those along meandering waterways from sub-centimeter quality work)
- Control survey measurements and topo measurements separate.
The reason for separating control and topo is that the procedures used are typically different, the control survey being made with greater care and the topo only that level of care required for the mapping.
For projects that extend over many years as happens when one returns to earlier work, it is also a smart idea to separate the input files by year as this will make the usual fact that different equipment and procedures were used easier to account for in the standard errors assigned to the observations in the adjustment.
> How do you create a new raw data file for an existing job in SurvCE? I don't think you can. I think you have to create a new job and then import an text file with the previous day's points.
>
> If I remember correctly, in TDS you could simply stay in the current job and create a new raw data file and go to work.
>
> Am I missing something? Is there an easier way to create a new raw data file in SurvCE?
If you mean create a new data file in the existing job,I don't know, but I'm having one heck of a time, just importing an ASCII file into SurvCE. It just seems flaky. Sometimes all the points come in, sometimes the coordinates are all wrong. I've got to figure this out or I'm going no where fast. Here's the file. I know it's good data; the coordinates match those in TPC. But when I import it into SurvCE, it gets screwed up.