Trying to wrap my head around some items that were mentioned in another post of mine. Thought it was best to start a new post.
So I’ve been using our RS2 with a paid for NTRIP service Key Net GPS that covers the north east. I recently captured GCPs in Massachusetts Mainland State Plane but selected the NAVD for vertical. It was causing issues and they deducted the orthometric height to get back to ellipsoid I believe and it worked. This is where I get confused. Full disclaimer, I’m a new user for about a year so please dumb it down for me.
So if I capture without NAVD, isn’t the point of NAVD to get the exact height or location where my survey pole hits the earth? Where do Geoids and orthometric come into it? Sorry for such a newbie question but I can’t for the life of me get this figured out and straight.
Hey Seth! You’re not the only one. This has been a big discussion in this forum as long as I’ve been here. I felt like I was crazy coming in here talking about ground level-looped elevations and how things are done in surveying and construction in the United States.
“The definition of NAVD 88 uses the Helmert orthometric height, which calculates the location of the geoid (which approximates MSL) from modeled local gravity. The NAVD 88 model is based on then-available measurements, and remains fixed despite later improved geoid models.”
This is straight off the web. Note the two statements “approximates” and “then-available”. The ellipsoid and geoid are mathematical best guesses so when you add that to the previous statements you get something that is not in check with reality. The fact is that in the US almost every construction site has a coordinate system of its own. It may appear to be State Plane coordinates, but very rarely is a one-to-one transformation from GNSS data.
Probably one of the biggest factors in this would be CAD. It’s very easy for things to get slightly shifted or rotated to a point that you wouldn’t even know it unless you brought in a one-to-one transformed piece of GNSS data like Google Earth or a drone orthomosaic. Another thing that messes with surface coordinate systems is the scale factor and the condition of the actual control which in our case is usually property pins and a couple of vertical benchmarks. Property pins go missing and get moved and our vertical benchmarks are traversed in from other benchmarks which they themselves are not even first generation from NAVD.
In construction in particular we do a process called localization which is sometimes called transformation or calibration. Basically uses the monumentation as it exists on the ground and best fits it to the theoretical positions from a plat or CAD file. This instantaneously creates a new coordinate system relative only to that construction site. It’s not uncommon to have horizontal scale factors of 100 ft and vertical adjustments of up to 5 ft based on the difference in orthometric heights versus real ground elevations.
At the end of the day you are working with theoretical information against ground calculated information that is in a constant system of digital manipulation so there are a lot of factors as to why control and coordinate systems between two different parties don’t match. It’s the age-old surveying discussion.
Best to use surrounding local Benchmarks with available NAVD88 values if possible to use as vertical control. This will eliminate any errors or geoid issues for the area. This is not always possible however, but a minimum of at least 1 will suffice if close to the site
If you’re looking for standalone virtual data then what was being compared to in order to say the results were wrong?
To me it seems like you could fly with native WGS84 without GCP’s and let the +/- of the barometer do the relative measurements. If it is going to be localized into a piece of modeling software then who cares if it’s globally accurate or even cm accurate in relativity. Nobody playing the game is going to know.
There has to be some reason for trying to achieve any better accuracy then that. Does the whole course need to be tied to itself with high relative accuracy?
@wizprod Sure, but something can be centimeter-correct regardless of the datum. I’m sure marketing people have pulled off with less truthful statements on tons of products.
Regarding the original question, @Seth.Z, ellipsoid or geoid is really just where we define the zero. Both orthometric and ellipsoidal measurements are “correct” but they have a different zero, like Celcius and Kelvin. In your case, transforming your GCPs to and fro shouldn’t have much impact on the project as it’s all for a virtual product that won’t ever need to tie with reality unless you’re going to tell us it’s an augmented reality game!
Haha! And all the people that play it pick up their Crown and Cokes. Just under the assumption that this is for something more than a console… or I’m wrong and it’s a Monster drink and some Cheez-Itz.
Except that ortho isn’t true ground as has been discussed to death. If they are looking at the relative elevation difference between two points with ortho heights versus an auto-level on the ground they are not going to match.
I agree and I think it might come from the misconception that the geoid is an exact representation of the Earth’s shape (and all that equipotential stuff) when in actuality it is just an approximation.
Honestly, I’m not sure why the end company wants it that way but it’s the requirement for me to collect the data that way. I’m more interested in understanding the process vs. why they want it that way. Doesn’t adding in NAVD88 give you the exact orthometric height placement vs. without it which is simply just the ellipsoid height? The drone photos were tagged with WGS84 and my GCPs with state plane for a tighter resolution and then converted to WGS84. I’m guessing because WGS84 is ellipsoid and then I used NAVD with Orthometric, that was the issue and there was an offset between the two.
I think this is subjective to timeframe and as datum is updated. Like Gabriel said the Geoid is an approximation so anything based off of that in my opinion is not reality. It’s fine to say that this single point on the Earth is this orthometric height, but if you ground level-loop that point to the next official point I am almost 100% certain you are not going to match. The way that photogrammetry works is that it is using the ellipsoid value as zero and then the drone tags the images +/- based off of another reading. Most are the barometer, but I have seen others that use Lidar and others that use the RTK value when in the right datum. For instance a P4Pro determines an ellipsoid elevation at the point of takeoff. Then as you travel the readout is in feet or meters, but the background data is +/- a relationship from that takeoff point.
As far as GCP’s go I went as far as to test a Topcon Hiper setup vs an RS2 where the Topcon was localized to site control and local elevation benchmarks and the RS2 was shooting Geoid through FieldGenius. I shot a point in with the Topcon and then shot it with the RS2. I occupied several more points and when doing the math on the deltas from point to point the elevation differences were different. Topcon would say these two points are 3ft different and the RS2 said 6ft so you would think maybe there is just a 3ft offset to account for. Nope. The next point was a 1ft variation and so on.
I have been looking for answers to this ever since I have been on this forum and since it seems that very few others use local datum or localize I just gave up.
We always use local State Plane Coordinates and NGS NAVD88 values for positioning our boundary surveys, topographic survey control, aerial photogrammetry control, geodetic surveys, lidar surveys control. No problem with us. Been doing it for 40+ years. Secret is adequate control based on surrounding benchmarks and photo targets tied to the NSRS. Using surrounding benchmarks eliminates orthometric errors as the benchmarks are the ground surface.
But otherwise, I agree!