State Plane (conus) vs 2011

> .... The unit was originally setup using the Oregon State Plane (conus) coordinate system and geoid12a. I subsequently discovered that I had used the wrong projection (should have been Oregon State Plane (2011), geoid12a). Is it just a matter of making the change to the correct projection in TBC? I tried this out and of course everything was shifted by about ~1 m, which was not too surprising. However, more surprising was the fact that the vertical elevations shifted by ~0.4 m despite not changing the geoid.

I believe that "Oregon State Plane (conus)" and "Oregon State Plane (2011)" refers to profiles that have been set up in your data collector rather than a coordinate system. These profile names are user entered and don't necessarily have any deeper meaning. While these particular names suggest to me certain things, they won't be the same on anybody else's data collector. Profiles contain a number of settings, not just datum projections.

Check your profile settings for foot definition. In Oregon, you should be using the International Foot (not the US Survey foot). The magnitude of the differences you report suggest that this is where the problem lies.

Yes, you can probably fix your data in a similar manner in TBC. Good luck.

Good practice is to check into something you know has good coordinates on it at the beginning and end of a set of data collection.

sounds like a confusing, technically incorrect combination of a projection and a transformation. A transformation compensates for various "realizations" of monuments in a datum. A projection is simply a means of visualizing coordinates - like looking at a distance measured in feet or meters. The distance is the same regardless. In a projection, the place on the Earth is unchanged.

Transformations change positions on the Earth due to inaccuracies in the determinations of those positions and due to crustal motion of those positions.

I agree with N.OK.

Verify that the projection you have chosen is in proper units and has the correct mathematical definition.

I would locate a nearby NGS control point if possible to verify your results.

Always check in before and after work. Having several points to choose from around your site would be beneficial.

Trimble always treated WGS84 and NAD83 as one and the same in their software, so the US State Plane 1983 coordinate system that is embedded in Survey Controller and Access does not contain any transformation from the Global LLH values to the Local LLH values, which are what the state plane coordinates are calculated from. This just makes it easier for the user - you can plug in the LLH values from your OPUS report and the State Plane coordinates will agree.

BTW - it is not my intent to start a big debate over what is geodetically proper or mathematically correct, I'm just stating how things were always done in Trimble Software. The WGS84 and GRS80 ellipsoids are close enough to the same thing that you can treat them as such - I once heard David Doyle say he transformed a baseline from Alaska to Florida and the difference was on the order of a millimeter or so.

However, with the advent of satellite based correction services that are in global coordinate systems, it became necessary for Trimble to embed a coordinate system that does apply a transformation from WGS84 to NAD83. This is what the US State Plane (2011) system does, and it is appropriate to use it when working with WAAS, Omnistar, CenterPoint, etc.

As to which one is correct for your VRS, it depends on what coordinate system their corrections are broadcast in; if they are in NAD83 (like the Louisiana Gulfnet), then you want the old US State Plane 1983. If they're in WGS84 or ITRF or some other Global system, then US State Plane 1983 (2011) will be a better fit. However, you should DEFINITELY check into monumentation that is in the coordinate system that you wish to work in, and apply a Site Calibration if necessary. It is OK to do a single point site calibration when your coordinate system is either of the NAD 83 systems and you just need to apply small shifts.

Lee is spot on with this. Went through the same issue with our VRS setups once switched over to 2011.

As stated, check with your corrections provider to make sure your coordinate system setup matches their output.

This kind of opens up a different terminology. Ellipsoids are different from realizations. An ellipsoid is still a precise mathematical model (like a projection). A realization has error and deformation. So in the sense that Dave Doyle can calculate the same distance across a continent shouldn't surprise much. Even between continents there should be substantial agreement because the parameters are so similar between GRS80 and WGS84 ellipsoids.

But the difference between datums/realizations will be more significant. NAD83xx and ITRF08 for instance include distortions from motion (which includes time) and the accuracy of the points positioned in that particular realization. NAD83(86) will vary from NAD83(93) for instance because of positioning errors. NAD83(2011) will vary from ITRF08 mostly due to crustal motion and an initial transformation offset.

It's cool that Trimble allows for use of an ITRF based correction that can be correlated to an NAD83 position. Very cool. And the advice to check into a physical monument is sound (and reiterates the need for stable ground monuments - at least as a means to test repeatability). The only negative issue I have is that it appears that Trimble is combining three distinct concepts (projections, ellipsoids and realizations) into one vague setting (State Plane CONUS/2011).

As professionals relying on precise positioning, we should be more aware of what these things are and how they related. Even if we aren't geodesists.

I'm curious why Trimble (or anyone else) would have an Oregon State Plane (CONUS) and an Oregon State Plane (2011)[or any other state]. The mathematical relationship between and NAD 83 latitude and longitude and the State Plane Coordinate has not changed since the datum was introduced in July 1986. What has changed as has already been reported here, are the several different realizations of NAD 83 which is fundamentally defined as latitude and longitude. The values Jon posted look vaguely like the difference between NAD 83 (2011) and ITRF08, which in Oregon is approximately 1.3 m in horizontal and 0.4 m in ellipsoid height. If Jon provided a more specific location for his area of interest it would be a rather simple effort to compute the offset from NAD 83 (2011) to IGS08/ITRF08.

Thank you all for your comments. I appreciate the various insights. I thought about the problem a little further and went back and reviewed the data we had collected.

Simply changing the projection/transformation in TBC was not the answer, as it effectively converted what were essentially already local coordinates (derived using our ORGN dial-up GPS network correctors) to global, which generated new local coordinates that were in fact incorrect resulting in the offsets I noted in my original email. I was able to verify the latter against a couple of monuments where we had operated a base gps and hence were able to obtain OPUS solutions on those points. I think I understand the process better and it was certainly a lesson learned in making sure one is using the correct projection/transformation from the outset.

Cheers
Jon

For your reference

I did not see this post when it first came out, but I had an experience yesterday that merits comment.

I was using the WVDOT VRS to survey 30 Lidar checkpoints on a military base in the mountains in eastern WV. I also had a static unit setup on a HARN along the runway at the facility, which is in a deep valley along the Cheat River. That was in case I could not get a data connection (which actually occurred at two sites). At the start of the day I occupied the HARN before I set the static unit there to collect data. I did static at two of the points in addition to VRS.

At the end of the day I occupied an NSRS benchmark along an abandoned railroad. The mark looked quite stable, but I missed the elevation by several feet. It was "treed-in", but the results looked good and I had plenty of satellites. Here is an aerial of the BM site:

On the drive home I pondered this, and wondered if it could possibly be a datum issue. I noticed when I got home and looked at the full info for the source I was using (vCMRplus) that it said "DEU". I wasn't sure what that meant but I thought maybe Germany? (Deutschland), whereas others said WVRTN or USA. By the way, you get get a listing of the source table for a VRS if you enter the address in a browser, followed by a colon and then the port number, for example www.cors.us:2101.

So, I thought maybe it was broadcasting WGS84 or ED87 corrections. But, when I processed the RTK lines and compared them against the static obs, they agreed very well.

So, I converted the .job file to a .jxl file (using ASCII file generator utility), and saw near the top of the file that a transformation was being applied:

SevenParameter
WGS84ToLocal
6378137
0.00335281067183
0.00000719851944
0.00000261845833
0.00000322204167
0.99343
-1.90331
-0.52655
1.000000001715

I then looked at the project configuration in the data collector. I was using UTM zone 17, but somehow the datum was changed from NAD 1983(CONUS)(MOL) that I normally use to NAD 1983(2011)(7P). The difference is that the first one is basically a 3 parameter transformation with 0 for the transformation parameters, and the 2011 one is a 7 parameter that uses the published IGS08 to NAD83 (2011) parameters from the CORS page.

The good thing is that this transformation is only applied to the displayed values, the stored values are what was broadcast by the VRS, namely NAD83 (2011). So, the stored "VRS BASES" that were created for each RTK observation were correct.

So, the point is to BEWARE! Something that sounds like it would be correct (NAD83 (2011) is NOT. I noticed there is a similar datum NAD 1983(CORS96)(7P).

I believe Trimble should call these by some other name that reflects what it is doing, something like "IGS08 to NAD83(2011)" for example. But I do feel it is good that they created these, so that one can use a WHS84 (IGS08) data stream.

Wow! Really surprised you got usable data with that kind of canopy. I imagine the leaves are off this time of year but still a boat load of branches. You do good work and always have checks on your data so I'm sure you are confident of your results.

I was surprised as well, but Glonass makes all the difference. I didn't really need that BM, but it was the end of the day, not quite dark yet, and I was driving back to the base. This was the third time I have done control work at this base, so I have it tied down pretty well.

The BM checked 0.025 m (using the VRS). Pretty good, especially considering this is in the mountains. WV is probably the most difficult state to do GPS in.

After using GPS/Glonass for years (not that I do much RTK, but occasionally), you get spoiled. Five of the check points were in the woods, so I would set pairs (static) in a clearing and shoot in with the total station. My other R8 is in the shop (got the estimate-$4600, ouch), so I was using a 5700. On one of them I started the 5700 with VRS just to see-it took MUCH longer to initialize (45 secs versus under 5 secs).