@norm I don’t think you have anything to worry about. Now once we move to the new datum things will get a little pickier. But you got er figured out ok. Using the correct geoid model with the correct realization coordinates is probably more easily seen than what you are doing and i have had to do the same thing with older data collector and field software in a pinch.
@gary_g Well I reckon the chandler cycle and gnss is the only solution . I remember my grandpa saying when he was young that the old timers use go say a generation is coming that will be upset that we used all our water for growing hog feed. Of course he was a very frugal man and we never was able to waste much as kids. That meant us kids shared the bath water. Now he was brought up without indoor plumbing so he understood how much energy it took to tote water for everything. Something that i will never do except when i have to tote water buckets to the end of the drive which is about 800 ft for wife to water her flowers lol.
I think the customers freaked every time control coordinates were updated and the vendors went along with it. Essentially all they do is copy the old parameters and rename it to the new name being used. The NAD 83 cage built of lines of latitude and longitude has the same definition as always. The earth and the control points move around inside the cage thus updated coordinates are realized. It doesn't mean you need a new NAD83 configuration in your survey field software.
That's my opinion as well.
I don't blame the manufacturers for trying to keep things as basic and simple as possible. It's hard enough to get folks to learn the actual concepts behind datums and transformations. How will they grasp what the software is doing if they don't even know the basics?
You can always check/verify this in Access by reviewing the global and local values in the Point Manager
Ok, this comment is not going to reveal my gratitude for all the recent posts (and I’m taking @rover83’s eloquent comment completely out of context), but I can’t help myself:
The OP said they were using Trimble ACCESS and could connect to a VRS that broadcasted NAD83(2011) corrections.
Since this particular VRS is similar to a base that was set on NAD83(2011) coordinates, as it is broadcasting NAD83(2011) corrections, then in order to see NAD83(2011) coordinates on their rover’s screen, they just select “United States/NAD83” and a State Plane… oh, dang it… then they see a bunch of Northings and Eastings on the screen… BUT! we could go into the point editor individually and look at the global coordinates, and there they are, NAD83(2011) lat/longs. Hiding but beautiful.
I probably wouldn’t be curious about this if I wasn’t trying to use the RTN technique for GPSonBM, but is there no other way than to survey in State Plane or some godforsaken UTM projection?
Why can I survey with the data collector explicitly set to the ellipsoidal NAD83(MA2011) but not the ellipsoidal NAD83(PA2011)?
@fugarewe this shows why the understanding of the difference between a DATUM and Projection and coordinate system(s) need to be understood at a basic level. Especially state plane coordinates and utm. You might not have said it directly but you indirectly you pulled the wool from the eyes.
You may survey in an infinite number of projections using NAD83(2011). Right there in TBC is an option to create your own. In fact there are two options to do that, maybe there's more, I've only used the default TM projection and the Coordinate System Manager. The underlying NAD83 data in MA is the same as in PA, if I'm understanding your comment correctly.
Why can I survey with the data collector explicitly set to the ellipsoidal NAD83(MA2011) but not the ellipsoidal NAD83(PA2011)?
What DC and version are you using? I don't remember seeing the plate designations in earlier versions, but I always set up templates when the controllers were updated so I rarely looked at the other datums. Trimble cleaned up the datums and zones last year (v2022.10 update), but generally kept the nomenclature.
These days, all the coordinate systems in the NAD83 groups state (2011) without a plate designation:
If you are surveying on the Pacific or Mariana plate, there's no need to specify MA2011 or PA2011 in the controller, because when you set up your base, you input the coordinate that you want everything referenced to, because the computations are still the same no matter what plate you are on.
The controller isn't messing with those values, unless you tell it to by using a datum transformation and a custom system. (Or unless you are doing an RTX survey, which is whole 'nother ball of wax.)
There is an option to apply ITRF to NAD83(2011) to the project. However, when I try to use that option and state plane it seems to simply switch that out and apply NAD83(conus). The Global and Local coordinates are identical so I guess it isn't transforming ITRF to NAD83. Maybe I'm doing it wrong.
I am really confused by all of the varying discussions of reference ellipsoids. WGS84 is the reference ellipsoid for nearly every raw satellite’s reception and all of the CORS station. NAD83 is a coordinate transformation on a different ellipsoid. Lat and Long from autonomous WGS84 positions are EASILY converted to any of the NAD83 adjustments. Autonomous positions can be just as accurate as whatever number your fancy receiver displays. WHERE THE HECK DO YOU THINK ORIGINAL CORS POSTIONS COME FROM. Sorry, I just wanted to make sure you heard me. I may have gotten some nomenclature items above wrong, but the gist of my diatribe is correct.
The "ITRF to NAD83" option disappeared in a recent update to Access.
With the release of TBC 5.90 and the support of NGS NCAT NAD83 transformations under the hood, I am hoping that Access will soon follow suit and allow users to modify the datums during NAD83 job setup. It already does that for the UTM projections, so the functionality is there...
I am really confused by all of the varying discussions of reference ellipsoids. WGS84 is the reference ellipsoid for nearly every raw satellite’s reception and all of the CORS station. NAD83 is a coordinate transformation on a different ellipsoid.
Computations done on the WGS84 ellipsoid are, for all practical purposes, exactly the same as the same comps done on the GRS80 ellipsoid.
Autonomous positions can be just as accurate as whatever number your fancy receiver displays. WHERE THE HELL DO YOU THINK ORIGINAL CORS POSTIONS COME FROM.
A CORS that has been tracked for years and years is a little different than a base receiver grabbing an instantaneous autonomous position and locking it down for the remainder of a day's survey.
In any case, published CORS positions are adjusted, not autonomous, and we typically hold those published positions during processing while perhaps using the short-term time series for standard errors.
Did the earth axis never shift prior to groundwater pumping? One year they say axis shift caused the Ice Age. Another year they say dead dinosaurs and vegetation ended the ice age and started global warming. Later years they say the Ford Explorer exacerbated global warming to the point we had to change its name to Climate Change. Now moving ground water to the surface to transvaporate, has caused the earth to shift back. Should I go buy snow tires for my Ford Explorer since the Ice Age is coming back?
WARNING: Sarcastictic non-politcal humor, I believe none of the above post, hmmpt. I hope Gary doesn't mind me stepping on his post. Without it, I would have not known of that particular scientific thought. It may not appear so, but I found it very interesting.
I am really confused by all of the varying discussions of reference ellipsoids. WGS84 is the reference ellipsoid for nearly every raw satellite’s reception and all of the CORS station. NAD83 is a coordinate transformation on a different ellipsoid.
Computations done on the WGS84 ellipsoid are, for all practical purposes, exactly the same as the same comps done on the GRS80 ellipsoid.
Autonomous positions can be just as accurate as whatever number your fancy receiver displays. WHERE THE HELL DO YOU THINK ORIGINAL CORS POSTIONS COME FROM.
A CORS that has been tracked for years and years is a little different than a base receiver grabbing an instantaneous autonomous position and locking it down for the remainder of a day's survey.
In any case, published CORS positions are adjusted, not autonomous, and we typically hold those published positions during processing while perhaps using the short-term time series for standard errors.
Both start from an autonomous postion. It is the same thing, just a longer observation time. 15 minutes of static is the same as 2 hours of static, just longer and more precise. Autonomous positions are just as accurate as a NAD83 position, its just the value that is different.
Where did that original CORS value come from? Of course it is adusted, just like your traverse gets adjusted. The value may change, but it is still just a nail in the dirt measured with the same two angles and same two distances.
The CORS Stations that I use get revised annually from new autonomous postions.
@oldpacer Concept seems reasonable enough. Take a spinning ball and redistribute a significant portion of mass from a small area to all areas of the system and this should cause a change in the axis of rotation. i would think it would simply be a calculation of the mass needed to cause x amount of change. Someone probably can't directly attribute the pumping of ground water to the change in the axis of rotation but they certainly could model the amount of mass needed to be moved in order to cause the change.
