Notifications
Clear all

GSF header format

7 Posts
4 Users
0 Reactions
87 Views
(@ncspiralguy)
Posts: 62
Member
Topic starter
 

I'm writing a program that outputs GSF files and I found an oddity in the header. The order of the numbers is south, west, north, east, width, height. The latitude comes first in the first two pairs, but the longitude first in the third. However, in the PDF that describes the format (currently at http://web.carlsonsw.com/files/knowledgebase/kbase_attach/716/Geoid%20Separation%20File%20Format.pdf ), they are the first line, the second line, the third line, the fourth line, the fifth line, and the fourth line. I'm wondering if the guy who wrote the description exchanged the last two lines.

Here are the heads of the GSF files I have:
$ head *.gsf
==> avl150.gsf <==
34.2333334
275.7833333
36.9333333
279.0999999
199
162
0.00000
0.00000
0.00000
0.00000

==> avl-clt150.gsf <==
33.8833333
275.7833333
36.9333333
280.8166667
302
183
0.00000
0.00000
0.00000
0.00000

==> NCAsheville100M.gsf <==
35.0167
276.1000
36.9833
278.0667
118.0
118.0
-28.6088
-28.5944
-28.5813
-28.5606

==> NCGreenHill150KM.gsf <==
34.5000
277.0500
36.3333
278.8833
110.0
110.0
-30.5497
-30.5496
-30.5468
-30.5428

==> test.gsf <==
-2.0000000
358.0000000
2.0000000
2.0000000
4
4
-2.88708
-2.14380
-1.27551
-0.28223
The first two are produced by my program (the data are zero because I haven't yet written the routine to fill the output geolattice with data from the input geolattice), the ones beginning NC are produced by Carlson, and the last one is test data used by my program. All the GSF files I've seen produced by Carlson have as many rows as columns. Can any of you confirm or deny that the fifth line is the width and the sixth the height?

 
Posted : December 8, 2016 7:00 pm
nate-the-surveyor
(@nate-the-surveyor)
Posts: 10522
Member
 

Um, thets beyond my knowledge and 'speriemce

 
Posted : December 9, 2016 3:39 pm
MarkSilver
(@mark-silver)
Posts: 714
Member
 

I am nearly 100% positive that the following fragment of DELPHI code will read ASCII files and output a valid .GSF file. I have used it extensively building files for GNSS Solutions over the years.

That said, the latest versions (5.02 and newer) of SurvCE (which was my typical reason for sub-setting files) now accepts a full file that covers the USA.

Is this the first code sharing on BeerLeg? If so, then I want a badge for it Wendell 🙂

(See next post... Indentation screwed up by posting.)

 
Posted : December 11, 2016 10:24 am
MarkSilver
(@mark-silver)
Posts: 714
Member
 

Uggh, looks like that messed up the indentation. I will attach a text file ...

Attached files

GSF_File.txt (2.7 KB) 

 
Posted : December 11, 2016 10:26 am
jhframe
(@jim-frame)
Posts: 7308
Member
 

Mark Silver, post: 403504, member: 1087 wrote: Is this the first code sharing on BeerLeg?

I think you're late to the party -- there have been many LISP routines posted in the past that would qualify.

Edit: Maybe not. I was thinking back to the older forums, and now am not sure any code has been posted here before. Yours may indeed be the first.

 
Posted : December 11, 2016 10:28 am

(@ncspiralguy)
Posts: 62
Member
Topic starter
 

If you have used that code to make a non-square file and it worked, it confirms what I thought.

If you're reading an ASCII file, why do you have this comment?

IKIND: longword; // had better be 1, if not we need to flip the endian of all values

I read the .bin file, trying one endianness and then the other. I check whether that value is less than 256, assuming that further values will be 2, 3, and a few more.

Attached files

gsf.txt (1.3 KB) 

 
Posted : December 11, 2016 10:55 am
MarkSilver
(@mark-silver)
Posts: 714
Member
 

Not sure, wrote it several years ago. It also does a few other things, I clipped that out of a big file. Also used for geo and a few other formats.

I know it works with the NGS geoid files and they are not all square.

 
Posted : December 11, 2016 4:43 pm