Working on a road reconstruction and set control on the local mandated system, a state coordinate system, NAD83, using 1.000235 as the scale factor scaled around 0,0 with Geoid03 applied to NAVD88 elevation bench marks.
This is a plot of some occupations and checks to one of the control points:
The static was run with R8's and R10's, the RTK with R10's, and conventional with S6.
The blue lines are RTK checks the green lines are conventional vectors, the far check in point is 0.017' hor. and .005'vert. The largest vertical miss was 0.012' which was the conventional green line.
I've noticed RTK is doing much better since we started using the R-10's. The S6 has always been very accurate!!
One important thing to do is make sure all the projection data is fixed before heading to the field, it all needs to be seemless. I'm sending a DC file containing the control to the engineers we are working with and they can import it, set on the control and go.
> One important thing to do is make sure all the projection data is fixed before heading to the field, it all needs to be seemless.
Yes, one of the major flaws in RTK work I see is what has to be the projection-du-jour approach, where one ad hoc projection is generated at some randomly selected control point where the base receiver is set up and some stuff is located. Then, days or weeks later, the folks return to the scene of the action, try to recreate their projection by some means other than just entering the parameters, and then stake out a bunch of stuff in what turns out to be a measurably different coordinate system.
> Yes, one of the major flaws in RTK work I see is what has to be the projection-du-jour approach...
I would amend that to read localization-du-jour. Salesman, who don't understand projections, love to sell that localization function as the one function that fixes all .
> > One important thing to do is make sure all the projection data is fixed before heading to the field, it all needs to be seemless.
>
> Yes, one of the major flaws in RTK work I see is what has to be the projection-du-jour approach, where one ad hoc projection is generated at some randomly selected control point where the base receiver is set up and some stuff is located. Then, days or weeks later, the folks return to the scene of the action, try to recreate their projection by some means other than just entering the parameters, and then stake out a bunch of stuff in what turns out to be a measurably different coordinate system.
What they (the dealers) tell you is that you end up with true bearings, but you need to localize it on a point. What they (the dealers) don't tell you is that when you do that, you effectively build a mapping projection that, the further you go, the worse the bearings are from true, except it takes new physics and linear algebra to compute the scale and theta/gamma angles.
That said, going back CAN be recreated with exceptional accuracy. The downside is that most people localize to 5k,5k or some variant thereof. When returning with new coordinates, in a new DC file, ANOTHER "here" position must be made and ANOTHER localization to the original BASE point, not some other random point. Once that is done, you will hit everything. If you don't, it won't even crank up because you don't have a Lat and Long associated to 5k,5k. For this reason, we QUIT doing this within the first two years. Not because it doesn't work, but because it's a HELLUVA lot more steps for a field crew to remember and verify in the field.
I have two legacy projects that were initiated like this and TONS of work over the last 12 years done in them. I have purposely NOT deleted those original vectors so that I can simply load new coordinates into the existing project file and then reload that into the DC whereby the localization is maintained. It's a headache every time though.
The grid is so much easier, especially at less that 800 feet MSL.
Mike
We find the R10 to be exception when checking into points as well. Very powerful when used properly.
Mike
We are seeing the same thing, basically nothing in the checks, really a c change, kinda like when Geoid03 came out, around here it was the first really workable useful model.
This project is constrained by photos and lidar already completed in 2007 and needs to use that system.
A permanent base that is an NGS CORS, or constrained to NGS CORS per NGS recommendations provides the published pedigree for proper geodetic reference, subsequent projections, and temporal resolution (we gots lotsa velocity up in these parts).
Of course the issue there is following the bouncing, rolling CORS/OPUS ball. Particularly with respect to vertical changes.
It's why the local DOT used the passive network and NAVD88 marks. At first I balked, but as the years go by, I'm sure glad they did, this project is a case in point, we are seamlessly melding into the mapping from 2007 and more important into control and property corners already on the system.
Yes there is now a CORS point broadcasting nereby, but vertically it is just awful, I hate using my backed in number to use it and try to make others understand how to do that. horizontally it's not too far off the passive network, but enough to not be useful for this.
Localizations or initializations can be misused like many other tools.
> The grid is so much easier, especially at less that 800 feet MSL.
The Texas Coordinate System works great at 2300 ft. and 5300 ft. as well. If we ever have to repo New Mexico East of the Rio Grande, I'm sure it will work great at 8300 ft.
What do you mean by "recreate their projection by some means other than just entering the parameters, and then stake out a bunch of stuff in what turns out to be a measurably different coordinate system."?
I'm not sure what Kent is saying, but I figure he means the curious procedure of calibrations and what's sometimes called localizations. I don't know why someone would do that on a new or "clean" job, but it sure happens.
You have such a powerful piece of equipment like GPS, so why not get on state coordinates or in my case the county system, or a defined LDP with metadata; imput the parameters into the office and field computers and when you set up your base you just go.
Why use 5000, 5000, 1000 on each job, the data collector is projecting somehow, but the user usually can't reproduce that projection. So the next guy or next job nearby is a complete start-over.
> I'm not sure what Kent is saying, but I figure he means the curious procedure of calibrations and what's sometimes called localizations. I don't know why someone would do that on a new or "clean" job, but it sure happens.
Sure. I assume that the end result of a "localization" or "calibration" really is the creation of a projection that the controller then applies, even if not exactly in plain view of the user.
I think that's what a localization does, a calibration is a twist and fit to existing control in the Trimble world, of course it has to have some projection going on then it needs to fit to what's out there.
I don't do them except in extreme situations where old control exists and I can't move it to a more modern system. It's very rare these days, usually a mine where the state mandates the mine stays on its old system.
But doing a localization or calibration on a new job is not something that should happen, IMO.;-)
I would assume the localization is doing an LDP somehow, probably a Transverse Mercator projection trying to scale up to the elevation the receiver is on.
I do know there was one of these programs that offered something (I forget what it was called) and everyone assumed it was putting them on ground and a geodetic az at the setup point, but it was actually down at sea level, basically a state planeish thing going on, but almost impossible to recreate.
> I do know there was one of these programs that offered something (I forget what it was called) and everyone assumed it was putting them on ground and a geodetic az at the setup point, but it was actually down at sea level, basically a state planeish thing going on, but almost impossible to recreate.
Yes, that was exactly the RTK magic I was dealing with last week. The bearings on the survey were North-ish and appeared to refer to geodetic North at some unstated point in the vicinity that probably was where a base receiver had been set up. The distances turned out to be grid-ish rather than surface-ish (a difference of about 1:8500) and I concluded that given the overall condition of the effort that it probably was something that the RTK controller had created without really asking.
> The Texas Coordinate System works great at 2300 ft. and 5300 ft. as well. If we ever have to repo New Mexico East of the Rio Grande, I'm sure it will work great at 8300 ft.
I typically work in the New Mexico Coordinate System between 5000 & 8000 ft. without any problem, but you could see some significant distortion trying to force your survey into the Texas Coordinate System. 😉
Classic, but of course the same thing happens with static
> > The Texas Coordinate System works great at 2300 ft. and 5300 ft. as well. If we ever have to repo New Mexico East of the Rio Grande, I'm sure it will work great at 8300 ft.
>
> I typically work in the New Mexico Coordinate System between 5000 & 8000 ft. without any problem, but you could see some significant distortion trying to force your survey into the Texas Coordinate System.
Actually, the folks who designed the Texas Coordinate System must have envisioned that New Mexico would finally decide that so many Texans were retiring there that there wasn't any reason for NM to keep up the pretense of being other than a colony of Texas. This is, I'm sure, why various zones of the Texas Coordinate System extend perfectly into the part of New Mexico that used to be Texas and will be again once there are enough Mercedes dealerships in place.
> Classic, but of course the same thing happens with static
The fact though is that it always seems to be RTK. I think the level of clue is the determining factor. It seems to have been that the standard was to run RTK per salesman's instructions. Adjusting post-processed GPS vectors, whether static or PPK, takes a different level of user.
Nah, I've seen it both ways, but more often with the X button in the DC, or whatever it is, still can't believe surveyors do that.:-(
> Nah, I've seen it both ways, but more often with the X button in the DC, or whatever it is, still can't believe surveyors do that.
I'm reaching back into memory and can honestly say that the only times I've seen post-processed GPS as screwed up as the recent RTK jumble was in the very early days of GPS when surveyors might try to warp a control network to match some low-grade monumented network. Either that or making a survey in the form of discontinuous pieces, each tied to some NGS control point and considering the NGS positions for those points as error free. That last bit is sort of RTK-like.
