[gdal-dev] [Proj] Pixel Shifts When Warping

[Roger André]

The GDAL data model does specifically call out the top-left corner of the
top-left pixel as the origin. Not sure if that's helpful, but I remember
having to look this up before.

http://www.gdal.org/gdal_datamodel.html


On Mon, May 18, 2015 at 8:31 AM, Yuta Sato <yutaxsato at gmail.com> wrote:

> Dear all:
>
> Thanks for sharing your ideas and experiences.
>
> As I mentioned in my question, it seems that MRT result is shifting right
> while the GDAL warp result is correct. Do you agree?
>
> The exact upper left corner of the original HDF-EOS file is exactly as the
> GDAL warpped result.
>
> The HDF file uses top left corner of top left pixel, while the MRT seems
> to use central of top left pixel (MRT userguide page 10 under corner
> coordinates section), am I right?
>
>
> https://lpdaac.usgs.gov/sites/default/files/public/mrt41_usermanual_032811.pdf
>
> If I am right, fortunately the GDAL would win!
>
>
>
>
>
> On Mon, May 18, 2015 at 11:24 PM, Markus Neteler <neteler at osgeo.org>
> wrote:
>
>> On Sun, May 17, 2015 at 1:32 PM, Even Rouault
>> <even.rouault at spatialys.com> wrote:
>> > Le dimanche 17 mai 2015 12:54:44, Markus Neteler a écrit :
>> >> On Sun, May 17, 2015 at 6:44 AM, Yuta Sato <yutaxsato at gmail.com>
>> wrote:
>> >> > Dear GDAL and Proj Developers and Users:
>> >> >
>> >> > I am really frustrated when the MODIS HDF file converted into GeoTiff
>> >> > with GCS projection never match with the same MODIS file  converted
>> from
>> >> > MODIS Reprojection tool.
>> >>
>> >> We had this issue in the past, too, for our "EuroLST" project
>> >> (gap-filling of all LST maps for Europe, see
>> http://gis.cri.fmach.it/eurolst/).
>> >> Solved since then, see below.
>> >> ...
>> >>
>> >> > Do you have any idea on which is more precise: gdalwarp or MRT? Or
>> there
>> >> > is any way in gdalwarp to get the same image as MRT gives?
>>
>> An addition:
>>
>> For our EuroLST project we use EU LAEA as target projection. In our
>> tests (we made a lot) the MRT results came out shifted by 0.5 -1.0
>> pixel since MRT does not support a datum or ellipsoid for LAEA (LA in
>> MRT), instead it supports only a sphere when reprojecting from MODIS
>> sinusoidal.
>>
>> Using recent GDAL, gdalwarp does the reprojection from MODIS
>> sinusoidal to EU LAEA correctly.
>>
>> >> You may take a look at
>> >> http://pymodis.fem-environment.eu/
>> >>
>> >> pyModis >= 1.0 comes with fast GDAL support (way faster than MRT).
>> >>
>> >> The details of the gdalwarp usage you find in the source code here:
>> >>
>> https://github.com/lucadelu/pyModis/blob/master/pymodis/convertmodis_gdal.py
>> >
>> > Markus,
>> >
>> > for the sake of my curiosity, could you explain what specific stuff it
>> does
>> > compared to gdalwarp ? I quickly skimmed through the file and only saw
>> regular
>> > use of the GDAL warping API. But perhaps I missed something.
>>
>> pyMODIS is a set of scripts and a library to perform the download of
>> large numbers of MODIS HDF/XML files (think cronjob), it creates a
>> mosaic of several tiles, it extracts specific information from
>> bit-encoded MODIS quality assessment layers of different product types
>> etc.
>>
>> Essentially a ready to use product which happily uses GDAL as a backend.
>>
>> Markus
>>
>> --
>> http://courses.neteler.org
>> http://gis.cri.fmach.it/neteler/
>> http://grass.osgeo.org
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
>
> _______________________________________________
> 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/20150518/dc8a569b/attachment-0001.html>