GeeOddMike, post: 360306, member: 677 wrote:
I now see what you are doing. You are assuming that N is always negative. It is not everywhere. The equations I provide are usable anywhere (although some parts of the world label h and H differently).
As explained previously, the various heights do not sum to zero as they were derived independently. As hybrid geoid models do combine h and H values (to compute N) there is a separability problem.
Image shows the arithmetic using the values in your post. Note that I have first shown your equation and then modified it.
Exactly, my intent is to fix H, n is going to be what it is, dependent on location; so h has to "float".
Yes, I have always seen n as -; I know in some areas that isn't so
These numbers are converging in the real world, they are getting closer, which is a good thing, and when the new numbers are released I assume they will work seamlessly, they will be totally model dependent so they should.
I've observed that if I run a static session from the near CORS to the north, I get an h, from the near south CORS I get one usually .2' different, and OPUS will adjust it often times holding close to one of them for some reason. If I adjust the same dat file from the same CORS station as OPUS, I will get a different number slightly different and if I send it off to RTX-PP I will get a third answer for h, the RTX-PP number will usually be the number nearest the NAVD88 value when the N is applied to h. So when the new elevations come out it will be interesting to see how stable the new system is.
The H=h-N equation is essentially correct, but beware:
- there are many "N" geoid models, which describe the offsets between various ellipsoid and orthometric frames. Know your inputs!
- NGS datasheets can provide N, H, and h, but they will rarely add up to zero. This is mainly because the geoid is from a MODEL, and isn't customized to fit at that mark; the misclosure shows that the (imperfect) surveys and (imperfect) modeling don't agree yet.
I wish NGS datasheets highlighted how poorly the equation closes at each mark, it can help you flag quality issues among the values (GPS, gravity, leveling, modeling.)
Joegeodesist, post: 360353, member: 6744 wrote: The H=h-N equation is essentially correct, but beware:
- there are many "N" geoid models, which describe the offsets between various ellipsoid and orthometric frames. Know your inputs!
- NGS datasheets can provide N, H, and h, but they will rarely add up to zero. This is mainly because the geoid is from a MODEL, and isn't customized to fit at that mark; the misclosure shows that the (imperfect) surveys and (imperfect) modeling don't agree yet.
I wish NGS datasheets highlighted how poorly the equation closes at each mark, it can help you flag quality issues among the values (GPS, gravity, leveling, modeling.)
Actually I would dispute that H=h-N is correct, that will not result in capturing the important number which is H.
h=H+N will hold H and N and allow h to float.
This has always been the problem, over just a few short years the reported h value has shifted 5" for the above point, pretty sure the ground hasn't sunk that much,,,,,,,,,,,,
However since 94 the H value hasn't changed, no doubt the N value is different with each GEOID model, so frankly I just don't care what Epoch it is, h for me is the floater. Applying Geoid 12B to NAD83 (93) or NAD83 (2011) will work just as well and it will produce an h value which is identical for each Epoch since H is fixed and has never changed through all the varies Epochs and models.
Applying Geoid09 or 03 to the same point will produce different h values which will not match the published ones for that Epoch, but I don't worry about chasing the bouncing ball that h is.
holding h is totally backwards.
