I am using SW Maps with a Facet Base station/ Rover configuration and am trying to figure out how to reconcile the Elevations SW maps gives with the elevations I measure with an arbitrary elevation reference I set (1000.00’ in a rock on-site). I am assuming all I have to do is convert the SW maps Ellipsoidal meter-elevations to US survey feet and offset from my 1000.00’ reference elevation. When I do this I get some elevations that are off quite a bit (6" or more and 8’ at the base station, which may be the antenna height no being subtracted properly). I know that SW maps has a little bug where if you set units to feet it still exports in meters, which I accounted for. I am assuming I don’t need to use any of the Scaling Factors (for elevations as is required for grid-to-ground transformations from the OPUS solution), or am I mistaken? I am not as clear on what, if anything, I should do with “Ortho elevations”. Right now, there are no Geoid models loaded into SW Maps (and I have no idea how to do that anyway) so all of those are being logged as zero. I feel I am close, but not close enough. Meaning, I kind of expected to see all known elevations come within a couple of inches as SW Maps was reporting 1" vertical accuracy when logging the 100-point averaged RTK-Fixed solution with stationary bipod rod-over-benchmark measurements. All benchmarks are within a few hundred feet and in a field with sunny and clear sight to the sky, with the Base somewhat centrally located - so ideal conditions. If I am doing the elevation conversion properly, then I guess I’ll just have to filter the wayward outliers somehow. Thoughts? Suggestions?
EDIT 1: I figured out how to load NOAA Geoid models into SW Maps. I am using GEOID 18 and will be going into the field to do some surveying today to get some data to play with. However, I’m even more confused after watching Surveyors videos on Ground-to Grid Transformation. It appears when they do the xform they only account for distances and not elevations. If geometry hasn’t changed in the last 50 years, then the vertical positions should change along with the horizontal as distances are stretched/shrunk to fit whichever earth-model you are trying to fit, yet no one seems to talk about that.
The geoid until we get the new datum is a hybrid model based on adjusted passive control points, benchmarks, therefore depending on the number of benchmarks in the area determines the Ortho accuracy. Ground to grid apply to horizontal distances of what you measure with a tape, chain, total station etc you are on ground measurements. Grid is what gps measurements give you, due to grid being a piece of paper depending upon the projection shape you sometimes need a scale factor to take those measurements and convert grid to ground. Some low distortion projections are available where grid equals ground.
The heights derived from gps are going to be your altitude which is the ellipsoid height minus the height of the geoid (in the case of around my parts the geoid is under the ellipsoid so our numbers get bigger). These heights are based on a datum that historically is tied to mean sea level which as you can imagine you may not even be near an ocean.
So the earth is moving right? Well the idea with a reference frame/datum is that if the benchmark on nad83 2011 epoch 2010 and navd88 geoid 18 coordinates are 10000,10000,1000 today they will be close to that in the future. Because in surveying we do not want our coordinates moving around on a job. So the CORS stations are constantly tracking to account for the shift and bring us back to where we are supposed to be.
A great book if you want to understand more is van sickle gps for land surveyors. You might find a copy floating around on Anna’s archive
Yes, you need to be thinking in terms of Orthometric Height and the Geoids.
I haven’t read through the SFE RTK Firmware in the context of a Base Station, but it shouldn’t matter since the RTCM observations aren’t related to a Geoid.
The Base will be nativily operating and calculating in ECEF, as all GNSS equipment does.
It is likely using a library (or the F9P) to also transform those into WGS84 (strictly guessing), but it’s main purpose as a Base Station is to send the Observation data. You will need to confirm w/ the source code, but you are likely in WGS84 at this point using SFE’s RTK Firmware.
It’s the Rover’s job to perform the RTK calculation (with the benefit of the RTCM stream) to resolve a 3D position in reference to the WGS84 Ellipsoid Surface onboard the Rover’s F9P.
The Height Above the Ellipsoid means nothing to Humans, so a Geoid is used to convert to an Ortho Height. The F9P has the EGM96 (IIRC) onboard and it’s fairly decimated, so it’s not very useful for your application. The Rover’s NMEA sentences are used by Your Software to back-out the position from the EGM96 Geoid and apply any Geoid that you wish.
There are many ways to introduce both random and systematic errors here, especially with the field work.
Thanks you for taking the time to respond. I think I understand the ellipsoid model and the geoid model, their differences and the relationship between the two. Where the broken link for me is relating my observed elevation differences in the field using a total station and how to reconcile those to the reported ellipsoidal or ortho heights reported by the GPS reciever (i.e. Facet Rover.) All I know is the base was set up by entering ECEF coordinates generated by OPUS using 6 hours of logged data with the FACET over an arbitrary point in the ground. To get my survey data, I set up the same facet, but now in Base Mode using the OPUS ECEF coords and set at the exact same rod height. The Base/Rover talk to each other over my LoRa radios and magically get a Fix over the point I am logging. The SW Maps reports Ellipsoidal height and now that I gave it the Geoid18 model it reports Ortho heights as well. I understand these heights are related and I further understand that the Geoid surface is by definition at Mean Sea Level. What I am looking for is how to take those heights and tie them into my ground elevation difference data. What I mean by “elevation difference” is that I set an arbitrary point on the ground at elevation 1000.00’ and use the total station to measure all other elevations based on that 1000’ reference. When I put my rover on the 1000.00’ reference SWmaps reports “Elevations” in meters and those elevations are within 7" of each other over several days under ideal conditions. Not great, but usable for contours/topography. So my issue is how to relate the GPS elvations back to my ground-based Total station elevations. I know the different earth models (ellipsoid and Geoids) are plumb (orthoganal) to the phystical ground point being observed. And my measured total station elevations are also measured relative to a plumb prism on a rod over the ground point. Is there some software transform I need to apply to the ellipsoidal/Geoidal elevations to adjust/correct to my physical earth based elevations? I understand the reason a similar transform is needed to adjust horizontal ground coordinates to horizontal grid coordinates and the concept of scale factor for distances. But I can’t seem to find discussions about elevations. To my way of thinking, All I need to do is take either of the ellipsoidal or geoid elevations SW maps reports in meters, scale by 39.37 inches per meter, subract from my 1000’ reference and use that difference to adjust all elevations to either total station physical ground or GPS ground. Does any of this make sense?
Really depends what kind of accuracy you’re looking for on your elevations using the states RTN here I typically do 1 or 2, 3 minute observations on 2 points using a low distortion projection set my total station up and hold one elevation and the geodetic angle and start traversing. My distance on say a 400 foot baseline is usually 0.02. now to do a base rover I would set up over a point and log data so you can process later with like opus. And the translate rotate your traverse. I have done my total station traverse on local assumed then shifted later in office with base point and observed 2nd point for rotation but I only ever use the base elevations. Many ways to skin a cat.
I agree with @AORPLS as this is how we normally use GNSS with Conventional Survey.
Drop 2 GNSS Control Points (easiest is a Network Rover, RTN) to situate your Conventional Data in real world coordinates (or assumed works just as well).
@BlackManOps, your description of your expectations seem correct to me.
Even though it’s likely not an issue for Topo work, another aspect to consider is your OPUS solution. That’s a NAD83(2011) solution for a plate-fixed system, even though it’s not an entirely fixed system. Your X,Y,Z answer from OPUS is where your Antenna would have been in 2010, and includes ~1 meter of error that’s baked into the NAD83 System versus the true Gravitational Center of the Earth. The Satellites are orbiting about the Gravitational Center and use ECEF.
So you’ve assigned X,Y,Z from the 2010 epoch to your Base, but that’s not what your Base and Rover are seeing today in real time. One might argue that this could have the same influence on RTK as a substantial error in the horizontal position and the Height of Instrument for your Base ARP. [I’m not saying that’s true, just a thought]. The Base/Rover system uses the RTCM Observation Data and assumes the Base Position was correct today.
The easy button (if you use OPUS) is to just use State Plane NAD83 for your survey, which you might already be doing. Keep in mind that you’ve started out with a 2010 position. You need to use NGS tools to bring that Base position to a current position, or remember that all RTK positions collected now are still in the NAD83(2011, 2010 epoch) reference.
Since it appears you’ll be using assumed coordinates. the easiest might be to perform the time-dependent adjustment to your OPUS solution ?
I like to describe GNSS as very similar to a typical Math Problem in school.
We use dimensional analysis to “keep the units right”. Once all the variables in a math problem have the same units, it basically solves itself.
In GNSS, the Reference Frames are the units.
The snag is we don’t always see the Reference Frames (the “units”) very easily, because the metadata is usually dropped unfortunately
AORPLS: I confess I am not a Professional Surveyor, so much of what you said is over my head since I am not familiar with the jargon. However, I think I get the jist of your workflow and it somewhat agrees with mine with the difference I don’t do traverses. I primarily do small lot contour/topograhy and wetland delineations. So when I get agreement to within an inch or two horizontally and/or vertically my error/accuracy requirements are met (wetlands have a +/-2 foot margin of error). I also do residential construction layout which allows for inch level slop as well.
However, I am trying to incorporate GPS into my workflow in an effort to be more efficient and survey in more heavily wooded or inaccessable areas to a total station. So I will have a mix of total station and GPS survey data. I dump my data into Autocad for drafting. Autocad has built in transform functions that take care of ground-to-grid or grid-to-gound as well as tools and commands that aid euclidian transforms (shift/rotate/scale) for imported survey plats etc.
My understanding and working knowlege of those tools is that they are X-Y/horizontal plane adjustments only. - i.e. not 3 dimensional. So I have treated elevations as simple verticals above the horizontal plane. This has worked fine when using total station data with autocad to generate autocad “surfaces” which represent elevation variations using contour lines.
Now that I am incorporating GPS data there are many additional steps to get to horizontal plane and elevation data compatable with the total station data. I am pretty sure I got the horizontal mapping done correctly by choosing the proper “datum” (WGS84 for SW Maps) and “projection” (ellipsoidal or Geoid) and “scaling (ESf,GSF,CSF)”. But I am hung up on the elevations component.
To rftop’s comment: My understanding is the the ESF, GSF and CSF are only related to reconciling the different earth models (i.e. N=h-H where N is Geoid height, h is ellipsoidal height and H is orthometric height). The height I’m interested in, and that is not explicitly called out in the relationship above, is the height I see on the actual ground. My confusion stems from there not being agreement with the facet GPS reported heights compared to the NGS heights of geodetic marks I have set my equipment on. In order to try and get some actual work done as I sort thru the reasons for not getting agreement from actual geodetic markers, I am thinking I could use simple arithmetic height differences from a point in the ground I use as a local reference. Specifically, if I set REF ELEV=1000.00’ in a centrally located rock and let my Rover cook on that for a bit to get GPS_ELEV at that point, I can now wonder around, gather rover points on site and then adjust all rover elevations by (REF_ELEV - GPS_ELEV) to adust back to what I call actual ground elevation. Mathematically this makes sense to me, but since I don’t know how GPS systems actually derive their “elevations” I don’t know if my simple mathematical model is accurate.
RFTOP: Your comment about using the 2010 epoch and State Plane NAD 83 just came in and represents an area I definitely need to study up on. All I can say is that I did look into this a while back and was using the NOAA Horizontal Time Dependant something-or-other tool to adjust for plate movement over time as described in the Sparkfuns tutorials and thru the comments on this forum. When I did this over local geodetic markers my results deviated even futrther than what I was supposed to get. Utimately I got more confused and set it aside. Since SW Maps produces coordinates in WGS84/UTM19N and Geoid18 I blindly used that to set up the transform autocad does when I import points. So, I agree, I should take another look at how I am establishing the Base Station location to make sure it is proper in both time and space. BUT, assuming I get the correct Base station location for todays date, can I use the elevation adjustment as described above?
I concur with your reasoning, but with the assumption you are working with Orthometric Heights.
Using your example:
Establish a repeatable point on a rock, and setup the Base where you can repeat the ARP at the known position.
Use the RTK Rover to locate 2 positions for a baseline (Point #1000, and #1001).
The Δ Z (Ortho Height) for the RTK points should match the Δ Z from your total station.
The baseline length should also match (w/ scale factor), but on a small site it can be insignificant.
“Match” = within a few hundredths of a foot.
It might make life easier to remove the Base Position from your analysis.
Treat the Base as only the local correction source.
Use your RTK baseline for referencing elevation, translation, and rotation in Autocad.
Point #1000 establishes the Elevation and Translation in Autocad for your ToPo point group.
Point #1001 is used for rotation of the group.
