[GRASS-user] TRMM (3B43) handling
Daniel Victoria
daniel.victoria at gmail.com
Sat Nov 20 11:59:31 EST 2010
Sorry for barging in, don't know much about 3b43 product but I'm
beginning to look at the daily 3b42 and I believe the data format
might be the same.
>From their FAQ [1], the lat/long for the hdf and binary files are
different. The binary files are set up to be read in GrADS and that
software stores binary files from south to north. So, as the FAQ
states, the first coordinate in the bin file is (-49.875,-179.875),
the second is (-49.875,-179.625).
I've run into this problem before (Importing upside down GrADS binary
data into GRASS) and my solution was to flip the binary file prior to
running r.in.bin. So I wrote a quick python code to flip the bin file.
The attached python script (vira_mapa.py) should take care of the job.
All you need to do is edit the file and input the number of lines
(nlin) and columns (ncol). To run the program just do ./vira_mapa.py
binary_file_name. It will output the flipped map in a file named
mapa_virado.bin.
Hope it helps
Cheers
Daniel
-------------------------------------------------------------------------
[1] - http://disc.sci.gsfc.nasa.gov/additional/faq/precipitation_faq.shtml#lat_lon
For TRMM 3B43, 3B42, it seems there are two datasets (HDF and binary)
with different latitude, longitude arrangements. Is this true? Which
one should I use?
Yes and both are arranged differently. The HDF is the standard TRMM
archive format and data are written in the following order, (-49.875,
-179.875), (-49.625, -179.875), (-49.375, -179.875)...... The binary
are written for GrADS (a free popular software used in climate and
weather communities) and in (-49.875,-179.875), (-49.875,-179.625),
(-49.875,-179.375°W)...... Apparently if you are a GrADS user, you
should use the binary. Otherwise, there is a list of software in
http://disc.sci.gsfc.nasa.gov/precipitation/additional/tools
On Fri, Nov 19, 2010 at 10:49 AM, Markus Neteler <neteler at osgeo.org> wrote:
> On Fri, Nov 19, 2010 at 8:40 AM, Markus Metz
> <markus.metz.giswork at googlemail.com> wrote:
>> nikos ves wrote:
>>> On Wed, 2010-11-17 at 10:08 +0100, Markus Metz wrote:
>>>> Another option:
>>>> get binary grids from here
>>>> ftp://disc2.nascom.nasa.gov/data/TRMM/Gridded/3B43_V6/
>>>> read
>>>> ftp://disc2.nascom.nasa.gov/data/TRMM/Gridded/3B43_V6/3B43.ctl
>>>>
>>>> import into a latlon location with r.in.bin -f -b north=50 south=-50
>>>> east=180 west=-180 rows=400 cols=1440, e.g.
>>>> r.in.bin -f -b input=3B43.100101.6.precipitation.bin
>>>> output=3B43.100101.6.precipitation north=50 south=-50 east=180
>>>> west=-180 rows=400 cols=1440
>>>
>>> i was comparing the output rasters with a png [1] a same period.
>>> eg Jul_2006. it seems that in the bin [2] file N is S and vise versa.
>>> The phenomenon can be seen clearly by comparing the western coast of
>>> India between [1] and [2]
>>>
>>> I don't think I'm doing something wrong, but can anyone cross check just
>>> to be sure I didn't anything stupid on my side?
>>>
>>
>> Confirmed, that's maybe the reason why these binary grids are well hidden.
>>
>> Looks like there is no way around setting GCPs and using i.rectify,
>> either with these binary grids or with the hdf dumps.
>
> how about flipping it with GDAL VRT and gdalwarp? Below I cite an older
> email from the GDAL list with a similar problem + solution.
>
> Markus
>
> PS: From gdal mailing list:
>
> On Fri, Jan 16, 2009 at 9:52 PM, Frank Warmerdam wrote:
>> Greg Ederer wrote:
>>>
>>> Hi,
>>>
>>> I'm running gdal_translate against a VRT file:
>>>
>>> <VRTDataset rasterXSize="751" rasterYSize="801">
>>> <GeoTransform>-20.05, 0.1, 0.0, 40.05, 0.0, -0.1</GeoTransform>
>>> <SRS>
>>> GEOGCS["WGS 84",
>>> DATUM["WGS_1984",
>>> SPHEROID["WGS 84",6378137,298.2572235630016,
>>> AUTHORITY["EPSG","7030"]],
>>> AUTHORITY["EPSG","6326"]],
>>> PRIMEM["Greenwich",0],
>>> UNIT["degree",0.0174532925199433],
>>> AUTHORITY["EPSG","4326"]]
>>> </SRS>
>>> <VRTRasterBand dataType="Float32" band="1" subClass="VRTRawRasterBand">
>>> <SourceFilename relativetoVRT="1">10day_precip.bin.1999121</SourceFilename>
>>> <ImageOffset>0</ImageOffset>
>>> <PixelOffset>4</PixelOffset>
>>> <LineOffset>3004</LineOffset>
>>> <ByteOrder>MSB</ByteOrder>
>>> <NoDataValue>-999.0</NoDataValue>
>>> </VRTRasterBand>
>>> </VRTDataset>
>>>
>>> I just noticed that the resulting GeoTIFF is upside down. Is this a
>>> problem with my GeoTransform values? If so, what values would produce the
>>> image right side up?
>>
>> Greg,
>>
>> I don't see any obvious problem with the geotransform values.
>>
>> Perhaps the image really is upside on disk. If so, you could flip it as
>> it is read by changing your values to
>>
>> <ImageOffset>2403200</ImageOffset>
>> <PixelOffset>4</PixelOffset>
>> <LineOffset>-3004</LineOffset>
>>
>> Best regards,
> _______________________________________________
> grass-user mailing list
> grass-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vira_mapa.py
Type: text/x-python
Size: 473 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-user/attachments/20101120/606c821e/vira_mapa.py
More information about the grass-user
mailing list