tr option not working on MOD10A1.005 HDF 4 file.

[William Valencia]

I tried converting a MOD10A1.005 HDF 4 file to GeoTIFF with the -tr option. It basically hangs while giving me an always growing file. I had to kill the process. When I use -outsize it works without issue.

Using a MOD10CM.005 HDF 4 file, both options(tr and outsize) execute fast and give the proper results. Not sure if it is projection related. I am using gdal version 2.2.1

Here is the result of the outsize call:

gdal_translate -co COMPRESS=DEFLATE -sds -of GTiff MOD10A1.A2005177.h12v12.005.2008204203950.hdf test.tif -outsize 1230 598

Input file size is 2400, 2400
0...10...20...30...40...50...60...70...80...90...100 - done.
Input file size is 2400, 2400
0...10...20...30...40...50...60...70...80...90...100 - done.
Input file size is 2400, 2400
0...10...20...30...40...50...60...70...80...90...100 - done.
Input file size is 2400, 2400
0...10...20...30...40...50...60...70...80...90...100 - done.

Here is the result of the -tr call (had to terminate it)

gdal_translate -co COMPRESS=DEFLATE -sds -of GTiff MOD10A1.A2005177.h12v12.005.2008204203950.hdf test.tif -tr 0.0167393593526468 0.0167224088988974

Input file size is 2400, 2400
0^C

Here is some info on the file(I chose a specific subdataset to show the projection info):

gdalinfo HDF4_EOS:EOS_GRID:"MOD10A1.A2005177.h12v12.005.2008204203950.hdf":MOD_Grid_Snow_500m:Snow_Cover_Daily_Tile
Driver: HDF4Image/HDF4 Dataset
Files: MOD10A1.A2005177.h12v12.005.2008204203950.hdf
Size is 2400, 2400
Coordinate System is:
PROJCS["unnamed",
    GEOGCS["Unknown datum based upon the custom spheroid",
        DATUM["Not specified (based on custom spheroid)",
            SPHEROID["Custom spheroid",6371007.181,0]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Sinusoidal"],
    PARAMETER["longitude_of_center",0],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["Meter",1]]
Origin = (-6671703.117999999783933,-3335851.558999999891967)
Pixel Size = (463.312716527916507,-463.312716527916677)
Metadata:
...
Corner Coordinates:
Upper Left  (-6671703.118,-3335851.559) ( 69d16'55.32"W, 30d 0' 0.00"S)
Lower Left  (-6671703.118,-4447802.079) ( 78d19'27.97"W, 40d 0' 0.00"S)
Upper Right (-5559752.598,-3335851.559) ( 57d44' 6.10"W, 30d 0' 0.00"S)
Lower Right (-5559752.598,-4447802.079) ( 65d16'13.31"W, 40d 0' 0.00"S)
Center      (-6115727.858,-3891826.819) ( 67d 8'33.37"W, 35d 0' 0.00"S)
Band 1 Block=2400x416 Type=Byte, ColorInterp=Gray
  Description = Snow cover extent by best observation of the day
  NoData Value=255
  Unit Type: none

[William Valencia]

MOD10A1.005 HDF file

[Even Rouault]

That's completely expected. Using such tiny values of -tr ( 0.01673 ) compared to your original resolution (463.31) results in a file that should be 66427304x66494638 !