[gdal-dev] gdalwarp problems with MODIS L1B

[Max Andela]

Dear Even Rouault:
May I know how to input the latitude and longitude layers while warping
with gdalwarp?

Thanks.
max

On Wed, May 20, 2015 at 6:34 PM, 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)
>
> 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
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150523/2fb75146/attachment.html>