[mapserver-users] GRIB files - gdal_translate

Thu May 21 08:34:56 EDT 2009

I opened the tif file I've extracted form it in QGIS and it looked like 
the same thing, a line. What do I need to do to manipulate this as a 
tiled/blocked data so? I want both things: make mapserver renders direct 
from the GRIB file and either create GeoTiff files from them using 
gdal_translate, by this time.

Tks a lot

Ivan wrote:
> Hi there!
>
> There is nothing wrong with your block X and Y size (161x1). It 
> indicates that your data is not tiled/blocked, so it is most likely to 
> be read row by row. If the image looks strange is not because of that. 
> You have 98 rows in 0.02 degrees, so if it looks like a line, I 
> wouldn't be suprised. Have you try to open it in another GDAL based 
> client application, like QGIS for example?
>
> Regards,
>
> Ivan
>
> Roberto Garcia,MSc wrote:
>> Hi people,
>>
>> 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:
>>
>> Driver: GRIB/GRIdded Binary (.grb)
>> Files: data\raster\T126L28.grb
>> Size is *161, 98*
>> Coordinate System is:
>> .....
>> Origin = (-150.000000000000000,-61.246000000000002)
>> Pixel Size = (0.938000000000000,-0.001836734693878)
>> Corner Coordinates:
>> Upper Left  (-150.0000000, -61.2460000) (150d 0'0.00"W, 61d14'45.60"S)
>> Lower Left  (-150.0000000, -61.4260000) (150d 0'0.00"W, 61d25'33.60"S)
>> Upper Right (   1.0180000, -61.2460000) (  1d 1'4.80"E, 61d14'45.60"S)
>> Lower Right (   1.0180000, -61.4260000) (  1d 1'4.80"E, 61d25'33.60"S)
>> Center      ( -74.4910000, -61.3360000) ( 74d29'27.60"W, 61d20'9.60"S)
>> Band 1 Block=*161x1* Type=Float64, ColorInterp=Undefined
>>   Description = 0[-] MSL (Mean sea level)
>>   Metadata:
>>     GRIB_UNIT=[Pa]
>>     GRIB_COMMENT=Pressure reduced to MSL [Pa]
>>     GRIB_ELEMENT=PRMSL
>>     GRIB_SHORT_NAME=0-MSL
>>     GRIB_REF_TIME=  1242453600 sec UTC
>>     GRIB_VALID_TIME=  1242453600 sec UTC
>>     GRIB_FORECAST_SECONDS=0 sec
>> ....
>>
>> 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).
>>
>> 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.
>>
>> dset ^T126L28.grb
>> title pac/sa/atlan sector: troposphere file
>> undef 1e+20
>> dtype grib
>> index ^T126L28.gmp
>> xdef 161 linear -150.000015 0.937500
>> ydef 98 levels
>> -61.246 -60.311
>> -59.376 -58.441 -57.506 -56.571 -55.636 -54.701 -53.766 -52.831 
>> -51.896 -50.961
>> -50.026 -49.091 -48.156 -47.221 -46.286 -45.350 -44.415 -43.480 
>> -42.545 -41.610
>> -40.675 -39.740 -38.805 -37.870 -36.935 -36.000 -35.065 -34.130 
>> -33.195 -32.260
>> -31.325 -30.389 -29.454 -28.519 -27.584 -26.649 -25.714 -24.779 
>> -23.844 -22.909
>> -21.974 -21.039 -20.104 -19.169 -18.234 -17.299 -16.364 -15.429 
>> -14.493 -13.558
>> -12.623 -11.688 -10.753  -9.818  -8.883  -7.948  -7.013  -6.078  
>> -5.143  -4.208
>>  -3.273  -2.338  -1.403  -0.468   0.468   1.403   2.338   3.273   
>> 4.208   5.143
>>   6.078   7.013   7.948   8.883   9.818  10.753  11.688  12.623  
>> 13.558  14.493
>>  15.429  16.364  17.299  18.234  19.169  20.104  21.039  21.974  
>> 22.909  23.844
>>  24.779  25.714  26.649  27.584  28.519  29.454
>> zdef 7 levels
>> 1000 925 850 700 500 300 200   ===> set Z 1 ou 2 ou 3 ... ou 7 (GRADS)
>> tdef 1 linear 6Z16may2009  6hr
>> vars 15
>> psnm      0    2,102,  0,  0 SEA LEVEL PRESSURE [hPa]
>> tsfc      0  187,  1,  0,  0 SURFACE TEMPERATURE [K]
>> prec      0   61,  1,  0,  0 TOTAL PRECIPITATION [Kg/m2/day]
>> cbnv      0   71,  3,  0,  0 CLOUD COVER [0-1]
>> role      0  114,  8,  0,  0 OUTGOING LONG WAVE AT TOP [W/m2]
>> mask      7  137,100 MASK [-/+]
>> uvel      7   33,100 ZONAL WIND (U) [m/s]
>> vvel      7   34,100 MERIDIONAL WIND (V) [m/s]
>> omeg      7   39,100 OMEGA [Pa/s]
>> fcor      7   35,100 STREAM FUNCTION [m2/s]
>> potv      7   36,100 VELOCITY POTENTIAL [m2/s]
>> zgeo      7    7,100 GEOPOTENTIAL HEIGHT [gpm]
>> temp      7   11,100 ABSOLUTE TEMPERATURE [K]
>> umrl      7   52,100 RELATIVE HUMIDITY [no Dim]
>> umes      7   51,100 SPECIFIC HUMIDITY [kg/kg]
>> endvars
>>
>> Can someone help me to find out what is happening?
>>
>> Tks a lot
>>
>> Roberto Garcia
>>
>>
>> Frank Warmerdam wrote:
>>> Roberto Garcia,MSc wrote:
>>>> Hi, tks for the answers.
>>>>
>>>> According to my gdainfo output file attached, can anyone tell me 
>>>> what element could be a CLASSITEM?
>>>
>>> Roberto,
>>>
>>> In MapServer you always classify rasters based on the item [pixel] but
>>> you do not need to explicitly state a classitem.
>>>
>>> This is a relatively simple example of raster classification.
>>>
>>> LAYER
>>>   NAME grid1
>>>   TYPE raster
>>>   STATUS default
>>>   DATA data/float.tif
>>>   CLASS
>>>     NAME "red"
>>>     EXPRESSION ([pixel] < -3)
>>>     COLOR 255 0 0
>>>   END
>>>   CLASS
>>>     NAME "green"
>>>     EXPRESSION ([pixel] >= -3 and [pixel] < 3)
>>>     COLOR 0 255 0
>>>   END
>>>   CLASS
>>>     NAME "blue"
>>>     EXPRESSION ([pixel] >= 3)
>>>     COLOR 0 0 255
>>>   END
>>> END
>>>
>>>> I can see my grib using Grads but what tool do I use to translate 
>>>> individual bands into GeoTIFF?
>>>
>>> You can use gdal_translate to extract particular bands from a grib file
>>> as a geotiff (or all the bands).  For instance, the following would
>>> extract band 3 (total precipitation):
>>>
>>> gdal_translate -b 3 T126L28.grb total_precip.tif
>>>
>>>> Converting the data on-the-fly to an image is the right way to work? 
>>>
>>> Having MapServer access the grib file on the fly rather than depending
>>> on pre-translated extracts will reduce data duplication and may help
>>> avoid confusion about what is up to date.  However, it is possible that
>>> there will be a performance penalty for extracting directly from GRIB.
>>> If so, it may not be significant enough to matter to you.
>>>
>>>> What are the problems with Apache if I do not do so?
>>>
>>> I don't see how either approach relates to Apache.  It is a
>>> data management and possibly performance issue with MapServer.
>>>
>>> Best regards,
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> mapserver-users mailing list
>> mapserver-users at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>

Jose Roberto M. Garcia, Msc
Grupo Banco de Dados / CPTEC / INPE
Fone: (12) 3186-8405
-- 
A luta contra o aquecimento global depende de cada um de nós, faça sua parte, economize recursos naturais.
-- 
http://www.cptec.inpe.br 
http://www.inpe.br 