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