Geostationary Meteorological Satellite (GMS)

Information updated on January 4, 2010, 9:49 pm GMT


General Data Description

GMS-5 was part of a series of Japanese geostationary satellites stationed over the Western Pacific (140°E) from 1995-03 through 2003-05-21. It carried a Visible and Infrared Spin Scan Radiometer (VISSR) similar to the NOAA GOES satellites. After its failure in 2003 it was temporarily replaced by GOES-9 on loan from the US and then the MTSAT series. It's primary measurements are cloud images in 1 visible and 3 infrared bands.

Expand All Collapse All

Data Stream Names

Measurement Description

twpgms5X1.a1.yymmdd.hhmmss.hdf

Data measured by the Visible and Infrared Spin Scan Radiometer (VISSR) with four channels, one in the visible part of the spectrum and three in the infrared. The ground resolution at the subsatellite point is 1.25 km in the visible channel and 5 km in the infrared. Some details of the GMS-5 satellite can be found at http://www.jaxa.jp/projects/sat/gms/index_e.html

The visible channel is averaged from 1.25 km to 5 km.
Resolution (IR & Vis)      = 5.00 km 
Image dimensions(IR)       = 677 lines x 1114 pixels 
Projection                 = Mercator 
Availability               = approximately hourly 
GMS 5 images  Variable  Wavelength Type  Units  Scale  Offset 
1)  Visible channel 'albedo'   svissr_vis  0.75 um   byte  albedo*100%   0.3   0
2)  Brightness temperature  svissr_ir1  10.8 um   byte  temp_deg_c  0.5 188.15
3)  Brightness temperature  svissr_ir2   11.5 um  byte  temp_deg_c  0.5 188.15
4)  Brightness temperature   svissr_ir3  6.9 um  byte  temp_deg_c  0.5 188.15
5)  satellite-solar azimuth angle  rel_azimuth  n/a   float   degrees  1  0
6)  satellite zenith angle  sat_zenith  n/a   float   degrees  1  0
6)  solar zenith angle  sun_zenith  n/a   float   degrees  1  0

Temporal Coverage

GMS data are available beginning in October 1996 until the satellite failed on 2003-05-21.

The Minnis products are available as follows:
twplbtm3minnisX1.c1 begin 1998-01-03
twplbtm3minnismanX1.c1 and twplbtm3minnisnauX1.c1 begin 1999-06-16
twplbtm3minnisdarX1.c1 begin 2002-04-01
All these data streams end on 2003-05-21.

Area Covered

The GMS-5 satellite was stationed over 140°E longitude. A subset in sensor scan coordinates was extracted over the TWP domain (centered over 155°E, 00°N, extending roughly from 130°E to 180°E and 10°S to 10°N) and mapped onto a mercator projection from 130°E to 180°E and 15°S to 15°N which resulted in approximately 5° latitude bands to the North and South of the domain with no data (fill value).

Note: the latitude and longitude variables are not included in the output data-stream files but rather provided separately here:
twpgms5lat-lonX1.00.hdf

For your convenience there are several overlays prepared for lat/lon grids, and coastlines. The overlay files consist of an 'image' of value 1 everywhere, except at the positions of the features (coastlines) in which case the pixel value is zero. Thus the overlays can be written into the image by multiplying them together; the image data remain unchanged and the overlain pixels become zero.

twpgms5coastX1.hdf Overlay of coastlines
twpgms5grid1x1X1.hdf Overlay of 1 x 1 lat lon grid
twpgms5grid5x5X1.hdf Overlay of 5 x 5 lat lon grid
These files can be found in the ARM Archive

Data Stream Inputs

twpgms5fullX1.00.yymmdd.hhmmss.raw.g5.yyjjj.hhmm

Notification Form Link

Contacts

FAQ

Q: I would like to have some informations about the HDF formatting of twpgms5X1.a1 data. I have had problems reading the VIS and IR data of these files with the software PCI-GEOMATICS. Customer service of PCI wrote me: "The problem with the HDF file you reported is that the data is 8 bit signed and we only support 8U, 16S, 16U, and 32R." I read the GMS data as 8 bit unsigned (0-255) so could it be possible that they are 8 bit signed?
A: You have uncovered a bug in the processing software that we use to generate the hdf file. The HDF data type for the infrared and visible imagery is written as "20" (8-bit integer type) whereas it should be "21" (8-bit unsigned integer type).When using Terascan or IDL, the data are read cleanly and the scaling can be correctly applied, but in NoESYS the data are indeed read as signed bytes. A problem notice has been filed with the supplier of the software but in the meantime the following solutions are offered.
  1. If you have TeraScan, use this to read in the data file (reformat using hdftotdf first) and do the analysis in TeraScan, or export the images you need as binary 'flat files' that can be read by most image processing or GIS systems.
  2. If you have IDL use this to read the data and do the analysis in IDL or write binary files. (Peter Minnett has tested this and can send you a simple program to do this if you wish)
  3. If you have Matlab, proceed as in (b) [Peter Minnett has not tested this]
  4. If you do not have access to the licenced software in (a) (b) or (c), you can use 'hdp' to extract the data from the hdf file. This software is available from http://www.hdfgroup.com/products/hdf4_tools/ and an example usage is given towards the bottom of http://www.arm.gov/data/files. Use the following unix command to extract the 'svissr_ir1' image as a simple binary file called 'ir1.bin' from the hdf file 'twpgms5X1.a1.970307.083100.hdf': hdp dumpsds -n svissr_ir1 -d -o ir1.bin -b twpgms5X1.a1.970307.083100.hdf The resulting file is a byte array of dimensions [1114, 677]. This file should be readable by most GIS or image processing software.
Q: What is the relation that I have to use to calibrate the twpgms5X1.a1 data?
A: Once you have read the data as a byte array (0 to 255) the scaling of the visible channel to get 'albedo' as a %, multiply the numbers in the array by 0.3

For the infrared images, multiply the numbers by 0.5 and add 188.15 to get brightness temperature in K.

Q: When I try to download the lat/lon files for the GMS data, I get absurd values (~10^38) for the lat/lon.
A: These values are _FillValue and should be ignored. See section Area Covered for an explanation.

Data User Notes

Note A - there is a known bug in earlier versions of tdftohdf which gives the incorrect data type code, 20, unsigned short integers, instead of 21, for signed short integers. If you use this information in converting the values read from the files to geophysical units, the answer may be wrong as the sign bit is misinterpreted. This affects most of the data currently available through the ARM Archive. Use of the information given in the HDF file header (metadata)  gives the correct values.

E.g.: In matlab manually change the output SDS type to uint8 (unsigned 8-bit integer).

Example Data

twpgms5coastX1 image Overlay of coastlines 
twpgms5grid1x1X1 image Overlay of 1x1 km grid 
twpgms5grid5x5X1 image Overlay of 5x5 km grid 
twpgms5lat-lonX1 latitude image
twpgms5lat-lonX1 longitude image
Images with latitude and longitude of each pixel 

Note: overlay files contain an image that can be overlayed on a gms5 image by multiplying the overlay file and the image file

Acronyms

GMS	Geostationary Meteorological Satellite
HDF	Hierarchical Data Format
TDF	Terascan Data Format
TWP 	Tropical Western Pacific
VISSR	Visible and Infrared Spin Scan Radiometer 

Citable References

The normalized spectral response functions can be seen at http://isccp.giss.nasa.gov/docs/response/gms-5s.html (ch1) and http://isccp.giss.nasa.gov/docs/response/gms-5i.html (chs 2-4).