[gdal-dev] gdalwarp problems with MODIS L1B

[Julien Demaria]

Hi,

I confirm that gdalwarp should not work well with MODIS/VIIRS bow-tie effect. Maybe apply the same reprojection logic but on each bow-tie separately (bow-tie are blocks of 20 rows I think) should give better results by I don't know if it's possible.

Here we developed an internal reprojection tool to handle swath products with per-pixel lat/lon (like MODIS, VIIRS, SeaWiFS, MERIS, ...), we do binning: for each input pixel we search were it falls in the output regular grid, but this approach needs to allocate the full output grid at the beginning. We also use a fast flux-conserving resampling (skyview.gsfc.nasa.gov/polysamp/polysamp.ppt): each input pixel is represented as a quadrilateral computed using the input per-pixel lat/lon; this is better than doing binning only using pixel center which will create artifact holes in the output product depending on your input/output resolutions. We use GDAL to read input L2 data.

Regards,
Julien

-----Message d'origine-----
De : gdal-dev-bounces at lists.osgeo.org [mailto:gdal-dev-bounces at lists.osgeo.org] De la part de Even Rouault
Envoyé : jeudi 21 mai 2015 10:43
À : gdal-dev at lists.osgeo.org
Cc : Rutger
Objet : Re: [gdal-dev] gdalwarp problems with MODIS L1B

Rutger,

> 
> Maybe i'm missing something, but for as far as i know, the MODIS 
> MOD021KM product is still a 'swath', and therefore still containing 
> the bow-tie effect as the result of the scanning sensor. Wouldn't this 
> mean that gdalwarp will never work? The lat/lon arrays aren't 
> continuous,

yes you're right. I looked at the first column of the latitude array, and the derivative apparently changes sign for each row,

>>> from osgeo import gdal
>>> ds =
gdal.Open('HDF4_SDS:UNKNOWN:"MOD021KM.A2012062.0455.006.2014220083128.hdf":0')
>>> first_col = ds.ReadAsArray()[:,0]
>>> first_col[1:] - first_col[0:-1]
array([-0.07051849,  0.0051384 , -0.07039642,  0.00334167, -0.07026672,
        0.00508118, -0.07014084,  0.00319672, -0.07001114,  0.00492477,
       -0.06988907,  0.00340271, -0.06975555,  0.00507736, -0.06962967, ....

So yes I don't think the GDAL transformers can work properly with that kind of data.

On lines, the values look more continuous. So a potential workaround might be to reorder the lines of the raster and of the lat,lon arrays priorly to any warping.

Even

--
Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev