I know ReachView uses WGS84 ellipsoid for vertical height.
For the sake of simplicity, I’ll measure 4 points of my property boundary using a Reach RS ROVER and a Reach RS BASE.
So say I measure the points using ReachView Survey. It records my LLH (or XYZ) using WGS84 in METERS.
I am in the USA and need US Survey Feet.
How do I get the actual GROUND ELEVATION reading of each of those property points using ROVER? Not just the ellipsoid height, but the physical ground elevation? Do I have to locate a KNOWN point close by in the area as a reference or control point then the rest base from there? How do I get the known coordinates and actual ground elevation that matches that known physical point so I can load it into the BASE?
I can also do this in MicroSurvey FieldGenius (FG) and assign NAD83 or a State Plane coordinate system for Northing and Eastings instead of Lat Long. But it still reads vertical based on WGS84. I can load a GEOID for my region also, but I want to know the actual vertical GROUND elevation of my property at each of the 4 corner points?
I know I can also use FG to LOCALIZE to Northing and Easting coordinates in the field. I guess I would need to do the same for a known ground elevation also but just don’t know how to get that known ground height?
Thanks for the help as usual. I haven’t really had a need for vertical, but now do.
You need to find a published benchmark that you can shoot as part of your dataset and adjust. Many cities and counties now have some sort of GIS portal. Then you can setup your base manually with a ground elevation. Localization on multiple benchmarks will help verify you are correct. Otherwise you are at the mercy of whether or not the benchmark you found is any good.
We regularly have to ask for more monumentation on projects as we normally only get one vertical benchmark in the plans. Or we get two and only one of them is there. We need to to run a level loop.
What is a typical “GIS Portal”? it is an account you create with the city/county for access to surveys on record and obviously GIS data? Is it typical for them to charge for this information, or shouldn’t it be public record without fees typically?
I guess say in my case for simplicity, I would need at least (1) KNOWN point very close to my property and set base on it, and plug in provided LLH. Then as you say, if no other monuments etc with good vertical benchmark elevation, would have to run a level loop.
Is the vertical benchmark I happen to get from them based on Mean Sea Level (MSL) in reference to a GEOID or WGS84 ellipsoid… sorry I get confused exactly what I get here. (I guess where is the origin start for vertical? kind of like 0,0 for X,Y or Y,X (N,E). Origin to me for WGS84 would be at the ellipsoid. Origin for a GEOID would be determined by my location from the GEOID.
Thank you for the wonderful help @michaelL. This is something that baffles me a bit until I completely understand it. ; )
In our area the counties have tax appraisal district and usually a website where property information, plats and GIS information is available. Most of the cities with populations In the 10k’s and higher have some sort of GIS site that is similar, but will also contain public utilities maps and whatnot. Sometimes they have their benchmarks on there and sometimes it is just in the GIS section of the website. Counties normally have to be contacted directly.
You can use the OpenLayers>Maps plugin on QGIS to obtain coordinates that will get you very close if you are ever looking for something that has a coordinate, but that you have no other information for. I will use this to find property corners and monuments on-the-fly.
I may have gone a little out of bounds on that piece, but QGIS would be a huge compliment to what we do. Let me think about your questions a little more and i’ll update if I come across better resources.
Are you trying to get an orthometric height is that what you mean by “true” elevation? You can find NGS benchmarks here: National Geodetic Survey Data Explorer
In U.S. these benchmarks are tied to NAD83 horizontally and NAVD88 vertically. If you want to tie to these references simply take your Emlid measured ellipsoid height and subtract the geoid height for that location. For just the geoid height: GEOID12B GEOID HEIGHT COMPUTATION
This should be all you need. You can use this tool to tie your point to whatever vertical reference you fancy: https://vdatum.noaa.gov/vdatumweb/
From what I understand, the difference from the GEOID height and say the rover measured top point of interest of a mountain is orthometric height correct? (FieldGenius also uses WGS84 but also allows loading GEOID file for the area)
ReachView uses WGS84 ellipsoid, so the elevation height is gives in meters is the ellipsoid height.
I get confused WHEN to use either WGS84, GEOID, MSL, known point etc?
I guess what I need is what @michaelL is explaining above. I guess a more localized reference point(s) to base from. Or set my base on and plug in those KNOWN points so the rover gives me the proper points in relation to the known point (not a averaged or PPK solution, but something accurate on file).
Where does MSL come in? Is that another reference like ellipsoid, geoid height?
The vertical datum I reference is traversed into a specific area by our crews or surveyors from a given vertical benchmark from another document, construction plan or engineer. These are often 2nd, 3rd or even 4th generation traverses so it does absolutely no good to have a theoretical NAD83, GEOID12A or Ellipsoid EGM96 elevation. The are “true ground” based on ground levels and observations.
Is this a true separation from GIS or whatever this community has been doing and traditional land surveying?
I think this is where things get messy, in all directions (XYZ), A lot of different datums, each target for the spesific job because it does it so well for that spesific task and no datum is universal that fits all area.
Well said, except for localization. We have a unique situation in construction and unfortunately not many handle it like a surveyor would. Engineers sure don’t. A reformation that I have started in our company is that everything aligns to WGS84 and as a result, the drone data. Due to the fact that we do localizations the only ill effect is that we have to transform CAD files when we get them from engineers. Surveyor files are normally pretty good with minor exceptions in areas where they were smoking something and devised their own coordinate system.
There really is no “true” elevation data only relative to its reference. If @timd1971 wants to tie into another local reference frame like @michaelL with his Emlid unit, he would have to know the localized difference in height from the WGS84 ellipsoid and apply it to his survey. But again this is dependent on what reference he wants to tie to.
I am considering bringing this into a new thread but NGS is set to release a new datum replacing NAD83 and NAVD88 in an attempt to bring all of this together. Lot and lots of good info to tease out. Very informative docs. New Datums - National Geodetic Survey
Maybe someone can explain the value of having a local coordinate system as opposed to a universal reference system? Are they inherently more accurate? Why go through all these transformations when we don’t have to? Its the same point on the ground, why does it need 10 different coordinates and datums attached to it? The days of surveyors “creating” their own coordinates seems dated to me, we have the technology to not necessarily need to do this. I am by no means a surveyor, but again in this day in age, why do we create local coordinate systems?
A few years ago I would receive CAD files for projects in their own coordinate system and would have to best guess how to align with our GPS data. Tremendous error and offsets resulted. Now, majority of our files come to us tied to NAD83, same as our GPS and GIS project data. No more guessing on alignment as we are all in the same reference system.
Making sure you are referencing true GROUND datum. Maybe it would be better to say “reality”. This is the actual terrain that we work on. With localization it is angle and distance so regardless of what a geoid or ellipsoid says it is a euclidean measurement.
Because the world isn’t flat. -Captain Obvious (sorry!) ; )
Yeah, this day and age, you’d think we would just be using a 3D model of the Earth (GoogleEarth?) to do all our measuring (in reality) etc instead of many many many different map projections folded in our pocket (old technology).
This is where Google comes in. As they map from satellites and they get better our geoid resolution gets better. Right now it is not ground survey worthy.
For example I did a test of shooting in GCPs first with my localized Topcon referencing ground level-looped elevations and then with the Reach RS+ and ellipsoid. The GPS localization was thousandths to hundredths of a foot from the level-loop and the ellipsoid reported as much as a 10-foot deviation. Useless to me.
Making sure you are referencing true GROUND datum. Maybe it would be better to say “reality”. This is the actual terrain that we work on. With localization it is angle and distance so regardless of what a geoid or ellipsoid says it is a euclidean measurement.
This is the core of our discussion or “problem”
I have an affected thesis.
If it had not been for the tectonic plate moving in all directions and what not`s, the WGS84 or UTM with cartesian grid would do just fine (with som minor tweeks).
With all these CORS/OPUS/EUREF etc stations monitoring and recording data about satellites all over the world, how about them monitoring the earths movement and changes in all forms and update to a single uniform datum for everybody to use…
The “datum” keep track of all changes but we (users) only have to address one datum. The datum keeps track of our beeing and apply the appropriate adjustment.
