Hi Max, Maybe this will help you: http://osgeo-org.1560.x6.nabble.com/gdal-dev-reproject-python-numpy-binary-swath-lat-lon-td4978609.html#a4981318
I made two VRT's containing the latitude and longitude band. Then referenced those in a VRT containing the actual data band, by using the "metadata" key in VRT. Note that the step of 1 and offset of 0 correspond to a situation where the shape of the lat/lon bands is identical to the data. Regards, Rutger Max Andela wrote > 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@ > > > 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 >> > [email protected] >> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> > > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-gdalwarp-problems-with-MODIS-L1B-tp5206583p5207732.html Sent from the GDAL - Dev mailing list archive at Nabble.com. _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
