Negative Values on RTK Elevation

I recently surveyed a number of GCPs and the elevation is showing as negative. I’ve found a few other posts about this topic but I cant figure out the solution. I’ve used this same workflow/setup before any my elevations have been fine.

My understanding so far is that the Elevations are WGS84 ellipsoid and I have to convert them? I tried using this tool to convert but the elevations are still showing negative value. https://vdatum.noaa.gov/vdatumweb/

I dont understand why I’m getting this now as the projects I have done in the past, I just used the .csv export and it worked fine. How do I get these to the right elevations? I only need relative accuracy in state plane U.S. feet.

Is it in ReachView that you are getting negative values for the height?

Yes, in reachview on each point that I created.

Do you have .ubx raw-logs?

ellipsoid values can be negative. if you just need relative accuracy in feet then just get a accurate control point for your project site and scale all your values to match. there are more accurate ways to do it but maybe thats all you need to do.

Indeed, but it should be a fairly rare occurrence on the surface of the Earth, no? So if it happens in a mountainous region, it must be a bug.

2 Likes

no its not that rare, but i agree it seems odd for it to be in a mountain region which i assume you mean to be over 1000 feet elev. whats your correction source? your own local base or a NTRIP accessed base? RTK or PPK? did you log a raw file?

and i dont see much room here for a “bug” in this regard.

I am not saying it is :smiley: I am not the one with the problem :smiley:

Alright… Where I live (Denmark) i have to be below the surface of the sea to get negative ellipsoid heights. MSL is around 30 meters ellipsoid here. Hence I have never seen it on my own.

1 Like

The only reason they could be negative is if you are in a hole or if the accuracy of the ellipsoid and reading are far enough off to put you below MSL because you are within 100m or so of it.

2 Likes

This diagram can perhaps help you to better understand the phenomenon.

As you see sometimes A Geoid is under Ellipsoid and sometimes No, a same thing for Topographic surface.

5 Likes

You can also see that the ellipsoid theoretically never drops below the sea surface, but as I stated before poor accuracy/anomalies can cause this to happen occasionally. Odd thing is that they report that the sea levels have been steadily rising so accordingly the the last adjustment we should be above where it was?
It may not relate to this discussion, but another note is that this can occur on drones because of those levels and the barometric pressure.

thats just not correct, I work in the san francisco bay area, California, USA, and i commonly see negative ellipsoid heights while working well above the visible sea level. and that is with a 3 to 4 hour OPUS observation and with NTRIP RTK.

dsdata_jt9545.pdf (79.6 KB) 05-01-2018_JT9545_2_x90-static.pdf (92.3 KB)

3 Likes

If I’m only using them as GCP XYZ for photogrammetry can I use the negative values? Are they proportionally correct? I’m only measuring volumes from the project.

I am absolutely not disputing this and I see this all the time in other forums. I was just pointing out that if you look at several models that the intent was for it not too. This will give you an idea of where this could happen. The half way through the darkest green areas are very susceptible.

1 Like

then yes i think they are proportionally correct as long as your correction source was the same through out your data collection and your area of operation is relatively small (typical small UAS project). doing the math with a GEOID though will give you a modern orthometric elevation.

1 Like

Thanks for keeping that from going sideways… :grin:

2 Likes

Thank you everyone for the help. I ended up using the negative values since I need to get this project turned around quickly. For future projects, whats the best way to correct for this? Can I change settings before starting in Reachview to get the orthometric elevations? Or do I have to go through post-processing the log files?

You could try putting in a manual coordinate with an offset elevation?

Has anyone tried this? I know that the app has issues getting a fix when the horizontal position is not close enough to what would be an averaged position, but I have never tried vertical.

Maybe easier in your scenario is to batch edit them in Excel afterwards. One hack that I do when managing GCP’s is that I export all the GNSS data, BUT I use the ground elevation from our control localization instead of the GNSS height . The only problem this causes is that the elevation is in feet so I always have to run a quick unit convert to meters before uploading into my processing software.

The smart ass answer is, find the cause of error and never do that again. :laughing:

If you can, maybe share the raw log for further investigation?

3 Likes

I’m in the same boat, working in the Puget Sound region of Washington State. I do all of my mapping on coastal sites, and it’s very common for most of my values to be negative in WGS84.

If my field readings are good (fix, dop, standard deviation of position, etc.), I assume that the relative accuracy of my points to one another is reliable and adjust the elevation in-post to A) a known reference, B) to published LiDAR elevations at a hard surface, or C) at a point collected with a different GPS unit (I have a handheld Trimble GeoXH that I use for validation).

Elegant solution? Absolutely not! Workable? Sure!