I Don't Understand
> > You have coordinates for items to be staked out, but have no coordinates for any existing physical point on site?
> >
> > Just where the heck are your stakeout coordinates coming from?
> >
> > Paul in PA
>
> A client might need random drill test holes on a parcel of land. Whether the starting point of the drill is here or there does not really matter, what matter is spacing between drill holes and exact final NEH.
>
> (Just an example.)
Pretty much this is what we are doing with the exception that the locations are planned out in advance using CAD and aerial imagery and are often right along fence lines, existing clearings, etc. If my stakeout error is too large the point could end up on the other side if the fence.
I Don't Understand
Drilldo,
With our equipment (Trimble) we can do a site calibration in the field.
1)Set up with a here shot.
2)Key in published coordinates of several benchmarks (make sure the are not scaled coordinates.)
3)Tie-in benchmarks with rover.
4)Do site calibration with software on controller.
I usually calibrate to the first benchmark I tie and then check into a few others to make sure everything is fitting.
Cy
SBAS - ITRF vs NAD83
Some receivers use the WAAS signal with impressive results. My Altus receivers, for instance have incredible precision (about 1 foot) with WAAS, however there is a substantial offset that must be accounted for.
From what you are describing, a satellite based correction is your best option (as others have mentioned). The decimeter level services available are very good. I've actually seen a few minutes of averaging (after the convergence period) achieve 5cm of standalone accuracy! But the user must be aware, most satellite based services (including WAAS) are correcting to ITRF. In Texas, that translates to about 2' in Northing, 2' in Easting and 4' in elevation. The decimeter level corrections are spendy of course, so you have to consider what it's worth to you. But I could envision a scenario in which you start your rover, set to receive SBAS corrections. Wait the requisite 20+ minutes for the solution to "converge" (before convergence, your accuracy will be +/- several feet). Collect a position for your base point (average maybe 5-10 minutes, beyond that there is no meaningful improvement to the position based on my own testing). Set the base on the collected point, log raw data for submission to OPUS. Survey by conventional base/rover for relative precision at centimeter level and absolute precision of decimeter. Return to office and translate the day's work to the OPUS position (which shouldn't vary more than that decimeter if you've done it right).
All GNSS surveyor's should really understand the ITRF/NAD83 relationship. We aren't geodesists, but we are using geodesy. You have all the tools necessary to test this for yourself. Your "Here" positions are likely WAAS corrected now (if your base is enabled for WAAS). How much translation do you usually observe? Is it consistently biased in one direction? If yes, then you are probably seeing the ITRF/NAD83 shift. You can see what the shift is in Northing, Easting, UP by looking at your OPUS report. It gives NAD83 and ITRF geographic (LLH) coordinates. Convert both to SPC and observe the difference between them.
I Don't Understand
We do it the same as what Cyril stated when there are control points within RTK range. When there are not control benchmarks in range, may I suggest using the same Aerial imagery as you used to compute your drill sites, and pick out some fence corners or other points easily identifiable points in the imagery to localize on. Again as Cyril says, calibrate to one, then do a check to another one or two. I would not calibrate to more than one, as this could adversely affect the scale factor, as well as rotation, computed for your stake out. Instead it may be that you need to rotate your calculated point to what you find in the field. Don’t forget to run static so that you can then process through OPUS to get the true locations.
Pat
Well, you can take a laptop and do it yourself, set up on your point, collect some data, have TBC loaded on your laptop with the projection and job already set up. Add the nearest CORS point (do all this before leaving the office). Collect some data, 5-10 minutes should be good, then download the CORS data (I think you will need to time it so you have the 5-10 minutes work with the last hour) and process your point. It will probably not "fix" but over the years I've found that this type of point is almost always within .15' or so. It may even be that you don't need to change it when you get back your OPUS data, often you will be less than .05'.
I use CORS as checks on my locations when I lose radio contact and have to go to PPK to locate a point, its amazing how close the CORS location will be to my base rover solution. For the Section 17 post below, I did two static sessions on the NW corner processed it to my base and then checked it to the nearest CORS, even though the sessions for the base rover were just 3 minutes and 2 minutes of data the CORS solution from many miles away "checked" my base solution within less than a .1', plenty good for me.;-)
Apparently you have Trimble equipment, do the following:
- Set up a WAAS survey style
- Create a job with the coordinate system US State Plane 1983 (2011)
- Run the WAAS survey, let the DGPS position stabilize, and take an Observed Control Point
- Create another job with the regular US State Plane 1983 coordinate system
- ASCII the WAAS point out of Job A and into Job B
- Start your base using that coordinate
This may sound convoluted but the NAD83 (2011) coordinate system transforms the WAAS position from ITRF to NAD83, which improves it by a meter or so Hz.
> Apparently you have Trimble equipment, do the following:
>
> - Set up a WAAS survey style
> - Create a job with the coordinate system US State Plane 1983 (2011)
> - Run the WAAS survey, let the DGPS position stabilize, and take an Observed Control Point
> - Create another job with the regular US State Plane 1983 coordinate system
> - ASCII the WAAS point out of Job A and into Job B
> - Start your base using that coordinate
>
> This may sound convoluted but the NAD83 (2011) coordinate system transforms the WAAS position from ITRF to NAD83, which improves it by a meter or so Hz.
Thanks.
I will try this.
When you say ASCII from job A to job B are you saying write it down from the 2011 job (job A) and then type it in to the NAD83 job (job b) as opposed to copying the point on the TSC?
If you are somewhere that gets cell phone data you could collect data for 15 minutes then send it into OPUS rapid static on site. You would need a laptop that can tether to your cell phone or a mobile hotspot.
I just export the point as a fixed format - CSV - and then import it back in.
> If you are somewhere that gets cell phone data you could collect data for 15 minutes then send it into OPUS rapid static on site. You would need a laptop that can tether to your cell phone or a mobile hotspot.
Unless I am doing something wrong that doesn't work in my area. I am not sure the exact amount of time but every time I have tried a fast static I get errors unless several hours have passed since I collected the data. I don't think all cors data that opus uses is instantly available.
Cors data can be downloaded each hour, just process your own point in TBC 10 minutes will get you close, longer the better