[mapserver-users] GRIB files - gdal_translate
Ivan
ivan.lucena at pmldnet.com
Wed May 20 17:46:27 EDT 2009
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
More information about the mapserver-users
mailing list