[gdal-dev] gdalwarp problems with MODIS L1B

[Even Rouault]

Mike,

> 
> By my reading of https://trac.osgeo.org/gdal/wiki/rfc4_geolocate that means
> the Geolocation tag from gdalinfo should have a PIXEL_STEP and LINE_STEP of
> 5, and if I do this I get a much better result but it's still not right.

I've just committed a patch in trunk that should put more sensible values for 
those values :
r29212 "HDF4: ProcessModisSDSGeolocation(): set more correct values for 
PIXEL_/LINE_ OFFSET/STEP by comparing longitude and latitude subdatasets 
dimensions with main subdataset dimensions"


> I've put a jpeg image of the result, with the coastline mapped and not
> lining up, here:
> 
> http://staff.acecrc.org.au/~mdsumner/mod1.jpg

Either the data itself is wrong, either there's an issue with the geolocation 
transformer... Later hypothesis is the more likely, although I've managed to 
make it work with L1B datasets where the tps or geoloc transformers gave 
roughly the same results.

I've gotten smoother results by resizing the longitude&latitude subdatasets to 
the main subdataset dimension

gdal_translate 
HDF4_SDS:UNKNOWN:"MOD021KM.A2012062.0455.006.2014220083128.hdf":1 
longitude.tif -outsize 1354 2030 -r cubic

gdal_translate 
HDF4_SDS:UNKNOWN:"MOD021KM.A2012062.0455.006.2014220083128.hdf":0 latitude.tif 
-outsize 1354 2030 -r cubic

and then referencing them in the VRT produced with 

gdal_translate -of VRT 
HDF4_SDS:UNKNOWN:"MOD021KM.A2012062.0455.006.2014220083128.hdf":2 data.vrt

(and then by correcting the offset and step values to 0 and 1 respectively)

You might want to do the warp with -wo SAMPLE_GRID=YES -wo SAMPLE_STEPS=100 
too

But overall the reprojected image stays roughly at the same location. This 
helps only removing a few artifacts on the edges.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com