GDAL fails to read AVHRR L1B GAC data prior to NOAA-15

[philes]

I am trying to use GDAL to read AVHRR L1B GAC data. The GDAL driver for AVHRR supposedly supports NOAA-9 through NOAA-17, but it appears to fail reading AVHRR files prior to NOAA-15 from our archive. For these files GDAL (for example when using gdalinfo, but it's the same error message when reading the data in Python) returns

ERROR 4: `NSS.GHRR.NH.D94001.S2246.E0034.B2717475.GC' not recognised as a supported file format. gdalinfo failed - unable to open 'NSS.GHRR.NH.D94001.S2246.E0034.B2717475.GC'.

The same files that cause trouble with GDAL can be read in other packages such as CoastWatch (​http://coastwatch.glerl.noaa.gov/software/software.html) or N1BX (​http://www.sat.dundee.ac.uk/programs/noaa1b/n1bx.c) without any problem, so the files should be in a standard format. Also, GDAL appears to work great with any files from NOAA-15 and later, so it doesn't seem to be an issue with my setup.

I will try to attach one of the problematic files to this ticket. I can also provide access to many more example files.

[Even Rouault]

I think you'll need to provide a problematic file, as in the autotest suite, we can read n12gac8bit.l1b successfully.

[philes]

Sorry, I wasn't able attach an example file to this ticket as it exceeded the maximum attachment size. I have now set up FTP access to some example AVHRR files that GDAL is unable to read:

​ftp://asterweb.jpl.nasa.gov/outgoing/phil/ExamplesAVHRR/ Login: aster PW: aster

[Even Rouault]

Reassigning to Andrey as the author of the L1B driver.

(I've been able to gdalopen the 2 *.WI files, but they are reported as SATELLITE=NOAA-15(K). The GCPs look (partly) wrong, the START and STOP time too. The other files are not recognized at all)

[warmerdam]

Andrey,

Do you anticipate having time to look into this problem? If not, I can reassign it to Chaitanya to try and come up with a solution.

[Markus Neteler]

We would be very interested to read these data. The current L1B driver fails to recognise the AVHRR L1B GAC file format.

Sample file "NSS.LHRR.NH.D90099.S1146.E1157.B0792727.GC" may be downloaded from:

​http://gis.cri.fmach.it/download/avhrr_sample/NSS.LHRR.NH.D90099.S1146.E1157.B0792727.GC

Format description:

• For data format descriptions for satellites prior to NOAA-15 (NOAA POD Guide): ​http://www.ncdc.noaa.gov/oa/pod-guide/ncdc/docs/podug/index.htm

From "vim" inspection, the current file format looks quite similar to the one implemented in the existing L1B driver.

See also (un)related patch in ticket #2403

[Even Rouault]

trunk (r25939) and branches/1.10 (r25940) "L1B: recognize NOAA-9/14 datasets whose dataset name in TBM header is encoded in EBCDIC and not in ASCII (#2848)"

[Markus Neteler]

Wonderful, Even! Now the file is recognized (except for the Coordinate System but maybe that's not defined):

[neteler@giscluster avhrr]$ gdalinfo NSS.LHRR.NH.D90099.S1146.E1157.B0792727.GC
Driver: L1B/NOAA Polar Orbiter Level 1b Data Set
Files: NSS.LHRR.NH.D90099.S1146.E1157.B0792727.GC
Size is 2048, 346
Coordinate System is `'
GCP Projection = 
GEOGCS["WGS 72",
    DATUM["WGS_1972",
        SPHEROID["WGS 72",6378135,298.26,
            AUTHORITY["EPSG","7043"]],
        TOWGS84[0,0,4.5,0,0,0.554,0.2263],
        AUTHORITY["EPSG","6322"]],
    PRIMEM["Greenwich",0,
        AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.0174532925199433,
        AUTHORITY["EPSG","9108"]],
    AUTHORITY["EPSG","4322"]]
GCP[  0]: Id=, Info=
          (2022.5,345.5) -> (42.4453125,48.078125,0)
GCP[  1]: Id=, Info=
          (1822.5,345.5) -> (34.9765625,47.90625,0)
...
GCP[218]: Id=, Info=
          (1662.5,-1701.5) -> (30.765625,50.8046875,0)
GCP[219]: Id=, Info=
          (22.5,-1701.5) -> (4.765625,45.359375,0)
Metadata:
  DATA_TYPE=AVHRR LAC
  DATASET_NAME=NSS.LHRR.NH.D90099.S1146.E1157.B0792727.GC
  LOCATION=Ascending
  PROCESSING_CENTER=NOAA/NESDIS - Suitland, Maryland, USA
  REVOLUTION=07927
  SATELLITE=NOAA-11(H)
  SOURCE=Fairbanks, Alaska, USA (formerly Gilmore Creek)
  START=year: 1990, day: 99, millisecond: 42520262
  STOP=year: 1990, day: 99, millisecond: 42577762
Corner Coordinates:
Upper Left  (    0.0,    0.0)
Lower Left  (    0.0,  346.0)
Upper Right ( 2048.0,    0.0)
Lower Right ( 2048.0,  346.0)
Center      ( 1024.0,  173.0)
Band 1 Block=2048x1 Type=UInt16, ColorInterp=Undefined
  Description = AVHRR Channel 1:  0.58  micrometers -- 0.68 micrometers
Band 2 Block=2048x1 Type=UInt16, ColorInterp=Undefined
  Description = AVHRR Channel 2:  0.725 micrometers -- 1.10 micrometers
Band 3 Block=2048x1 Type=UInt16, ColorInterp=Undefined
  Description = AVHRR Channel 3:  3.55  micrometers -- 3.93 micrometers
Band 4 Block=2048x1 Type=UInt16, ColorInterp=Undefined
  Description = AVHRR Channel 4:  10.3  micrometers -- 11.3 micrometers
Band 5 Block=2048x1 Type=UInt16, ColorInterp=Undefined
  Description = AVHRR Channel 5:  11.5  micrometers -- 12.5 micrometers

However, decades of data become usable now.

[Even Rouault]

The L1B driver only handles GCP, so exposes the GCP projection only, and it is hard-coded to WGS72

[Even Rouault]

Closing assuming this has been addressed by "recent" work in the L1B driver