Ellipsoid Height

What height information do you have to work from??ÿ Does the program already have an ellipsoidal height, orthometric height, or none of the above?

A GPS derived ground elevation.

The GPS measures ellipsoidal height.?ÿ If it also gives you orthometric (NAVD88), that is done by applying a geoid model.?ÿ So you should have ellipsoidal available to you.?ÿ I don't know what your program does with the numbers.

RTK GPS initially computes a cartesian x,y,z relative to the equatorial plane. It then transforms those coordinates to geaographic on whatever ellipsoid you choose. At that stage heights will be ellipsoid, relative to the control used. That of course assumes you used the correct height.

Next, the coordinates are projected by math or transformed by math or localization. Ellipsoid heights are converted to elevations by applying the geoid separation or again by some localization or mathematical violence.

Bottom line, GPS spits out what you tell it to, nothing more, nothing less...

An easy way to get a combined scale factor is using the free software corpscon. I don't have Survey Pro so I don't have any idea how it works. Corpscon can be googled and then downloaded, it is simple to use. Pay attention to the zone you want and the Geoid model however any Conus Geoid flavor will give you a combined scale factor within a ppm if you are in the US. I would use it even if you figure out the Survey Pro program as a check against what you are doing.?ÿ

Posted by: MightyMoe

An easy way to get a combined scale factor is using the free software corpscon. I don't have Survey Pro so I don't have any idea how it works.?ÿ

I have Survey Pro but?ÿ I would not attempt to use it to determine a point's CSF. I don't even know if it can be done in SP. Certainly you set up jobs in it to be on whatever grid system you want to work in and the software does it's magic on collected data. So it has the capacity at some level to determine scaling factors. But as far as reporting it to the user in real time - not so much. My go-to for such things is StarNet, with Corpscon being a back up system.?ÿ ?ÿ?ÿ

"My go-to for such things is StarNet, with Corpscon being a back up system."

?ÿ

There tends to be very slight differences in SF between programs that I've used, so I usually have corpscon as a back up to check. However, there is little chance that anything I've done with a combined SF will have an effect to the end result. Usually a SF is used to push up a grid to a surface "close" to ground. I'm assuming the OP needs it for that.?ÿ

At risk of being labeled a pedant, let me clarify that the scale factor (SF) does not require an elevation. It is a function of the location of the point within a grid zone. The application of a grid factor to a length yields a distance on the ellipsoid surface.

To allow reduction of distances to account for the height of the line other than at the ellipsoid we compute an elevation factor (EF). An elevation factor does require a height; it requires an ellipsoid height.?ÿ

The distance at the height of the line is computed using the combined factor (CF) the product of the GF and EF.

There is a nice graphic showing how grid and scale factors yield different lengths as a function of of the surface on which the measurements are desired here:

https://www.e-education.psu.edu/geog862/node/1815

As for the issue of where one obtains the required ellipsoid height, I would be wary of assuming that something displayed as ƒ??heightƒ? is either an orthometric or ellipsoid height. Perhaps the device is set to display an orthometric height using a stored geoid model? It would seem fundamental to know what your device is displaying.

?ÿI like the graphic showing the relationship of height systems here:

https://www.researchgate.net/figure/The-relationship-of-ellipsoid-height-h-orthometric-height-H-and-geoid-height-N-at_fig3_268516558

For those unaware, the equation for the computation of the elevation factor (EF) is: R/ (R + h) where h is the ellipsoid height. In the US one uses NAD83 ellipsoid heights.

I once explored numerically the impact of different R and h values on computed EF values. An HTML generated from a Matlab script see: http://geodesyattamucc.pbworks.com/w/file/fetch/110168668/compRfromEF.html

?ÿ

Important to note that older versions of Corpscon incorrectly used the orthometric height. Makes a difference of roughly 5 ppm if I recall correctly. Be sure to use the latest version to get the correct results.?ÿ

There should be no reason for a difference between software. The state plane formulas compute an exact value, as does the formula shown above by GeeOddMike. Unless one uses a different value for the radius. I use R=Sqrt(M x N) where M is the radius of curvature in the N-S direction and N is the radius of curvature in the E-W direction.

Here is a plot I made of the mean radius by latitude for a presentation I gave at Trimble Dimensions in 2012. I also included a value commonly used as a "mean value" as the bold line.?ÿ

?ÿ

In the old days (NAD27 SPC) the Combined Scale Factor was calculated by hand, the procedure was to measure the next point in a traverse and calculate a easting. Then mean the eastings of the two points, from there using a booklet with a chart of Grid Scale Factor numbers based on the easting you interpolate the value for the meaned easting.

To get the elevation factor you would add the elevation and 20,906,000'-the radius of the earth. Then divide 20,906,000 by the sum. This would be the ESF.?ÿ

Those two numbers were multiplied and that was the Combined Scale Factor. This number was multiplied by the measured ground horizontal distance and you have the grid distance. Unlike the trig table books which were 8 place tables the Grid Scale Factor tables were 6 places if I remember correctly. Plenty accurate for the purpose. Of course the 20,906,000 number isn't exact, but since it's a ratio, not a big deal to the calculation.?ÿ

The number 20,906,000 still sticks in my head all these years later, it must be at least 35 years since I've used it.

Posted by: John Hamilton

Important to note that older versions of Corpscon incorrectly used the orthometric height. Makes a difference of roughly 5 ppm if I recall correctly. Be sure to use the latest version to get the correct results.?ÿ

There should be no reason for a difference between software. The state plane formulas compute an exact value, as does the formula shown above by GeeOddMike. Unless one uses a different value for the radius. I use R=Sqrt(M x N) where M is the radius of curvature in the N-S direction and N is the radius of curvature in the E-W direction.

?ÿ

The differences I've noted in the past were very small, not meaningful to anything I was doing. It may have been how corpscon used to calculate using the ortho height. Where I am that would be <2ppm. I've been using Trimble for that calculation for a long time, before that it was a program created by a guy who posts here once in a while.?ÿ

Because in the old days they did not know the ellipsoid height, they used the orthometric height. This caused a scale bias in NAD27 as one went away from Meades Ranch in Kansas, especially to the west.?ÿ

Here is another slide showing the error in using an incorrect radius. As you can see, it gets more significant as the elevation increases.?ÿ

Not only did Copscon INCORRECTLY use orthometric heights in the 90's at least Trimble software did too, I guess hearkening back to the days in NAD27 where the ellipsoid height was assumed to be the same as the orthometric height and similarly (and still to this day) where many software packages indicate WGS84 and NAD83 are the same 🙂 Never trust that a software is necessarily any smarter than you are!!!

SHG

1 ppm per 6M in height, roughly 1/1,000,000 of the earth's radius. Doing the elevation scale calculation the number changes 1 digit in the 6th place per each 6M change in elevation. For NAD27 I suppose that was "close enough".?ÿ .01' per 10,000'. Nobody was going to get worked up about it back then.?ÿ

?ÿ

WRT Mr Hamiltonƒ??s statement ƒ??...that they did not know the ellipsoid heights, they used the orthometric heights.ƒ? ?ÿThe horizontal datum NAD27 was/is a regional datum. Not going too deeply into the weeds, developers of regional datums chose a reference ellipsoid that best fit their part of the world. The original at MEADES RANCH (near the center of CONUS) was where the ellipsoid was fitted.

It wasnƒ??t until the develop of technology that earth-centered datums became possible; NAD83 was the first. Given the subsequent development of GPS it might have been better to have waited. Hindsight is of course 20:20.

?ÿUntil the earth-centered datums, we worked in a 2D + 1D world where Lat/Lon work was separate from heights.

BTW, the correction for heights in the NAD27 grid system was called the ƒ??Sea Level Factor.ƒ? When I worked using state plane coordinates under NAD27 we computed mean combined factors for each measurement segment not for an entire project. This was in the 1970s/early 1980s.

As Mr Griggs notes, it is always important to know what your software is doing. While gross errors readily identify a problem, smaller discrepancies are more insidious. As Mr Hamilton indicated, small differences result from the choice of the ƒ??Rƒ? value in the EF computation. Using the Gaussian mean radius rather than the approximation for N. America of 20,906,000 ft will yield different results at the few millimeter level. Professionals should know when that matters.?ÿ

BTW, here is a tabulation of reference ellipsoid s (a, b, f^-1, and area where they were used):

I have never seen this map anywhere else (I have a copy that I acquired many years ago). It shows what the knowledge of the geoid was in 1974 (before NAD83, GPS, GRACE, etc). As can be seen, using a 0.0 height at Meades Ranch was pretty good for much of the country, but as one goes west it rapidly increases to about -30 m on the west coast, meaning 6 ppm scale bias out there.?ÿ