This summarizes my understanding of some of the basic ideas. Because it is hard to find all of them clearly described and summarized in one place, I could be wrong or misleading about some of them: comments and corrections are welcome.
"Geoids" are approximations to a surface of gravitational equipotential.
The geoid is a hypothetical Earth surface ...
WGS84 is natively XYZ, like the International Terrestrial Reference Frames (ITRF), and you can use an ellipsoid model to convert to latitude, longitude, and ellipsoidal height. Ellipsoidal heights aren't very useful. Water can flow up here, and it doesn't reflect the terrain at all.
A geoid, kinda sorta, is the surface you would get if there were tubes ...
I am not a Geodesy expert, but far as I understand it, the geoid, is the shape that the surface of the oceans would take under the influence of gravity alone. It is the surface at which the intensity of gravity is the same.
The Problem isn't that it is difficult to describe mathematically, but it might be impossible to predict correctly and accurately.
Convert from (EGM96) geoid vertical datum to (WGS84) ellipsoid vertical datum:
gdalwarp -s_srs "+proj=longlat +datum=WGS84 +no_defs +geoidgrids=egm96_15.gtx" -t_srs "+proj=longlat +datum=WGS84 +no_def" dem_in_egm96_geoid.tif dem_in_wgs84_ellipsoid.tif
You will need the gtx file containing vertical datum shifts from here:
EDIT: I've updated this to do an actual surface.
It's interactive with rgl, and you can zoom in to see the closed surface but you'll need more work to respect the actual WGS84 datum and get your vertical exaggeration just right.
Download the files with R:
baseurl <- "http://earth-info.nga.mil/GandG/wgs84/gravitymod/egm2008/GIS/world_geoid"
GPS units can be pre-loaded with one or more geoids, which can be used to calculate elevations by geoid separation. But support for this feature varies by manufacturer and by device.
On many Trimble GPS units (and probably units from other manufacturers who make higher-end GNSS hardware for professional surveying), the geoid is stored on the device. Trimble ...
Downvote me if I'm wrong, but the GEOID is a concatenation of a bunch of fields as noted in the summary file documentation on page 13. In the geographic area codes, you'll be looking for fields at positions 26-65.
The normal to the ellipsoid is the vector orthogonal to the tangent to the ellipsoid at that point. This will not point to the center of the earth except at the equator and the poles.
The gravity vector is orthogonal to the geiod and varies from the ellipsoidal normal by an amount called the deflection of the vertical. Which is usually expressed in the ...
Here's a few improvements on previous answer.
Use randomCoordinates to more evenly distribute the points, and save creating any intermediate rasters.
Just a 2D triangulation, simpler and more directly what we want, though there's more required, you need work to "seal" the surface properly by triangulating in a smarter way.
To really get the exaggeration ...
Earth's surface is often represented as an ellipsoid and an ellipsoid is just an oblate sphere. What controls water flow is the relief and topography of the earth under the rules of gravity (or more correctly general relativity) and hypothetically pressure. I actually think water would not flow on a perfect spheroid under gravity and I think on a perfect ...
The Wikipedia article is out of date. The current WGS84 geoid model is EGM2008 which comes in two public versions: 2.5' x 2.5' and 1' x 1'.
WGS84 itself has has several realizations such as G973 and the latest, G1762, which are linked to various International Terrestrial Reference Frames (ITRF). Confluence GIS has a nice table on them. With each new ...
This answer isn't a single command, but I'll put it in to get the ball rolling. Use gdalwarp to resample the geoid grid, then gdal_calc.py to shift the original raster.
gdalwarp -s_srs epsg:4326 -t_srs epsg:26910 -r cubic -tr 10 10 -tap HT2_0.gtx HT2_0_resampled.tif
gdal_calc.py -A original.tif -B HT2_0_resampled.tif --calc="A+B" --outfile=shifted.tif
QField can record z value from NMEA sentence. Create a layer, then save as, select geometry type and flag include z-dimension.
I use it with an RTK GNSS. I collect point, lines (I have not try with area).
Create a new field in the attribute table called z and use an expression such as : Z($geometry) - (the height of pole) to calculate the z of ground.
I realise this is an old thread now but for future reference Earth is represented as a type of ellipsoid called an oblate spheroid. The oblate spheroid is a result of the balancing between self gravitation forces and rotation forces (centrifugal force) and this balancing intuitively results in an force vector that is equal at all points along the spheroid ...
If this is the walkable food data:
Download the zipped shapefile (or kml), go to your data dashboard on Cartodb (http://yourname.cartodb.com/dashboard/datasets), and drag the zipfile onto the page:
It's already "georeferenced" - but maybe this isn'...
PROJ and cs2cs were mainly designed to convert between 2D datums. There was some effort to add vertical datums, but this has not gone very far:
If you need height coordinates conversion, feel free to sponsor the development ;-)
The term horizontal datum is used because it is more easily flattened into 2 dimensions and more useful for finding locations on a flat plane (compared to a vertical datum).
As in the ESRI post you referenced (image below), the Earth's surface is very uneven, so modeling this very difficult. The "ellipsoid" used in horizontal datums is close approximation ...
After several years, I finally created my own code to build a schema. However, it is currently embedded in a python library, so it isn't generally usable as a spec. Here is the geoid module, which parses and generate Census geoids, with variants for Census, Tiger and ACS formats:
If you are handy with ...
PDAL can do this with its filters.reprojection capability, which is based on the vertical datum transformation capabilities of Proj.4.
pdal translate input.las output.las reprojection
Make sure that egm08_25.gtx, defined in GDAL_DATA's vertcs.csv file ...
I think there is a problem with the way you are thinking about the whole thing.
To sum up:
You use Cesium points which are from a Digital Elevation Model. Those points are expressed in WGS84 and the height representation is ellipsoidal height
GPS gives you height which is ellipsoidal height
You have geoid height from the EGM2008 model
So when you ...
Yes, you must use an ellipsoid (or other mathematical surfaces).
the reason is that the Geoid is a Physical surface (defined as the equipotential surface of gravity strength field). Simple meaning - it has no mathematical formula (another simple meaning - it is a surface at the height of the mean sea level that if you put a drop of water on it it wont move)....
The answer depends on what you are interested in and therefore what you mean by 'earth's surface'. The Geoid is the equipotential surface (in terms of gravitational potential). The ellipsoid is a geometric approximation of the irregular land-sea (physical) surface. Given the irregularities even in the physical surface, no ellipsoid can ever do a perfect job. ...
EPSG:2284 only specifies the horizontal coordinates, the altitudes depend on the system the surveyor (or whoever captured the points) used. It could be in NAVD88, Mean Sea Level, etc. You'll have to check the data's metadata or ask whoever did the data collection.
For more on vertical datums see the National Geodetic Survey's page
LiDAR measurements are in the ellipsoidal height system. First, you have to see if the two sets use the same ellipsoidal system. I think the answer is yes and the system should be WGS84 (the GPS system).
I guess you have obtained your two sets of orthometric heights using:
OH_2003 = h_2003 - N_geoid03
OH_2009 = h_2009 - N_geoid09
where h_2003 and ...
To accurately compare these two LiDAR datasets do I need to update the old dataset to use the new geoid?
Yes, the two geoid models will have different ondulation values for different same coordinates and so different orthometric height. So, you have to account for that or you will have systematic deviations.
The text is not accurate. GRS80 and WGS84 describe really the ellipsoid only, they are not directly linked to any geoid as the text suggests.
But as the elevation above WGS84 elipsoid is not really useful, it is automatically converted by most GPS devices into height above sea level using some geoid model. EGM96 is one of them (there is also newer version ...
When measuring heights, there should be an initial point or zero point as reference for measuring. That is where the Geoid and Ellipsoid fits in. The Ellipsoid and Geoid are considered the initial points(zero), where heights are referenced from. Heights derived from satellites(ie.the use of RTK GPS, handheld gps e.t.c) are with reference to an Ellipsoid. ...
You can download a demo verion of the Hydromagic software from https://www.eye4software.com/download/
It includes a geoid converter freeware: https://www.eye4software.com/hydromagic/documentation/manual/utilities/geoid-file-conversion/
Supported file types are .geo, .ggf, .gsf, .byn, .bin, .grd, .txt, .gtx as source and destination.
They offer a bunch of ...
To convert from orthometric (vertical datum-based) heights to ellipsoidal heights, you need to add the geoid height to your Google Map elevations. I am not exactly sure how Google uses LMSL, it might simply be based on a local or national vertical datum (maybe like Normalhöhennull in Germany), but seeing that your data comes from Google Maps, using the ...