Re: [mapserver-users] GRIB files - gdal_translate
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.000,-61.2460002) Pixel Size = (0.938,-0.001836734693878) Corner Coordinates: Upper Left (-150.000, -61.246) (150d 0'0.00W, 61d14'45.60S) Lower Left (-150.000, -61.426) (150d 0'0.00W, 61d25'33.60S) Upper Right ( 1.018, -61.246) ( 1d 1'4.80E, 61d14'45.60S) Lower Right ( 1.018, -61.426) ( 1d 1'4.80E, 61d25'33.60S) Center ( -74.491, -61.336) ( 74d29'27.60W, 61d20'9.60S) 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.15 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 02,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 77,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
Re: [mapserver-users] GRIB files - gdal_translate
Roberto Garcia,MSc wrote: Size is *161, 98* Coordinate System is: . Origin = (-150.000,-61.2460002) Pixel Size = (0.938,-0.001836734693878) ... Band 1 Block=*161x1* Type=Float64, ColorInterp=Undefined 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? Roberto, This means that the file (and bands) are 161x98, but the bands are subdivided into blocks which are 161x1 implying that the natural access chunk is a scanline. This is normal. 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). This appears to be screwed up. Perhaps you could provide the file, and file a ticket about this? 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. What is CTL? PS. this would likely be better addressed on gdal-dev. Any ticket should be filed in the GDAL Trac. http://trac.osgeo.org/gdal/ Best regards, dset ^T126L28.grb title pac/sa/atlan sector: troposphere file undef 1e+20 dtype grib index ^T126L28.gmp xdef 161 linear -150.15 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 02,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 77,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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users -- ---+-- I set the clouds in motion -
Re: [mapserver-users] GRIB files - gdal_translate
Hi Frank, tks for the answer. CTL is an ASCII file that follows Grib files (at least here) and informs the metadata of the Grib file. If anyone consider helping me my data is available by ftp in ftp1.cptec.inpe.br inside bdados folder, as my map file is. I access them with http://localhost/cgi-bin/mapserv.exe?map=/ms4w/apps/tutorial/htdocs/grib.mapmode=maplayer=grib1 or http://localhost/cgi-bin/mapserv.exe?map=/ms4w/apps/tutorial/htdocs/grib.mapmode=maplayer=tif1 And the results are almost the same (the diff is the color), a line below S.A. Tks Frank Warmerdam wrote: Roberto Garcia,MSc wrote: Size is *161, 98* Coordinate System is: . Origin = (-150.000,-61.2460002) Pixel Size = (0.938,-0.001836734693878) ... Band 1 Block=*161x1* Type=Float64, ColorInterp=Undefined 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? Roberto, This means that the file (and bands) are 161x98, but the bands are subdivided into blocks which are 161x1 implying that the natural access chunk is a scanline. This is normal. 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). This appears to be screwed up. Perhaps you could provide the file, and file a ticket about this? 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. What is CTL? PS. this would likely be better addressed on gdal-dev. Any ticket should be filed in the GDAL Trac. http://trac.osgeo.org/gdal/ Best regards, dset ^T126L28.grb title pac/sa/atlan sector: troposphere file undef 1e+20 dtype grib index ^T126L28.gmp xdef 161 linear -150.15 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 02,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 77,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
Re: [mapserver-users] GRIB files - gdal_translate
Tks people, yes I can wait, for sure. I can send the files to your particular email if u prefer, it's about 3 MB. or at ftp1.cptec.inpe.br (login=anonymous, pwd=some email) (passive mode) once there, go to bdados folder. Tks Lucena, Ivan wrote: Roberto, I can take a look at that tonight if you are not in a hurry. Ivan ---Original Message--- From: Roberto Garcia,MSc roberto.gar...@cptec.inpe.br Subject: Re: [mapserver-users] GRIB files - gdal_translate Sent: May 21 '09 09:16 Hi Frank, tks for the answer. CTL is an ASCII file that follows Grib files (at least here) and informs the metadata of the Grib file. If anyone consider helping me my data is available by ftp in ftp1.cptec.inpe.br inside bdados folder, as my map file is. I access them with http://localhost/cgi-bin/mapserv.exe?map=/ms4w/apps/tutorial/htdocs/grib.mapmode=maplayer=grib1 or http://localhost/cgi-bin/mapserv.exe?map=/ms4w/apps/tutorial/htdocs/grib.mapmode=maplayer=tif1 And the results are almost the same (the diff is the color), a line below S.A. Tks Frank Warmerdam wrote: Roberto Garcia,MSc wrote: Size is *161, 98* Coordinate System is: . Origin = (-150.000,-61.2460002) Pixel Size = (0.938,-0.001836734693878) ... Band 1 Block=*161x1* Type=Float64, ColorInterp=Undefined 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? Roberto, This means that the file (and bands) are 161x98, but the bands are subdivided into blocks which are 161x1 implying that the natural access chunk is a scanline. This is normal. 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). This appears to be screwed up. Perhaps you could provide the file, and file a ticket about this? 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. What is CTL? PS. this would likely be better addressed on gdal-dev. Any ticket should be filed in the GDAL Trac. http://trac.osgeo.org/gdal/ Best regards, dset ^T126L28.grb title pac/sa/atlan sector: troposphere file undef 1e+20 dtype grib index ^T126L28.gmp xdef 161 linear -150.15 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 02,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 77,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
Re: [mapserver-users] GRIB files - gdal_translate
Olá Roberto, The file T126L28.ctl gives up the clue: -- xdef 161 linear *-150.15* *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 -- Whatever ydef 98 levels means, it looks like there is one Y ordinate for each one of the 98 rows. So your upper left and lower right values are in fact -150.0 -61.246 0.9375 29.454. I create a VRT file based on that: $ gdal_translate -of VRT T126L28.grb T126L28.vrt -a_ullr -150.0 -61.246 0.9375 29.454 And I opened it on QGIS and the image looks pretty good to me. See attachment. Since you don't want to convert the data to other format you can create VRTs and use then instead. DATA c:/ms4w/data/raster/T126L28.vrt Does it make sense? PT_BR: Revisando: Eu interpretei o arquivo .ctl, achei a extensao da imagem e criei arquivos vrt passando estes parametros. Agora quando eu abro o arquivo vrt os dados continuam sendo lidos do .grb mas com a descricao do vrt. Tente fazer o mesmo pra ver se resolve pra voce. (eu estudei no INPE :) Regards, Ivan inline: screenshot.png___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
[mapserver-users] GRIB files - gdal_translate
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.000,-61.2460002) Pixel Size = (0.938,-0.001836734693878) Corner Coordinates: Upper Left (-150.000, -61.246) (150d 0'0.00W, 61d14'45.60S) Lower Left (-150.000, -61.426) (150d 0'0.00W, 61d25'33.60S) Upper Right ( 1.018, -61.246) ( 1d 1'4.80E, 61d14'45.60S) Lower Right ( 1.018, -61.426) ( 1d 1'4.80E, 61d25'33.60S) Center ( -74.491, -61.336) ( 74d29'27.60W, 61d20'9.60S) 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.15 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 02,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 77,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
Re: [mapserver-users] GRIB files - gdal_translate
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.000,-61.2460002) Pixel Size = (0.938,-0.001836734693878) Corner Coordinates: Upper Left (-150.000, -61.246) (150d 0'0.00W, 61d14'45.60S) Lower Left (-150.000, -61.426) (150d 0'0.00W, 61d25'33.60S) Upper Right ( 1.018, -61.246) ( 1d 1'4.80E, 61d14'45.60S) Lower Right ( 1.018, -61.426) ( 1d 1'4.80E, 61d25'33.60S) Center ( -74.491, -61.336) ( 74d29'27.60W, 61d20'9.60S) 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.15 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 02,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 77,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
