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
