PPK vs RTK
I??m new to static surveying and we needed to receive static measurements on a point we set. We post processed the data using FDOT??s computation service and the difference between the ppk coordinates and the RTK coordinates were about 5 feet in the E direction and a few tenths for elevation and N direction. The computation service used 4 local base stations near the point that was measured. The point was statically measured for about 1.5 hours. We processed the rinex file a few hours later once we got back to the office. The RTK coordinates were measured in by a published control point from FDOT via base and rover. The published control point was established via rapid static per fdots data sheets. We put our base on the new point and checked back to the control point and it was only a couple of hundredths out. I??ve heard that waiting for the epheremis data for a 24 hour period helps tighten the ppk solution but by a whole 5 feet? I just feel like something??s missing, or I??m approaching something wrong. Any help would be appreciated. Thank you!
- 17 Replies
Sounds like the “FDOT computation service” is some kind of automated post processing of static data. Is this not OPUS? Have you tried OPUS? These automatic services are hood checks and help you indentify your errors in RTK settings or parameters. Sounds like your RTK may have wrong settings. Many newbies want to use NAD83(2011) when they should be using NAD83_NOTRANS.
When are rtk was used, we did use NAD83(2011) transformation. This is due to the fact our job is pretty big, about 7 miles. Wouldn??t using no transformation introduce more errors? It seems to me we would need a scale factor for this project.
This has nothing to do with grid vs ground. It is the projection from Lat/Lon to SPC. The NAD83_NO_TRANS means no transformation is needed. You can change the parameters in your DC and correct all the data. This is a very common mistake. It has been explained on this forum many times over the years, try a search or others here may explain this in more detail.
To simplify it, your service provider CORSVRSRTN has already adjusted to the realization NAD83(2011) and you are reapplying this a second time by selecting NAD83(2011) in your controller.
What are the Lat, Long, Height numbers?
XYZ coordinates aren’t important.
Those should be projected from geographic coordinates.
If your geographic coordinates are mismatched you are comparing apples to oranges.
My guess is that your basis is for one system might be ITRF and for the other NAD83 of some flavor causing the resulting coordinates to miss.
Another thing to check is international feet vs US feet, but that shouldn’t effect the elevation and it’s simple to check cause the miss in the Northing and Easting would hold the same ratio. If the miss in the northing is 5 feet and the coordinate is 1,000,000 then the miss for an easting of 500,000 would be 2.5 feet.
It’s all about the settings, basis, projections. Start with the Lat, longs, if they’re off you know how to proceed. If they match you don’t really have an issue, then it’s your projections and your set-up.
Here’s where black box things get iffy and clear communication is often hard to come by.
Per the Topcon Magnet Field NAD 83 datum details, NAD 83_NO_TRANS means that WGS 84 equals NAD 83. It codes the WGS 84 transformation parameters as all zeroes.
Choosing NAD 83(2011) makes the transformation parameters non-zero so that a 7-parameter transformation changes the coordinates.
This is consistent with coding for GIS WKT files. The NO_TRANS definition is an instruction for converting WGS 84 to the desired ellipsoid, or the reverse of that; I’m not really sure which way the conversion goes in survey equipment. In GIS software, the transformation is TOWGS84.
Here’s where the trouble appears. The two ellipsoids, WGS 84 and GRS 80, are virtually identical. Over time, though, the center point for the WGS 84 ellipsoid has been moved to more closely agree with new measurements of the location of the center of the earth while GRS 80 has remained centered at its original (0,0,0).
The writings I’ve seen hit at the proper interpretation but don’t spell it out to the extent that I need in order to understand it completely. If I were I a practicing surveyor, I would take the equipment to an NGS known point and collect its coordinates both with and without the transformation defined.
That should answer the question.
The reason for using NO_TRANS with RTK is that the base position may already be NAD83, and so the rover position is NAD83 without any additional translation. You need the translation if the rover is used by itself, say for a static session, or if the base is reporting ITRF/WGS
.
This is consistent with coding for GIS WKT files. The NO_TRANS definition is an instruction for converting WGS 84 to the desired ellipsoid, or the reverse of that; I’m not really sure which way the conversion goes in survey equipment. In GIS software, the transformation is TOWGS84.
Here’s where the trouble appears. The two ellipsoids, WGS 84 and GRS 80, are virtually identical. Over time, though, the center point for the WGS 84 ellipsoid has been moved to more closely agree with new measurements of the location of the center of the earth while GRS 80 has remained centered at its original (0,0,0).
The writings I’ve seen hit at the proper interpretation but don’t spell it out to the extent that I need in order to understand it completely. If I were I a practicing surveyor, I would take the equipment to an NGS known point and collect its coordinates both with and without the transformation defined.
There are two things in play here. First, those transformations are not operating on LLh, but on XYZ ECEF values. The ellipsoid doesn’t come into play until after the transformation is applied.
Second, because we’re talking just reference ellipsoids and not reference frames, there can’t be a shift between GRS80 and WGS84. There’s absolutely a difference between NAD83(2011) and WGS84(G1762). But the mathematical shapes used to define them are consistent at the 0.1 mm level.
I suspect that some DCs used to (and may still) treat the WGS84 and GRS80 ellipsoids as one and the same for convenience’s sake. It makes things simpler from a computational standpoint.
In any case, computations done on the WGS84 ellipsoid versus the exact same computations done on the GRS80 ellipsoid – without any specific reference frame being defined – will be identical for all intents and purposes.
Straight from the NGS (from the documentation of their INVERSE3D and FORWARD tools):
“Please note that the GRS80 and WGS84 are considered to be the same. Actually, there is a very small difference in the flattening which results in the semi-minor axis, b, being different by 0.0001 meters. There is no known application for which this difference is significant.“
“…people will come to love their oppression, to adore the technologies that undo their capacities to think.” -Neil Postman@bill93 so even if I??m running rtk for a project that spans 7 miles, I can run a 1:1 scale assuming my base is on an NAD83 point? Doesn??t the scale factor help account for the curvature of the earth, therefore measurements along this 7 mile span should be scaled, no? I guess I always thought about it the wrong way.
to avoid this issue in the future, rtk should always be ran at a 1:1 scale, unless using a vrs network or recording static measurements, correct?
There is no scaling associated with choice of datums. It’s just an offset from one to the other at the precision of ordinary work in a modest area.
If you are working in a projection like SPC or UTM then you need scaling to relate projected distances to ground distances and that’s true for any datum.
Over 7 miles the SPC or UTM projection scale factor may change significantly, as well as perhaps the elevation factor. The curvature of the earth causes a projection scale factor change. Flatten out an orange peel to appreciate that fact. Some parts stretch more than others.
.@bill93 so even if I??m running rtk for a project that spans 7 miles, I can run a 1:1 scale assuming my base is on an NAD83 point? Doesn??t the scale factor help account for the curvature of the earth, therefore measurements along this 7 mile span should be scaled, no? I guess I always thought about it the wrong way.
to avoid this issue in the future, rtk should always be ran at a 1:1 scale, unless using a vrs network or recording static measurements, correct?
There’s a lot to unpack here…
First, RTK or VRS/NRTK or static, it makes no difference. All those things are geodetic measurements. They’re all derived from different methods but the result is the same thing, an XYZ delta vector. No method is immune to scale factors.
Scale factor does account for the distortion introduced by both (a) the map projection relative to curvature of the earth and (b) the height of the project above the earth (meaning the ellipsoid). How much distortion there is depends on several things.
As far as whether you can run a “1:1 scale” (I think you mean grid rather than ground distances) over 7 miles, I would say that it might be possible, but is highly unlikely, but again it might be possible depending on the project parameters.
Is there a project surveyor in responsible charge who can explain these things and guide you through the process? It’s great that you want to learn about this stuff, but it sounds like you’ve been sort of left hanging, and it’s not exactly something that can be explained in a single internet post…
“…people will come to love their oppression, to adore the technologies that undo their capacities to think.” -Neil PostmanThe OP started this thread with PPK vs RTK, but appears to be using a VRS and OPUS with datum issues. But he keeps thinking a scale factor is the issue. Clearly they don’t have experience with Geodetic surveying and has no mentors to fall on, just their own face. This is a tread I don’t like to see. Yet I finding about a third of the Geodetic surveys that I retrace have these issues. How do we educate these surveyors. In my consulting and training experience 99% of my clients are contractors willing to accept formal training. While only 1% of surveyors have the willingness to accept formal training. This continues to put a negative image on all surveyors, which may give engineers more fuel to work with.
I??m new to static surveying and we needed to receive static measurements on a point we set. We post processed the data using FDOT??s computation service and the difference between the ppk coordinates and the RTK coordinates were about 5 feet in the E direction and a few tenths for elevation and N direction. The computation service used 4 local base stations near the point that was measured. The point was statically measured for about 1.5 hours. We processed the rinex file a few hours later once we got back to the office. The RTK coordinates were measured in by a published control point from FDOT via base and rover. The published control point was established via rapid static per fdots data sheets. We put our base on the new point and checked back to the control point and it was only a couple of hundredths out. I??ve heard that waiting for the epheremis data for a 24 hour period helps tighten the ppk solution but by a whole 5 feet? I just feel like something??s missing, or I??m approaching something wrong. Any help would be appreciated. Thank you!
“We put our base on the new point and checked back to the control point and it was only a couple of hundredths out.”
This tells me that the relationship between the two points is good. So it sounds like you have some kind of difference in the way the RTK and Static observations are processed.
“I am new to static surveying.”
Here are some things I would check to investigate the difference in my RTK and my Static Solutions. You probably have thought of most of these if not all.
a. ensure horizontal and vertical datum selected for both Static and RTK solutions are the same
b. ensure the Geoid selected for both are the same
c. ensure the receiver selected for your static solution was correct
d. check your receiver HI (probably the most common issue with vertical issues)
f. try running your static data through OPUS and see how the solution compares to the FDOT service solution and your RTK solution.
g. try running your static data through the FDOT service again today and see if you get a different solution
How do we educate these surveyors. In my consulting and training experience 99% of my clients are contractors willing to accept formal training. While only 1% of surveyors have the willingness to accept formal training. This continues to put a negative image on all surveyors, which may give engineers more fuel to work with.
I do in-house training, and even I have trouble convincing folks that training is necessary, or even a good thing in general.
The most depressing part is that many anti-training/anti-education licensees will take that disdain for formal training and that know-it-all attitude and pass it along to folks working under their stamp, despite not really teaching them anything (apart from maybe “do this because I say so”). They’re also the ones least likely to be open to new information, new technology, or experimenting with new workflows.
When I advocate for training, or when I show up for a session, sometimes I get pushback not only from a licensee who thinks it’s worthless, but from the guy with only a few years of experience working underneath that licensee. Within a few years, that next guy will get licensed and continue the cycle.
“…people will come to love their oppression, to adore the technologies that undo their capacities to think.” -Neil PostmanI think that the NGS reference means that Inverse, etc will calculate correct azimuths and distances for WGS 84 coordinates when the selected ellipsoid is GRS 80. That is, any flavor of WGS 84 coordinates can be entered into any of these programs with confidence that the results will be accurate.
That’s a different problem from the calculation of the coordinates of a particular point within the GPS software.
Consider this, though. The (0,0,0) point, the origin for the x, y, z coordinate calculation is also the center of the earth and the center of the reference ellipsoid. Perhaps this has not changed as WGS 84 has evolved so that any desired WGS 84 datum is a transformation from this original GPS origin.
That would keep GPS WGS 84 and GRS 80 in synch, but I really don’t know how it works.
so even if I??m running rtk for a project that spans 7 miles, I can run a 1:1 scale assuming my base is on an NAD83 point? Doesn??t the scale factor help account for the curvature of the earth, therefore measurements along this 7 mile span should be scaled, no? I guess I always thought about it the wrong way.
You are kind of hung up on this scale factor thing. Perhaps because it would afford the opportunity to apply a factor that makes things fit and not have to call it a fudge factor. Scale factors and convergence angles are relevant only when you convert from grid to ground or vice versa.
Probably the NO_TRANS thing is your answer here. A US Foot / Int’l Foot issue is another possibility. Or both.
I can’t figure why FDOT would be devoting resources to a “computation service” when OPUS is perfectly servicable.
I can’t figure why FDOT would be devoting resources to a “computation service” when OPUS is perfectly servicable.
I can’t speak for FDOT. The Comp service our RTN offers has lower residuals than OPUS because the reference stations are closer together than CORS reference stations. NGS in their wisdom would not accept all our ref. stations. Furthermore, the resulting computed coordinates fit the RTN observations better than the OPUS results and many times fit the horiz. and vert. positions on the NGS data sheets better than the OPUS results, in particular vertical. There are no more resources required to operate the comp service than there are not to. The comp service can be used immediately after the static survey is completed rather than waiting until the next day or longer. Other than that I can’t figure it out either.
A benefit in using a state comp service may be that they are utilizing GNSS for post processing while OPUS is only using GPS.
Log in to reply.