A geoid file is supposed to store the differences between elipsoid height and the geoid surface. But in which coordinate format does it store them and does it need localisation to use for a specific Region.
For example I do a cutout to a specific Region, does it need georeferencing as well? If i make an EGM2008 Europe Cutout, and lets say theres a job in Germany and one in Italy, do i have to loccalise that cutout for Germany and Italy respectively and have seperate EGM 2008 cutouts for each Region?
OR does the collection software do that when you set the project settings automatically
Geoid models are dependent on locations determined by your lat, long and applied to the ellipsoid height.
At lat 45 N long 20 E there will be a specific Geoid height calculated for that location in whatever Geoid model covers that point.
The Geoid height will slowly change as you move away from that point, it won't change very fast, .1meter in 1000 meters would be a fast change, but not unheard of.
You will get whatever number the model assigns to any point, the geoid will apply that number determined by your location and apply it to the ellipsoid height you say you are reading and give you an orthometric height, it's basically hands free. It's up to you to get the location correct, if you don't the Geoid model will apply the correction anyway and you will be off by the errors you introduce.
There should be no localization unless you want to back it in and apply it to a known orthometric height and allow the model to calculate the ellipsoid height which is what I do when I want to hold NAVD88 elevations.
Ok so geoids are stored on lat longtitude format and its the software job to translate that the active job projection and give the orthometric heights
"Location dependant differences" the lat lon supplies the location. It's like a chart, built on gravometric differences.
I believe the way the models are stored is that there is one coordinate in the file (upper left, or lower right, for example), and then a "spacing" record (i.e. the grid spacing of the values), and then all of the geoid separation values for each grid location (grid meaning lat/long values in a regularly spaced grid).
That way software can very quickly extract the values around a point (i,j) rather than have to search the geoid data file for the lat/long values.
For example: lower right=40å¡N/080å¡W, spacing=1 arc minute. After that, only the actual separation values for each coordinate are in the file. For example (made up numbers): -32.567,-32.456,-32.325, etc would be the separation at 40å¡00N/80å¡00W, 40å¡01N/80å¡00W, 40å¡02N/80å¡00W respectively (assuming the file was increasing in latitude first). This makes the file a random access file, which can be "addressed" very rapidly and data extracted infractions of a second rather than search through a 10MB file.
Geoid models often are split into subsets to allow for a smaller file to be available to the controller, you need to be sure the geoid model in the file in your collector covers the area you are working in.
If not then the data collector will not work, you will probably only see ? marks in the coordinate fields. At least that's my experience.
I've gone past my geoid model extents in the field and couldn't work.
At least couldn't work in the area with elevations.
I was a long way from the office and had to make-do until I could return and fix it.
Luckly for me it was a boundary job and I could work with ellipsoid heights and fix it later, but you need to be careful.
Today's controller can take much larger files, I just load conus anymore which is the entire US.