<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
Hello,<br>
<br>
I am happy that you were able to build GDAL with the GRIB driver and
try it. I also thank you for the feedback, which I will use to improve
the driver.<br>
<br>
You are right, the choice for "metric" is accidentally fixed in the
driver (in case you are interested, this is in file gribdataset.cpp,
function GRIBRasterBand::ReadGribData, you will find a line with "sChar
f_unit = 2; /* None = 0, English = 1,
Metric = 2 */").<br>
Consider that it was quite a headache to integrate degrib with GDAL,
and I was so happy to get it to work after a huge effort, that I forgot
that this was left hardcoded.<br>
I guess this could be offered as an option to the user (e.g. with a
command-line parameter for gdal_translate and gdalwarp).<br>
<br>
To check what happens with the image's description and the
georeferencing, I downloaded the image gfs.2008011612/gfs.t12.pgrb2f00.<br>
<br>
Description:<br>
Band 2 of this image contains the following metadata that could be used
in a description:<br>
- msgNum = 2<br>
- subgNum = 0<br>
- refTime = 1200484800.0000000<br>
- validTime = 1200484800.0000000<br>
- element = "TMP"<br>
- comment = "Temperature [K]"<br>
- unitName = "[K]"<br>
- foreSec = 0.00000000000000000<br>
- shortFstLevel = "1000-ISBL"<br>
- longFstLevel = "1000[Pa] ISBL="Isobaric surface""<br>
When I was implementing the GDAL-GRIB driver (a year ago), I had
checked those fields in all GRIB images available to me at that time,
and concluded that longFstLevel was sufficient. With your images it
makes sense to compose a combination of these fields (note that GDAL
only has place for one description string).<br>
This also goes for bands 8 and 9: For both bands, msgNum = 8, but
subgNum = 0,1. This can be incorporated in the description, but for
GDAL they will remain separate bands.<br>
<br>
Georeferencing:<br>
This image contains (among others) the following info in the metadata:<br>
- Scan direction = GRIB2BIT_2 (meaning from south to north)<br>
- (lat1,lon1) = (90,0) .. considering the scan direction, this is the
lower-left point<br>
- (lat2,lon2) = (-90,359.5) .. this is the upper-right point of the
image<br>
Well, I was not happy with this, as it differs from all images I tried
til now. At first sight I would conclude that the image is upside-down.
Only by opening a band I can see that it is straight-up, and that the
lower-left corner must be assigned (lat,lon)=(-90,0). The image
contains the whole world, with the greenwich meridian on the left.<br>
To solve this, I must add some intelligence to the code that passes the
georeferencing parameters to GDAL (file gribdataset.cpp, function
GRIBDataset::SetMetaData). However, I wish I had some documentation of
the GRIB format, as I am not sure if I can simply "sort" the corner
coordinates of the image (why is the scan direction given?).<br>
For now, you can force gdal_translate to assign the correct
georeference to the image during import, by adding a parameter: -a_ullr
0 90 360 -90 . Unless your GIS expects longitudes to be between -180
and 180, this will solve the problem.<br>
<br>
When I find some time, I will implement above improvements (user's
choice of unit, better description, and more robust georeferencing).
But if you have some experience in C++, feel free to assist.<br>
<br>
Cheers,<br>
<br>
Bas.<br>
<br>
<pre class="moz-signature" cols="72">-- 
Ir. V. (Bas) Retsios
Software Developer
Geo-information Processing Department
International Institute for Geo-information Science and Earth Observation (ITC)
P.O. Box 6,  7500 AA Enschede, The Netherlands
Phone +31 (0)53 4874 573, telefax +31 (0)53 4874 335
E-mail <a
 class="moz-txt-link-abbreviated" href="mailto:retsios@itc.nl">retsios@itc.nl</a>, Internet <a
 class="moz-txt-link-freetext" href="http://www.itc.nl">http://www.itc.nl</a>
</pre>
<br>
<br>
<br>
<br>
winkey wrote:<br>
<blockquote type="cite" cite="mid1200349886.23033.42.camel@winkey.org">
  <pre wrap="">After trying a second time I finally got the grib driver to work for me.

the grib file i am testing with is the gfs forecast model .5 degree
global grid available from
<a class="moz-txt-link-freetext"
 href="http://www.ftp.ncep.noaa.gov/data/nccf/com/gfs/prod/gfs.2008011412/gfs.t12z.pgrb2f00">http://www.ftp.ncep.noaa.gov/data/nccf/com/gfs/prod/gfs.2008011412/gfs.t12z.pgrb2f00</a>

replace 2008011412 with current date, last 2 digits are hour 00, 06, 12,
18

this is a list of my experiences.

first with gdalinfo I noticed that not enough info was reported to
choose the band(s) you want

degrib reports:
 2.0, 158408, 2, TMP="Temperature [K]", 1000-ISBL, 11/05/2007 00:00,
11/05/2007 00:00, 0.00

gdalinfo reports:
Band 2 Block=720x1 Type=Float64, ColorInterp=Undefined
  Description = 1000[Pa] ISBL="Isobaric surface"


There seems to be no way to specify the units. degrib has a feature to
convert the values in the grid to english or metric units. For instance
in the band above default would have the values in kelvin, specifying
english would convert those values to Fahrenheit, and metric would
convert to celsius.


Two part messages seem to be represented by two different bands. This is
not necessarily a problem but without the variable name being reported
by gdalinfo it is hard to find what your looking for.

degrib reports:
8.0, 901490, 2, UGRD="u-component of wind [m/s]", 2000-ISBL, 11/05/2007
00:00, 11/05/2007 00:00, 0.00
8.1, 901490, 2, VGRD="v-component of wind [m/s]", 2000-ISBL, 11/05/2007
00:00, 11/05/2007 00:00, 0.00

gdalinfo reports:
Band 8 Block=720x1 Type=Float64, ColorInterp=Undefined
  Description = 2000[Pa] ISBL="Isobaric surface"
Band 9 Block=720x1 Type=Float64, ColorInterp=Undefined
  Description = 2000[Pa] ISBL="Isobaric surface"


I tried contouring band 169 (aka grib msg 147) 925 mb temps it seemed to
contour only the northern hemisphere and nothing seemed in the right
place. once again I may have the wrong band, but that would not effect
hemisphere only the contours


thanks

brian



_______________________________________________
gdal-dev mailing list
<a class="moz-txt-link-abbreviated"
 href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
<a class="moz-txt-link-freetext"
 href="http://lists.osgeo.org/mailman/listinfo/gdal-dev">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
  </pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72"></pre>
</body>
</html>