[mapserver-users] GRIB files - gdal_translate
Jose Roberto M. Garcia, MSc
roberto.garcia at cptec.inpe.br
Thu May 21 13:42:03 EDT 2009
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.garcia at 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.map&mode=map&layer=grib1
>> or
>> http://localhost/cgi-bin/mapserv.exe?map=/ms4w/apps/tutorial/htdocs/grib.map&mode=map&layer=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.000000000000000,-61.246000000000002)
>> >> Pixel Size = (0.938000000000000,-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.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
>> >
>> >
>> _______________________________________________
>> 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
More information about the mapserver-users
mailing list