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.
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.
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.
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.
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.
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.
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.
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).