[gdal-dev] gdalwarp problems with MODIS L1B

Even Rouault even.rouault at spatialys.com
Wed May 20 04:27:46 PDT 2015


Le mercredi 20 mai 2015 12:34:57, Michael Sumner a écrit :
> Hi Even, that is excellent, thank you.
> 
> I have one question about the resampling workaround:
> 
> On Wed, 20 May 2015 at 19:34 Even Rouault <even.rouault at spatialys.com>
> 
> wrote:
> > 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)
> 
> Is this what occurs when warping generally? 

The geolocation warper will do bilinear interpolation.

> Or, even with your fix for
> PIXEL/LINE STEP/OFFSET is present will it still be better to do these
> external steps to improve the result?

I'm not sure honestly. That should be studied in depth.

One idea I had would be to use the longitude and latitude subdatasets to 
generate GCPs from them and then use the TPS or 2nd order polynomial GCP 
transformers in order to compare the result (can be done manually for 
experiments, and could potentially become a dedicated transformer too although 
the performance of TPS will be not that great for a big number of GCPs). I 
would trust the GCPs transformers more than the geolocation one. If you still 
had bad results, you could begin blaming the data.

> 
> Thanks again, I've really learnt a lot through this process.
> 
> Cheers, Mike.
> 
> > 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

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


More information about the gdal-dev mailing list