-
Why don't the filesizes for the INTG.EXE, INTG, INTD.EXE, and INTD executable files
match those given in the README files on the CD-ROM?
-
The executable files were recompiled after revisions had been made to them.
The filesizes for the source code were changed in the README files, but the
filesizes for the executables were not updated before the CD-ROM's were
pressed. The correct file sizes are given below and are now reflected in
the online versions of the README files.
The following is a list of file sizes that are wrong and need fixing
in the README file:
Name Wrong value in README Correct value
INTG.EXE 161,280 169,472
INTG 107,320 122,388
INTD.EXE 183,296 194,048
INTD 127,112 148,012
-
In simplest terms, what files do I need and how must they be set up to run GEOID99?
-
To "run" GEOID99, you need the following things:
- A working version of the INTG program on your computer
("INTG.EXE" on
PC/INTEL or "INTG" on SUN).
- At least one "g1999***.bin" file on your computer, or have
the GEOID99 CD in your CD-ROM drive.
That's it. The "*.bin" data files may be stored anywhere on your
computer, or you may use the files as stored on the GEOID99 CD-ROM.
If you are not working with an INTEL or SUN computer,
then instructions for setting up a working version of GEOID99
on other computers can be found in the GEOID99 readme file (g1999rme.txt).
This answer is applicable to G99SSS (needs one "s1999***.bin" file) and
DEFLEC99 (needs one pair of "x1999***.bin" and "e1999***.bin" files).
-
Are there formal accuracy estimates for GEOID99?
-
There are no formal accuracy estimates for GEOID99. The computation
of the gravimetric residual co-geoid undulations from residual
Faye gravity anomalies was done through a 1-D FFT representation
of the spherical Stokes integral, which inherently contains no
formal accuracy estimation.
However, in the United States we have a fairly homogenous distribution
of GPS-derived ellipsoid heights (in the NAD 83 datum) co-located
with leveled Helmert orthometric heights (in the NAVD 88 datum) and
these data are used to control long wavelength errors in the
geoid model as well as providing an accuracy check. It is found,
nationwide, that we are able to reproduce GPS/level derived geoid
undulations with our GEOID99 model to the +/- 4.6 cm level. The
source of this disagreement is both the error in GPS heights as
well as geoid and leveling errors. Separation of the errors is
difficult, but preliminary analysis indicates that +/- 2.5 cm of
that is geoid error.
Dr. Dennis Milbert performed some preliminary Monte Carlo estimates
of the geoid error back in 1993 and found that the propogation of
anomaly error into geoid error was bowl-shaped, leaving small (sub cm)
errors in the center of the country and large (10+ cm) errors in the
oceans. This situation has changed somewhat with the inclusion of
satellite altimetry, and numerous data and computational improvements
since 1993, however.
-
What's the difference between GEOID96 and GEOID99 (in plain English, please)?
-
Put simply, GEOID99 is an improved version of GEOID96. There
was better data in GEOID99 and better computational methods
in GEOID99. That meant, overall, a better geoid model. This
is most obviously seen in the comparison of each geoid model
to GPS on leveled benchmarks. GEOID96 had an absolute
agreement of +/- 5.5 cm (1 sigma) relative to 2951 GPS-BMs.
GEOID99 has an absolute agreement of +/- 4.6 cm (1 sigma)
relative to 6169 GPS-BMs.
For those who care about technical details, here's a running
list of differences between GEOID96 and GEOID99:
| Category
| GEOID96
| GEOID99
|
| Year
| 1996
| 1999
|
Gravimetric
Base Model
| G96SSS
| G99SSS
|
| Gravity Measurements
| 1.6 Million*
| 2.0 Million*
|
| Altimetry
| Sandwell/Smith
Version 6.2
| KMS98
|
| DEM
| TOPO30
(30 arcsecond)
| Corrected TOPO30 (30 arcsecond)
and NGSDEM99 (1 arcsecond)
|
Terrain Corrections
(Resolution)
| 30 arc-second
| 30 and 3 arc-second
|
Terrain Corrections
(Method)
| 2-D FFT single run
| 2-D FFT multi-band runs
|
| Global Geopotential Model
| EGM96
| EGM96
|
| Geocentric Reference Frame
| ITRF94
| ITRF97
|
Horizontal
Resolution
| 2 arc-minutes
| 1 arc-minute
|
North Edge of
CONUS computation
| 54 degrees
| 58 degrees
|
| NAVD 88 bias estimate
| -31 cm
| -52 cm
|
| GPS on Benchmarks
| 2951
| 6169
|
Accuracy (1 sigma) wrt
GPS/Benchmarks
| 5.5 cm
| 4.6 cm
|
* - There were not 400,000 new gravity measurements taken between 1996 and 1999. The
reason for this increase is mostly due to expanding the computational area of the CONUS grid.
-
Are you telling me that POSITIVE WEST LONGITUDES don't work in INTG?
-
The initial version (1.0) of INTG and INTD was loaded
on September 30, 1999. That version only allowed positive
East longitudes. Later versions (1.1 and higher) of INTG and INTD
do allow positive WEST longitudes.
-
My copy of INTG (or INTD) doesn't work right. What's up?
-
The initial version of INTG (and INTD) was version 1.0, loaded
on September 30, 1999. There were some bugs and oversights
still in that code, particularly with respect to Blue Book formats.
Newer versions of INTG (and INTD), have been loaded since then.
Try downloading the latest version and see if that helps.
-
What do the filenames indicate about the type of data they contain?
-
A typical filename, "tyyyyrnn.fff", would indicate:
- t: The type of data contained in the file
- t = g means hybrid geoid model undulations (i.e. GEOID96, GEOID99)
- t = s means gravimetric geoid model undulations (i.e. G99SSS, G96SSS)
- t = x means Deflections of the vertical in the North/South direction (Xi)
- t = e means Deflections of the vertical in the East/West direction (Eta)
- yyyy: The year the data was created
- r: The main region where the data are located
- r = u means "Conterminous USA"
- r = a means "Alaska"
- r = h means "Hawaii"
- r = p means "Puerto Rico and the American Virgin Islands"
- nn: The sub-region number of this file
- CONUS, has 8 overlapping sub-regions (nn=01 to 08)
- Alaska, has 4 overlapping sub-regions (nn=01 to 04)
- Hawaii has1 sub-region (nn=01)
- Puerto Rico and the American Virgin Islands has 1 sub-region (nn=01)
- fff: The format of the data file
- fff = bin means FORTRAN 77 direct access binary file
- fff = asc means ASCII file
So, for example, "g1999u01.bin" means "GEOID99 in CONUS, sub-grid #1, in binary"
-
What is the new format for the data files?
-
The new file format for any sub-grid file (GEOID99, G99SSS or DEFLEC99 files)
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 Variab Variable
Type Name Description
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"
45-48 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
- The actual numbers of rows (nla) and columns (nlo) for each
sub-grid is the same within each region but varies between regions:
REGION ROWS COLUMNS
(nla) (nlo)
Conterminous United States 1081 1141
Alaska 721 1921
Hawaii 361 421
Puerto Rico and the Virgin Islands 361 301
-
Isn't this different than what you announced in May?
-
Yes, slightly. In May we anticipated using FORTRAN unformatted binary
files. We ended up using FORTRAN direct-access binary files. Because
each FORTRAN compiler (we tried 4 of the many available) stores "buffer"
bytes differently in a FORTRAN unformatted binary file, that prevented
us from creating unformatted binary files with one compiler and letting users
use another compiler to read them. All compilers use the same way of
storing direct access binary files, so this was clearly the solution.
The ordering of the data remains as we announced in May, there just aren't
any of the "buffer" bytes that come with a FORTRAN unformatted binary file
now.
-
Why was the file format changed from the old "*.GEO" (and "*.XII" and "*.ETA") format
in the first place?
-
For GEOID96, the header inormation was ASCII data while the gridded data were in
binary. This caused failures for some browsers attempting to download those data.
Due to these difficulties, a purely binary format was desired.
-
Will you be releasing GEOID99 in the "*.GEO" format at all?
-
No. The "*.GEO" format is effectively retired.
-
On which platforms can I run GEOID99 (G99SSS, DEFLEC96) software?
-
We have provided working versions of all software for GEOID99, G99SSS and DEFLEC96
for the PC(Intel) platform and the Sun platforms. In addition we provide a third
set of data and software, which we call "ASCII", which is not ready-to-run
as is, but does allow you to set up your own working version on whatever
non-PC non-Sun platform you use. If you wish to run the software
on any machine besides a PC or Sun, you should download the ASCII version of
the data (and un-gzip it), and compile the XNTG.FOR (or XNTD.FOR) program
with your own local FORTRAN compiler. Then you may use the XNTG (or XNTD) executable
to convert the "*.asc" data files into "*.bin" files on your machine. After
that, you need only compile the INTG.FOR (or INTD.FOR) program and you should
have a working version of data and software on your own platform!
-
Will the new software work with the old (i.e. GEOID96) data files?
-
Not yet. The new software does not work with .GEO, .XII nor .ETA files. A
re-release of GEOID96 with the new .bin format may occur later in 1999. For
now, the GEOID96 files still work with the old GEOID.FOR and GEOGRD.FOR
programs.
-
I see you have two different models for the U.S., GEOID99 and G99SSS.
Which should I use?
-
In general, most users should work with GEOID99. It is constructed to relate
GPS ellipsoid heights in NAD 83 and orthometric heights in the NAVD 88 datum.
These are the datums used in many maps and charts, and it is likely that your
application requires that consistency.