[gdal-dev] gdalwarp problems with MODIS L1B

Rutger kassies at gmail.com
Wed May 27 02:17:38 PDT 2015


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
>> 

> gdal-dev at .osgeo

>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
> 
> _______________________________________________
> gdal-dev mailing list

> gdal-dev at .osgeo

> 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.


More information about the gdal-dev mailing list