Using R360, Emlid RS2+, and M300 RTK and can not seem to figure out why elevations are way off for scan i just did. Hoping somebody can clear this up:
-Emlid was setup, had fix, and was logging data. It was connected to the Rock Network getting RTK during this (first time i had that on and wondering if this messed something up)
-M300 was using RTK from ODOT’s CORS network.
-Processed data and it was uploaded to cloud in WGS84/UTM 16N (32616) in meters and ellipsoid meters. Reprojected to NAD83/Ohio South- feet (3735) and NAVD88 (ft).
-I also shot some of the control points and other features at the site (borings, transmission tower, etc) using the Emlid in RTK Rover (still on Rock Network). I did stupidly use the Global CS coordinate system in the project settings i realized later.
The issue is with the elevations. Comparing one point (all are similar issue) i have the following:
-LiDAR elevation is ~808’, EmlidRover ~638’, and when it was surveyed during boring layout that point was ~748’.
-The 748 foot elevation is correct for that area.
-Horizontal coordinates seem to be all lining up, just everything is shifted vertically.
I’m not sure what the heck i did wrong to get this all mixed up. Appreciate any help. Thanks!
Tried a few things here are home.
Put emlid in backyard and got following differing elevations:
Emlid w/ Rock RTK, Emlid Flow using Global CS = 203m
Emlid w/ ODOT CORS RTCM3, Emlid Flow using Global CS= 204m
Emild w/ NO RTK, Emlid Flow using Global CS = 204m
Emlid w/ ODOT CORS RTCM3, Emlid Flow using NAD83/NAVD88= 237m
Emlid w/ NO RTK, Emlid Flow using NAD83/NAVD88= 238m
Emlid w/ ODOT CORS RTCM3, Emlid Flow using NAD83/Ellipsoidal= 202m
Clearly the difference between the boring layout survey and the EmlidRover point is one is ellipsoidal and other is NAVD88 (duh).
Still have no clue why the elevations in the LiDAR scan are 60 feet/18 meters higher than they should be.
The 18m difference you see is the delta between the ellipsoidal and the geoid.
In my part of the world, it is between 16-19m delta.
This is a feature, not a bug. Adjust your data to match what you need.
1 Like
Thanks. When i reproject from ellipsoid to geoid (NAD83/Ohio South- feet (3735) and NAVD88 (ft)) shouldnt that be “fixed” then?
You would think.
In my personal workflow, I process in the coord system in UTM with the elevation datum I want, then I adjust my data to be in and just adjust the “z” value to meet “real life” once done (that is why I have all those GCPs).
I rarely re-project unless the client wants a more eclectic coordinate system. Just make sure you shoot your GCPs in the coord system you want your finished product in.
1 Like
Appreciate your help. When you say you process in UTM with elevation datum you want, where are you doing that? Unless im missing something i dont see where i get any choice in processing in the R360 settings or Rock Desktop for what elevation datum is used. It does it in UTM/ellipsoid or does it depend on settings in the GPS base station maybe?
You process in Rock Desktop. You bring your Lidar data together with your base station correction data; all of this is done in Lat/Long (the universal purity).
Once the processing is done, THEN you convert to whatever you need, as your data was processed with Lat/Long (the universal purity).
Where do you enter the coord system you want?
- At the start of your project you are processing in the ROCK CLOUD (online, now that you have your laz file), it asks you to define the coord system (xy) and coord system (z) you would like to see your data in.
I always utilize my UTM (12N) and the modern vertical datum that works for USA.
After it loads into the ROCK CLOUD, just adjust your z to what you need (off the ellipsoid to ortho height) and if you shot your GCPs in the same xy datum you loaded your lidar data with, the x/y should match!
Got ya. I was thinking you meant you were making that change during processing in Desktop. Thanks!