shift grid & geoid files

I don't (dunno) what a "shift grid" file is.

The NGS Geoid file format is described here:

http://www.ngs.noaa.gov/GEOID/GEOID12A/g2012Arme.txt

But that might no help you either (no NGS data in your neck of the woods).

Most all of this stuff is software dependent.

Loyal

Howdy,

As Loyal indicates file formats will vary by provider and data. For the US Geoid files see the FAQ from which the below was extracted.

You may want to examine the International Geoid Service for other possible file formats.

As far as "shift files" likewise there are files of differences in Lat and Lon between various versions of NAD. Format descriptions are in the site page for NADCON.

For Geoid 2012:

Q: What is the format for the data files?

A: The NGS .bin file format for any sub-grid file is identical: A 44 byte header followed by "nla" rows of data, each row being "nlo" elements long, each element being a 4 byte floating point number. The format chosen is known in FORTRAN lingo as "direct access binary". The exact ordering of the bytes is mapped below:

Bytes Data Variable Variable
Type Name Description
First Record:
1- 8 real*8 glamn Southermost Latitude of grid (decimal degrees)
9-16 real*8 glomn Westernmost Longitude of grid (decimal degrees)
17-24 real*8 dla Latitude spacing of grid (decimal degrees)
25-32 real*8 dlo Longitude spacing of grid (decimal degrees)
33-36 int*4 nla Number of rows of grid
37-40 int*4 nlo Number of columns of grid
41-44 int*4 ikind Set to "1", meaning the gridded data is "real*4"

Subsequent Records:
1- 4 real*4 data(1,1) Gridded value at element 1,1 (Southwest corner)
. . .

The rest of the file continues as 4 byte real values, filling in first the
south row (data(1,nlo) being the last variable in the south row), and then
proceeding northward.

The total number of bytes in a "*.bin" file is:
44 + 4*nla*nlo
Current models have dla and dlo equal to one arc-minute (0.01666666 degrees).

The data following the header record, as I said above, row-major.
Hence, each data record is a list of values "nlo" long (equating to the longitudinal intervals along the row of latitude)
and the record length = "nlo" * 4 bytes

Then the next northern row of data will be listed. This continues until the northernmost row, which is at the bottom of the file.

Hence, the first value in the data is the SW corner of the grid (westernmost point of southernmost row),
while the last point is in the NE corner (easternmost value on the northernmost row).

The binary data format is direct access. This means that the usual head/footer word that FORTRAN appends has been stripped off (just extra baggage). This is more akin to what C or other languages would read.

Inspect the XNTG_V12.ZIP files, available from various the GEOID12A and USGG2012 download pages. This program is designed to read a binary format input file and write an ASCII format output file.

HTH,

DMM

thanks,
I was not aware these files are brand dependent, why??

I have the Belgium(2005).sgf shift grid file and the Belgium hbg3.ggf geoid file on my Trimble TSC2.

I'll check our Belgian National Geodetic Institute of they have an ASCII file available. (I read on the website they delivered the data files to the GPS manufacturers, not sure if I can get these files)

For our little Belgium we have now one transformation parameter set for the whole country ... but it uses a sgf and ggf file to correct (E,N) and Elevations. Then (E,N) corrections vary from 0-30cm if I understand well.

Trying to figure out how to do my own calculations from raw RTK data.

thanks to both for your help,

Chr.

Howdy again,

You might find the file here: http://www.hypack.com/new/portals/1/PDF/sb/07_10/New%20Geoid%20Model%20for%20France%20and%20Information%20about%20Geoid%20File%20Formats.pdf of interest.

As to your comment, all the different model providers have different preferences regarding data reduction, wavelengths at which useful information can be extracted (signal/noise). One group might feel that a one-minute grid is excessive;others that it is insufficient. As long as the characteristics of the data file are known, it should not be a problem.

Be aware that there are significant issues involved when choosing the appropriate geoid model. In the US there are two primary models: a gravimetric and a hybrid model. The latter includes information and datum transformations making it more suitable for deriving orthometric heights from ellipsoid heights. Using GPS derived ellipsoid heights to derive heights consistent with national vertical datums (achieved in the US via the hybrid model) is a pretty challenging subject.

This is the "bookkeeping" part of geodesy, keeping everything consistent.

HTH,

DMM

There's a User Group for "PROJ4" software (freebie) that goes into exquisite detail regarding such grid file makeups for do-it-yourselfers. I have seen discussions on many country-to-country variations and esoteric quirks.

Should be relatively easy to find with a Google search.

Howdy again,

Having mentioned the International Geoid Service I decided to revisit the site. There are some good details about geoid models worldwide as well as software and modeling at: http://www.iges.polimi.it/Geoid/Europe/europe_g.html

The specific link above is to a European geoid.

Looks like much of the code is in Fortran. The memories...

BTW, net year's geoid school will be in Trieste, Italy. Visit a beautiful foreign land and spend the five days in an inside room doing math.

Cheers,

DMM

Howdy yet again,

There is an interesting article on the Belgian gravity network here: http://webftp.omp.obs-mip.fr/bgi/bgi_bulletin/BI90-2002.pdf

Cheers,

DMM

Thanks again for all the info and links,
there's so much knowledge available on this site!

Today I received both files in ascii format from our National Geographic Institute, so now I got a lot to read and some data to play with.
(Files are available if anyone interested ...)

Christof.