There's a ppm error there as well, but that's a usually a different problem. If different units were used, it would be obvious when checking in on the benchmark.
If it's in northing and easting, the baselines are to the South and West of all coordinates covered by the projection, plus an offset. So it might start at 1000000 instead of zero, to ensure format consistency and to catch blunders.
So it's about 2ppm, multiplied by the number of feet between you and the Southern or Western most edge of your state (if single projection state) plus 10^5 or 10^6 or similar.
It's designed to make an error large enough to notice.
Vertical however is rarely a problem, as it's all based off local benchmarks.
Wouldn't the elevation difference between benchmark and site be the important bit here? If so, then the difference would rarely be more than a mile, and the resulting error would be at most an 1/8"
It has been 20 years since I worked in this area so likely I have some details wrong. If elevation is distance to the center of the earth 1/8" per mile is 40 feet!
From the link below you can see the noaa benchmark is using both elevation in feet above sea level and in meters from the center of the earth.
If you're not converting H (gps orthometric height) to E (local elevation datum to "sea level") first, you're doing it wrong, for a number of practical reasons.
Usually there's not even a reason to use H directly anymore, since elevations should reference a local benchmark.
GPS has changed things, but surveyors are still obscenely practical when it comes to procedures for eliminating systematic error.
Using an RTK-GNSS requires a gravitational model of the earth to measure mean sea level (MSL). Using your position, you use the GEOID model to figure out the delta of the nav satellite's orbit to the MSL.
Yes, That's what I mean by going straight from H to e first. The geoid is that conversion.
Although for rtk, the delta isn't to any of the sats, it's to your base station. The deltas to the sats cancel out of the equations, which is where most of the gains in accuracy come from. But it still needs to be tied into a known elevation benchmark.
That said, most field crews will still be shooting a differential to a published benchmark, or plugging the geoid file into the data collector, or dialing into a vrs or cors that already is adjusting for the geoid. For them, H is just an extra data point asking to be plugged into the wrong data field.
Unless you're doing static observations or geodesy or manual network adjustments or direct gravity readings, the new way (22) isn't all that different from the old way (83). There's just different underlying theory of MSL and different math to adjust the network. And if you are doing any of those things, then you generally already know what you're doing.
We're not even getting to the topic of elevation (yet). The US Survey Foot is 1200/3937 which is a not a clean value that terminates after a few decimal places. With high grid coordinates (X,Y), your origin is based at 0,0 as origin. When you scale between metric and US Imperial, if you're not using enough significant digits it impacts how the model scales. This can cause a difference of 1 foot or more from my experience. Floating point operators also become an issue especially in CAD. Standardizing to one number is a great start.
If it's in northing and easting, the baselines are to the South and West of all coordinates covered by the projection, plus an offset. So it might start at 1000000 instead of zero, to ensure format consistency and to catch blunders.
So it's about 2ppm, multiplied by the number of feet between you and the Southern or Western most edge of your state (if single projection state) plus 10^5 or 10^6 or similar.
It's designed to make an error large enough to notice.
Vertical however is rarely a problem, as it's all based off local benchmarks.