[Gdal-dev] modis sinusoidal tiles: bug in gdal?

[Vincent Schut]

Frank Warmerdam wrote:
> Vincent Schut wrote:
>> The puzzle:
>> Then I tried to merge some modis tiles by using VRT, using vrt_merge.py.
>> I was very puzzeled when I got an error message telling me it wouldn't
>> merge my tiles because they did not have the same scale. 
>
> Vincent,
>
> vrt_merge.py isn't part of GDAL - could you provide a pointer to the
> version you are using?
>
>> After some
>> investigation, it indeed appeared they didn't! Pixel size (as calculated
>> by gdal) is different per tile. At around (0,0) degrees latlong, pixels
>> are square and of size 463.312716527916677 meters. The further one goes
>> from the equator or 0 deg longitude, the more the pixel size in that
>> direction differs from this 463.312716527916677 and pixels are not
>> square anymore.
>
> I see the pixels are just very slightly not-square.  The actually bounds
> in sinusoidal projection are apparently computed from the lat/long bounds
> for the image so they are sensitive to small differences due to floating
> point error, and issues in the sinusoidal equations.  I see the
> differences
> are roughly 12 digits into the pixel size and represent a difference in
> pixel size of roughly one billionth of a meter or (I think) roughly one
> millionth of a meter in the origin/corner values.
And as an extra example to the not-so-good metadata that NASA apparently
ships with their products:
- they say they use a spheroid of 6371007.181.
- md says GLOBALGRIDCOLUMNS=86400
- md says CHARACTERISTICBINSIZE=463.312716527778
- (6371007.181 * 2pi) / 86400 = 463.31271656938469
Now which one is non-accurate, their spheroid or their pixel size? OK,
we are still talking below-mm scales, but still I think it is a bit
embarassing... Or maybe they have a more accurate pi than my python
has... :-)

OK, let's close the issue. I'll just use their spheroid and calculate my
own pixel sizes.

Cheers,
VS.