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 : [email protected] [mailto:[email protected]] De la part de Even Rouault Envoyé : jeudi 21 mai 2015 10:43 À : [email protected] 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 [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
