Hi,?ÿ
So I did precalcs for a city block that has been surveyed many times. Upon site arrival, the city has wiped out the center line block corners.?ÿ I had maps that use exterior points to re establish the block corners.?ÿ I took readings on those exterior points, then did a line station distance stakeout to reset the block corners. Then after those were reset, I performed a localization transformation on the reset points.?ÿ Decent residuals.?ÿ ?ÿUpon checking some other found monuments. I knew something as wrong.?ÿ I adjusted to the found monuments and completed the job.?ÿ ?ÿIn the office, it wss discovered that the reset points were NOT at the prescribed distances although perfectly on line between the exterior positions used for reestablishment. Im wondering if the in transformed data was using some scale factor from CRTN. ??ÿ
Any thoughts or advice ??ÿ
Thank you?ÿ
Unless you're within a few miles of a base the CRTN may produce too much error for control work. On top of that you further warped the scale factor and transformation by performing a localization. This is best done with a static network and or total station. An example where quicker is not always better. I would use my 6 static recievers around the perimeter for control network.?ÿ Then run the TS where multiparth s an issue. Reduce grid to ground if needed. Check record vs. measured to tie in to old datum. Once confident with your control, then stake points.
?ÿ
That's the thing,?ÿ I DIDN'T do a local transformation prior to resetting the control points. I'm thinking I should've done a "mock localization" on the exterior points , set the control. Then an inverse to make sure thy really checked.?ÿ THEN do a "good" localization eliminating the other one.?ÿ THEN re-inverse.?ÿ This job had nothing to do with speed. But I had a small window where the site was available.?ÿ?ÿ
Fortunately, I smelled something was off and used close site monuments to set everything. I just need to replace the bad control points so others don't use them OR find themselves lost.?ÿ Apparently, RAW CRTN data isn't as reliable as I thought.?ÿ From now on, I will add extra calculations and be prepared for the unexpected.?ÿ
?ÿ
goodgps?ÿ?ÿ you look too young to have 108 posts.
I suggest contacting Dr. Bock at CRTN to help understand the root of your issue. If he can't address it, there are others (users of CRTN) who he can refer you to. I am not going to guess, as it isn't totally clear to me what you did.
ybock@ucsd.edu
Sounds like localizations on top of localizations, seems like that could cause problems.?ÿ
Apparently, RAW CRTN data isn't as reliable as I thought.
It's unlikely that the RTN data are the problem. Possible, but unlikely.
It sounds like you held the positions of two recovered monuments, set some monuments from those, then calibrated/localized to your set monuments.
By the time you got to staking, you were stacking the absolute positional error of those recovered mons (vs record) and the standard errors of the RTK vectors for your observations of same, on top of the RTK errors of your set mons against their positional error versus your calcs.
The localization is always going to warp things to fit, and my guess is that somewhere along the line something got out of whack enough to really warp your solution.
I rarely localize to calculated positions; if I do it's a single point localization for the sole purpose of improving my search for monuments. I won't stake based upon a field localization unless I (a) have terrestrial grid coordinates that are real world rather than calculated, and (b) I was the one who observed them conventionally.
Simply use a projection, if it doesn't match each day then the RTN isn't capable of doing the survey to the precision needed.?ÿ
@lurker LOL?ÿ Thanks?ÿ?ÿ
That is my grandson when he was very small.?ÿ?ÿ
@mightymoe?ÿ ?ÿI only did ONE localization.?ÿ That was after I set control simply using points observed while using CRTN.?ÿ I am guessing that CRTN uses spheroid distances and by my NOT localizing to a nominal ground height, I inadvertently set points to the spheroid distance.?ÿ
That being said, for the last two jobs I've done, there seems to be gross errors with CRTN solutions. I've reached out to them with no response.?ÿ
I'll go back to using a base station for a while.?ÿ ?ÿ
@rover83?ÿ I think there are hazards that may arise while using CRTN.?ÿ In this particular case, I had measured those "external" control points using total stations before GPS was around.?ÿ In the future, I'll add calculations for ALL external control and expect the unexpected.?ÿ
My method for stakeout parallels yours insofar that I'll localize to find control points, then occupy and work off of the true monument.?ÿ For this job, and its mess, a quick on-site decision was made to reconstruct and set the monuments to the positions?ÿ called for on the map.?ÿ ie:?ÿ 100 feet north of a pin on line with another pin etc etc.?ÿ distances were cross checked and all is satisfactory. I shudder to think that a crew may have simply set monuments regardless of positioning errors that were evident.?ÿ I'm sure it happens often.?ÿ It pays to be older except for the aches and pains.?ÿ
Thanks (^_^)?ÿ
?ÿ
This sounds more simplistic than it is but I was taught to isolate the error inside the subject block. In other words, survey it inside out rather than outside in.?ÿ When I see a reference to an RTN network tied to determination of a block location all kinds of red flags go up. The process used here may be ok but I'd have to look at the interior evidence first and foremost.?ÿ
