<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi people,<br>
<br>
I used gdal_translate in the GRIB file I want to show with mapserver,
but there still is something wrong. The following is a partial output
from it:<br>
<br>
Driver: GRIB/GRIdded Binary (.grb)<br>
Files: data\raster\T126L28.grb<br>
Size is <font color="#ff0000"><b>161, 98</b></font><br>
Coordinate System is:<br>
.....<br>
Origin = (-150.000000000000000,-61.246000000000002)<br>
Pixel Size = (0.938000000000000,-0.001836734693878)<br>
Corner Coordinates:<br>
Upper Left (-150.0000000, -61.2460000) (150d 0'0.00"W, 61d14'45.60"S)<br>
Lower Left (-150.0000000, -61.4260000) (150d 0'0.00"W, 61d25'33.60"S)<br>
Upper Right ( 1.0180000, -61.2460000) ( 1d 1'4.80"E, 61d14'45.60"S)<br>
Lower Right ( 1.0180000, -61.4260000) ( 1d 1'4.80"E, 61d25'33.60"S)<br>
Center ( -74.4910000, -61.3360000) ( 74d29'27.60"W, 61d20'9.60"S)<br>
Band 1 Block=<font color="#ff0000"><b>161x1</b></font> Type=Float64,
ColorInterp=Undefined<br>
Description = 0[-] MSL (Mean sea level)<br>
Metadata:<br>
GRIB_UNIT=[Pa]<br>
GRIB_COMMENT=Pressure reduced to MSL [Pa]<br>
GRIB_ELEMENT=PRMSL<br>
GRIB_SHORT_NAME=0-MSL<br>
GRIB_REF_TIME= 1242453600 sec UTC<br>
GRIB_VALID_TIME= 1242453600 sec UTC<br>
GRIB_FORECAST_SECONDS=0 sec<br>
....<br>
<br>
As u can see the size according to the its header is 161x98, but all
the bands are related as 161x1 block. Why does it happen? Another thing
I noticed is that the dif between upper and lower latitude in the
corner coordinates is very small (-61.246 to -61.426).<br>
<br>
The issue is that, when mapserver renders this layer it only draws a
straight line below South America, exactly where the whole image should
start, as my CTL below shows.<br>
<br>
dset ^T126L28.grb<br>
title pac/sa/atlan sector: troposphere file<br>
undef 1e+20<br>
dtype grib<br>
index ^T126L28.gmp<br>
xdef 161 linear -150.000015 0.937500<br>
ydef 98 levels<br>
-61.246 -60.311 <br>
-59.376 -58.441 -57.506 -56.571 -55.636 -54.701 -53.766 -52.831 -51.896
-50.961 <br>
-50.026 -49.091 -48.156 -47.221 -46.286 -45.350 -44.415 -43.480 -42.545
-41.610 <br>
-40.675 -39.740 -38.805 -37.870 -36.935 -36.000 -35.065 -34.130 -33.195
-32.260 <br>
-31.325 -30.389 -29.454 -28.519 -27.584 -26.649 -25.714 -24.779 -23.844
-22.909 <br>
-21.974 -21.039 -20.104 -19.169 -18.234 -17.299 -16.364 -15.429 -14.493
-13.558 <br>
-12.623 -11.688 -10.753 -9.818 -8.883 -7.948 -7.013 -6.078
-5.143 -4.208 <br>
-3.273 -2.338 -1.403 -0.468 0.468 1.403 2.338 3.273
4.208 5.143 <br>
6.078 7.013 7.948 8.883 9.818 10.753 11.688 12.623
13.558 14.493 <br>
15.429 16.364 17.299 18.234 19.169 20.104 21.039 21.974
22.909 23.844 <br>
24.779 25.714 26.649 27.584 28.519 29.454 <br>
zdef 7 levels<br>
1000 925 850 700 500 300 200 ===> set Z 1 ou 2 ou 3 ... ou 7
(GRADS)<br>
tdef 1 linear 6Z16may2009 6hr<br>
vars 15<br>
psnm 0 2,102, 0, 0 SEA LEVEL PRESSURE [hPa]<br>
tsfc 0 187, 1, 0, 0 SURFACE TEMPERATURE [K]<br>
prec 0 61, 1, 0, 0 TOTAL PRECIPITATION [Kg/m2/day]<br>
cbnv 0 71, 3, 0, 0 CLOUD COVER [0-1]<br>
role 0 114, 8, 0, 0 OUTGOING LONG WAVE AT TOP [W/m2]<br>
mask 7 137,100 MASK [-/+]<br>
uvel 7 33,100 ZONAL WIND (U) [m/s]<br>
vvel 7 34,100 MERIDIONAL WIND (V) [m/s]<br>
omeg 7 39,100 OMEGA [Pa/s]<br>
fcor 7 35,100 STREAM FUNCTION [m2/s]<br>
potv 7 36,100 VELOCITY POTENTIAL [m2/s]<br>
zgeo 7 7,100 GEOPOTENTIAL HEIGHT [gpm]<br>
temp 7 11,100 ABSOLUTE TEMPERATURE [K]<br>
umrl 7 52,100 RELATIVE HUMIDITY [no Dim]<br>
umes 7 51,100 SPECIFIC HUMIDITY [kg/kg]<br>
endvars<br>
<br>
Can someone help me to find out what is happening?<br>
<br>
Tks a lot<br>
<br>
Roberto Garcia<br>
<br>
<br>
Frank Warmerdam wrote:
<blockquote cite="mid:4A0ACF89.3010004@pobox.com" type="cite">Roberto
Garcia,MSc wrote:
<br>
<blockquote type="cite">Hi, tks for the answers.
<br>
<br>
According to my gdainfo output file attached, can anyone tell me what
element could be a CLASSITEM?
<br>
</blockquote>
<br>
Roberto,
<br>
<br>
In MapServer you always classify rasters based on the item [pixel] but
<br>
you do not need to explicitly state a classitem.
<br>
<br>
This is a relatively simple example of raster classification.
<br>
<br>
LAYER
<br>
NAME grid1
<br>
TYPE raster
<br>
STATUS default
<br>
DATA data/float.tif
<br>
CLASS
<br>
NAME "red"
<br>
EXPRESSION ([pixel] < -3)
<br>
COLOR 255 0 0
<br>
END
<br>
CLASS
<br>
NAME "green"
<br>
EXPRESSION ([pixel] >= -3 and [pixel] < 3)
<br>
COLOR 0 255 0
<br>
END
<br>
CLASS
<br>
NAME "blue"
<br>
EXPRESSION ([pixel] >= 3)
<br>
COLOR 0 0 255
<br>
END
<br>
END
<br>
<br>
<blockquote type="cite">I can see my grib using Grads but what tool
do I use to translate individual bands into GeoTIFF?
<br>
</blockquote>
<br>
You can use gdal_translate to extract particular bands from a grib file
<br>
as a geotiff (or all the bands). For instance, the following would
<br>
extract band 3 (total precipitation):
<br>
<br>
gdal_translate -b 3 T126L28.grb total_precip.tif
<br>
<br>
<blockquote type="cite">Converting the data on-the-fly to an image is
the right way to work? </blockquote>
<br>
Having MapServer access the grib file on the fly rather than depending
<br>
on pre-translated extracts will reduce data duplication and may help
<br>
avoid confusion about what is up to date. However, it is possible that
<br>
there will be a performance penalty for extracting directly from GRIB.
<br>
If so, it may not be significant enough to matter to you.
<br>
<br>
<blockquote type="cite">What are the problems with Apache if I do not
do so?
<br>
</blockquote>
<br>
I don't see how either approach relates to Apache. It is a
<br>
data management and possibly performance issue with MapServer.
<br>
<br>
Best regards,
<br>
</blockquote>
</body>
</html>