[GRASS-user] MODIS HDF conversion in TIF tool.

Nikos Alexandris nikos.alexandris at felis.uni-freiburg.de
Tue Nov 20 09:56:29 EST 2007


Hello Ivan!

You think your script would be applicable to Surface Reflectance
products (L2) ?

Sorry for bothering again, but since I've limited experience with
scripts... I ask before I I try to modify it for my need.



Ivan Shmakov wrote:
> 
>>>>>> Hamish  <hamish_nospam at yahoo.com> writes:
> 
>  >>>> Reprojecting and subsetting of HDF-EOS grid data is, indeed,
>  >>>> straight-forward, and usually could be done with, e. g.,
>  >>>> gdalwarp(1).  Not so for the swath data.
> 
>  >>> Could the swath data be reprojected using gdalwarp's -tps thin
>  >>> plate spline function? ISTR that's what -tps was commisioned
>  >>> for. (??)
> 
>  >> I've tried gdalinfo(1) on AIRS .hdf:
> 
>  >> $ gdalinfo AIRS.2007.05.31.214.L2.RetStd.v4.0.9.102.D07281163221.hdf
> 
>  >> and it shows no ground control points.  I suppose, this is because
>  >> the GCP's are given in separate HDF arrays (Latitude & Longitude),
>  >> and not in the metadata.  Solving this problem may make gdalwarp(1)
>  >> an alternative to HEG.
> 
>  > you can use gdal_translate to add (per scanline) GCPs to the metadata
>  > before running gdalwarp.  gdal_translate -gcp pixel line easting
>  > northing [elevation]
> 
> 	Indeed, it works, at least for the AIRS data.  (Although I've
> 	had to upgrade GDAL 1.3.2, as supplied with Debian 4.0 r1, to
> 	1.4.3.)
> 
> 	For those who are interested, the script I've used looks roughly
> 	as follows:
> 
> --cut--
> #!/bin/bash
> file=AIRS.2007.07.09.079.L2.RetStd.v4.0.9.102.D07190164053.hdf
> file_gcp=airs-2007-07-09-gran-79-l2-retstd-tsurfstd-gcp+0.5.tiff
> file_out=airs-2007-07-09-gran-79-l2-retstd-tsurfstd-gcp+0.5-laea-10km.tiff
> 
> ## FIXME: specify ``no projection'' instead?
> source_srs='+proj=latlong'
> target_srs='+proj=laea +lat_0=55.0 +lon_0=90'
> 
> ## FIXME: more clean error handling
> set -x -e
> 
> long_lat_to_gcp () {
>     gawk '$1 != -9999 && $2 != -9999 {
>               print "-gcp", (NR - 1) % 30 + .5, int ((NR - 1) / 30) + .5,
> $1, $2;
>           }'
> }
> 
> gdal_translate \
>     $(paste <(hdfdump --text "$file" {Long,Lat}itude) | long_lat_to_gcp) \
>    
> "HDF4_EOS:EOS_SWATH:\"$file\":L2_Standard_atmospheric&surface_product:TSurfStd"
> \
>     "$file_gcp"
> gdalwarp \
>     -tps -s_srs "$source_srs" -t_srs "$target_srs" \
>     -tr 1e4 1e4 \
>     "$file_gcp" "$file_out"
> --cut--
> 
> 	Is there any chance that GDAL will obtain ``GCPs'' from the
> 	HDF-EOS file directly?
> 
> [...]
> 
>  >> The one more problem with the MODIS L2 data is that it consists of
>  >> overlapping scans -- MODIS could ``see'' some parts of the Earth in
>  >> consequent scans.
> 
> [...]
> 
>  > I think you may get a much better answer about this if you ask on the
>  > gdal-dev mailing list. (www.gdal.org) Lots of smart experts on this
>  > stuff there.
> 
> 	I'm cross-posting it there.
> _______________________________________________
> grass-user mailing list
> grass-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
> 
> 

-- 
View this message in context: http://www.nabble.com/MODIS-HDF-conversion-in-TIF-tool.-tf4799564.html#a13858358
Sent from the Grass - Users mailing list archive at Nabble.com.



More information about the grass-user mailing list