We will use alpha as a check point number.
For instance, working with a set of static control, we will check into them each day from the base sitting on one point. Each RTK location will get an alpha check such as T101, T meaning Party Chief Tom was working that day. Or J101, or N101. I have some that will have 5 or more check points surrounding the control point. The last few I've done with DOT control show check points all within .03'h, .05'v (we don't care about v for DOT work) of the static control. The check points stay in TBC and each point number location gets reduced to one point in the drawings.
an alpha check such as T101, T meaning Party Chief Tom was working that day. Or J101, or N101.
OUAT the outfit I was with kept data separated by source crew, so they could identify who had made errors. IMO, that smacked of scapegoating. It lead to guys finding new and novel ways to hide data that didn't quite meet expectations. A common dodge was to reshoot check shots until they got one that worked to the perceived bosses satisfaction - leaning the rod as necessary to get a "good" number.
I ran this adjustment and everything looks fine to me except the station coord error elipses, some of which approach 0.30'. Does this indicate a bust or blunder? I'm posting my lst for anyone to check out if you have time. thanks in advance
I ran this adjustment ....
It looks pretty good. I don't see any major blunders. But what I would do now is un-fix all those coordinates you are holding fixed. Instead of " !!! " I'd give them all a standard error of " 0.001 0.001 0.001 ", run the adjustment, and see if any have large (outlier) residuals. These will be the points that need to have somewhat larger standard error values applied. It's perfectly normal to, in the end, have standard errors on GPS'd control points in the 0.02 0.02 0.04 range, with some being double or triple that.
It is not realistic to assume that all your (presumably) GPS'd control is perfect. Those points have errors (ie/imperfections) just like all your other data does, and making the adjustment treat them as perfect forces the error into the other measurements.
Just scrolled down the text file looking for any numbers that seemed out of place to me.
Why does at 5551 bs 5550 fs 5552 have an 84.66 second standard error at line 220 and line 2945? That seems a bit large.
Why does at 5551 bs 5550 fs 5552 have an 84.66 second standard error at line 220 and line 2945?
Because the foresight length is only 10 feet. With a target centering error of 0.003', plus other contributors, it makes sense.
BTW - I usually (at least) start with 0.003' for instrument centering, 0.005' for target centering, and 0.01' for vertical centering. Do that and you can probably dial back on the angular and distance a priori errors. I generally go with the instruments specification on angular and distance errors, then mess with the target centering errors if necessary to tweak to a passing Chi-square. Not too much, though.
an alpha check such as T101, T meaning Party Chief Tom was working that day. Or J101, or N101.
OUAT the outfit I was with kept data separated by source crew, so they could identify who had made errors. IMO, that smacked of scapegoating. It lead to guys finding new and novel ways to hide data that didn't quite meet expectations. A common dodge was to reshoot check shots until they got one that worked to the perceived bosses satisfaction - leaning the rod as necessary to get a "good" number.
Scapegoats? What a strange place to work.
Just so you know the party chiefs came up with that way to collect check shots.
I went along with it cause it seemed fine with me.
What would they be scapegoated for? Data?
Glad I never worked in that company. Sounds math obsessed to the point of non-functional.
What would they be scapegoated for? Data? Glad I never worked in that company.
It wasn't all that bad a place. I've done time in far worse. Nevertheless, as I described, guys would take a number of check shots and do what they had to to get a good number. If you think your guys aren't doing the same you may well be kidding yourself. I only learned it because both my sons spent time on the crews, and told me this - and many other tales - years after both they and I had left that company. They didn't want to be identified as "narcs".
What then is the point of tagging the check shots with the name of the source if not to scapegoat? Even if it is not intended, it has the effect. Just because it has been going on a long time doesn't make it a good idea.
What would they be scapegoated for? Data? Glad I never worked in that company.
It wasn't all that bad a place. I've done time in far worse. Nevertheless, as I described, guys would take a number of check shots and do what they had to to get a good number. If you think your guys aren't doing the same you may well be kidding yourself. I only learned it because both my sons spent time on the crews, and told me this - and many other tales - years after both they and I had left that company. They didn't want to be identified as "narcs".
What then is the point of tagging the check shots with the name of the source if not to scapegoat? Even if it is not intended, it has the effect. Just because it has been going on a long time doesn't make it a good idea.
This sounds highly weird to me. The alpha inclusion is to remove a check shot from the drawing. It keeps the drawing a bit less cluttered. The check is still in TBC as a record but Autocad won't accept it with an Alpha. Like I said the crews started using their first initial instead of something else and they still do it that way. If I wanted to search out who was working the day I wouldn't have to look at the initial. The idea of scapegoating anyone cause a check isn't what? Close enough?
Dang strange place to work.
We will use alpha as a check point number.
For instance, working with a set of static control, we will check into them each day from the base sitting on one point. Each RTK location will get an alpha check such as T101, T meaning Party Chief Tom was working that day. Or J101, or N101. I have some that will have 5 or more check points surrounding the control point. The last few I've done with DOT control show check points all within .03'h, .05'v (we don't care about v for DOT work) of the static control. The check points stay in TBC and each point number location gets reduced to one point in the drawings.
If using TBC why not just use same point # and store as a check vs overwrite or store another. If you use more than RTK say robot as well the conventional side has that option. I haven’t used this in a while but slowly moving our process to this because their use to be a stylesheet that can be ran in TBC or Trimble access back as part of qa/qc in office you can run a check shot report and it makes things nice and was to quickly check. I used it when I had several crews data I was checking daily.
We will use alpha as a check point number.
For instance, working with a set of static control, we will check into them each day from the base sitting on one point. Each RTK location will get an alpha check such as T101, T meaning Party Chief Tom was working that day. Or J101, or N101. I have some that will have 5 or more check points surrounding the control point. The last few I've done with DOT control show check points all within .03'h, .05'v (we don't care about v for DOT work) of the static control. The check points stay in TBC and each point number location gets reduced to one point in the drawings.
If using TBC why not just use same point # and store as a check vs overwrite or store another. If you use more than RTK say robot as well the conventional side has that option. I haven’t used this in a while but slowly moving our process to this because their use to be a stylesheet that can be ran in TBC or Trimble access back as part of qa/qc in office you can run a check shot report and it makes things nice and was to quickly check. I used it when I had several crews data I was checking daily.
We don't use the same pt name so there aren't multiple points in the database with the same name. That can cause confusion. We will use the same pt name when we want to adjust a point. Such as a control point or a boundary monument. Then they get the same pt name. Once the adjustments on points are completed we keep them fixed. As far as a report, it generates one anyway, using the pt name or using another name, if an alpha is added then you have both.
The alpha inclusion is to remove a check shot from the drawing
You could be using an alpha that isn't personalized. Or a half dozen other approaches. In my case, the check shots are given descriptors that identify them as check shots. That descriptor causes those points to be uniquely layerized. After checking in CAD, the contents of that layer can deleted - I usually just freeze it.
I find the idea that field data should be anonymized absurd. You should be able to identify the field data by date and who collected it. Anonymizing it so no one can be held accountable is negligent. Yes you should expect your field data to be scrutinized and you should be accountable for it. To do otherwise is a field crew who is not under the direct supervision of a PLS.
The alpha inclusion is to remove a check shot from the drawing
You could be using an alpha that isn't personalized. Or a half dozen other approaches. In my case, the check shots are given descriptors that identify them as check shots. That descriptor causes those points to be uniquely layerized. After checking in CAD, the contents of that layer can deleted - I usually just freeze it.
We do it similar, there are multiple layers in autocad for points. Final, calculated, topo, fence, control, plus others depending on the job. We've kept check shots in TBC, but they are always there. The check shots are mostly sanity checks, it confirms that we entered in the correct base number, the base is plumbed over the point, the rod bubble is working well, ect. Keeping it in TBC spares us making another layer and having a cluster surrounding the coordinate we want used. There isn't a reason to have them in the drawing. As far as the alpha the crews got tired of all the CK100 type of names. So, they started using their own names and they used first initials. It makes it easier for them to track and since they fill out the book they know how many checks they've done at a location. Fine by me, it wasn't asked for. We encourage finding bad closures and work out what happened. What kinda place hides that?
You should be able to identify the field data by date and who collected it.
Date? Yes, certainly. Although that is usually imbedded within the dataset. If not it will be an attribute of the file itself. As Moe pointed out earlier, there are plenty of ways to figure the who if it becomes desirable to do so.
This discussion makes be go back and think about problems with field personal. The last surveyor I had to let go was because he got a DUI and I got a call from my insurer that he isn't allowed to drive the field truck anymore. Nice guy, but what I didn't know was that wasn't his first DUI, or his second. There was a problem. It's a part of the hand book that field personal have to be able to drive the trucks and four-wheelers.
Mostly it's work volume related for us to let a crew person go, otherwise we've been very good or lucky with who we hire.
I find the idea that field data should be anonymized absurd. You should be able to identify the field data by date and who collected it. Anonymizing it so no one can be held accountable is negligent. Yes you should expect your field data to be scrutinized and you should be accountable for it. To do otherwise is a field crew who is not under the direct supervision of a PLS.
This is why I like TBC so much vs cad platforms in the day of electronic data vs old field books. I do still like a field book. In TBC if the job file in field is set up correctly and the naming convention of the daily job file is done per guidelines. I know who the party chief was on any given POINT/OBSERVATIOn who was running the instrument what date a particular observation was taken the time of day what method was used conventional down to the settings like Topo measure rounds offset and type all with one click to select and one click to view properties. I could have many different job files and I know exactly which file that came from along with a bunch of other information like rod heights instrument height or base rover etc. I take it a step further and use selection sets as well so I can group things like job files in many different ways to be able to tag them inside TBC which allows me to see that information. All raw data and computed. There are still some things I would like them to add but it really does a great job of managing data. It still lacks a little on pure cad drafting work but it’s not far just different than cad points based system. Yes you can have point names that allow one to back trace or identify who what when and where along with groups. But that’s right there in TBC. Any edits they made even simple edits like a field code change I can see very quickly. If I want more information I can run many different reports and even make my own custom ones that allow me to qa/qc data based on LS preferences and protocols along with crews abilities.
Anonymizing it so no one can be held accountable is negligent.
If you need a file name to tell you who collected data on your project ..... that, it seems to me, is a problem.
So tell me Norman, how should the files of data collection be accounted for when you have three people working on the same project on the same day. You think file names that are different is a problem? You must be joking surely.
Presumably each group would be assigned point number ranges to work with. So you would know who's who right off from that. Presumably each crew has an assigned area to work in, so you would know right off from that. The software I use includes the serial number of the instrument being used in the raw data, so you would know right off from that. Beyond that, everybody has their little ways -one can tell. If you start to think that someone's work needs some extra scrutiny you can find a way of your own.
A very good thing to do is to have what we called "Party Chief Reports" - a daily form the party chief fills out that gave job number, crew members, hours, and a brief line or two about what was done. Including point number ranges of collected data. We found these coming in handy at billing time more than once. And they can be used to figure out who is responsible for a particular point if that becomes desireable.
These days I mostly collect, process, and map my own data. So I have no one to blame but myself. For a long time it was otherwise. I've worked with multiple crews on big jobs plenty. I'm dogmatic about mapping the data - at least to a degree- that comes in same day, and reviewing the results with the crew before they go back out the next morning. This sometimes required that I work some odd hours. But with F2f I can run data through StarNet, import to CAD, and process a field file of topo in 10 minutes. So most times, no big deal. And if there are shortcomings they can be dealt with in near real time before they become real big deals. My crews seemed to respond well to that.