gdal_rasterize hangs with all_touched option

[piyushrpt]

gdal_rasterize hangs when I use the -at option on some of the SRTM land water body datasets. An example can be found here:

​http://dds.cr.usgs.gov/srtm/version2_1/SWBD/SWBDwest/w082n30n.zip

Exact command: gdal_rasterize -burn 1 -at -of ENVI -ot Byte -te -82 30 -81 31 -ts 3600 3600 w082n30n.shp test.msk

gdal-config --version 1.11.0

gdal-config --ogr-enabled yes

[Jukka Rahkonen]

I can confirm. Tested with GDAL 2.0-dev on Window 7 64-bit and to ENVI and GeoTIFF output. Process stops in the beginning after showing "0" as the progress indicator. Without -at no problems at all.

gdal_rasterize -burn 1 -at  -of GTiff -ot Byte -te -82 30 -81 31 -ts 3600 3600 w082n30n.shp test.tif  --debug on
GDAL: GDALOpen(w082n30n.shp, this=00000000004EF650) succeeds as ESRI Shapefile.
GDAL: QuietDelete(test.tif) invoking Delete()
GDAL: GDALOpen(test.tif, this=000000000061FFB0) succeeds as GTiff.
GDAL: GDALDefaultOverviews::OverviewScan()
GDAL: GDALClose(test.tif, this=000000000061FFB0)
GDAL: GDALDriver::Create(GTiff,test.tif,3600,3600,1,Byte,0000000000000000)
GDAL: Rasterizer operating on 2 swaths of 2777 scanlines.
0

[meier]

Running the initial gdal_rasterize on the image with -at option, but without the -te arguments -

$ gdal_rasterize -burn 100 -of GTiff -ot Byte -at -ts 3600 3600 w082n30n.shp test.tif --debug on

GDAL: GDALOpen(w082n30n.shp, this=0x81ab320) succeeds as ESRI Shapefile.
GDAL: GDALDriver::Create(GTiff,test.tif,3600,3600,1,Byte,(nil))
GDAL: Rasterizer operating on 2 swaths of 2777 scanlines.
0...10...20...30...40...50...60...70...80...90...100 - done.
Shape: 59 features read on layer 'w082n30n'.
GDAL: GDALClose(w082n30n.shp, this=0x81ab320)
GDAL: GDALClose(test.tif, this=0x81ac4f0)

After that, I ran the following to get the input coordinates of the vector image -

$ gdalinfo -stats test.tif 
Driver: GTiff/GeoTIFF
Files: test.tif
Size is 3600, 3600
Coordinate System is `'
Origin = (-81.982130862341990,31.000000000000000)
Pixel Size = (0.000272814128428,-0.000277777777778)
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  ( -81.9821309,  31.0000000) 
Lower Left  ( -81.9821309,  30.0000000) 
Upper Right ( -81.0000000,  31.0000000) 
Lower Right ( -81.0000000,  30.0000000) 
Center      ( -81.4910654,  30.5000000) 
Band 1 Block=3600x2 Type=Byte, ColorInterp=Gray
  Minimum=0.000, Maximum=100.000, Mean=45.058, StdDev=49.755
  Metadata:
    STATISTICS_MAXIMUM=100
    STATISTICS_MEAN=45.058225308642
    STATISTICS_MINIMUM=0
    STATISTICS_STDDEV=49.755189306241

As can be seen, the coordinates of the extents of the vector image initially are (-81.9821309, 31.0000000), ( -81.9821309, 30.0000000), ( -81.0000000, 31.0000000) and ( -81.0000000, 30.0000000).

Running the gdal_rasterize operation with these coordinates, I got -

$ gdal_rasterize -burn 100 -of GTiff -ot Byte -at -te -81.9821309 30.0000000 -81.0000000 31.0000000 -ts 3600 3600 w082n30n.shp test.tif --debug on
GDAL: GDALOpen(w082n30n.shp, this=0x92c2398) succeeds as ESRI Shapefile.
GDAL: GDALDriver::Create(GTiff,test.tif,3600,3600,1,Byte,(nil))
GDAL: Rasterizer operating on 2 swaths of 2777 scanlines.
0...10...20...30...40...50...60...70...80...90...100 - done.
Shape: 59 features read on layer 'w082n30n'.
GDAL: GDALClose(w082n30n.shp, this=0x92c2398)
GDAL: GDALClose(test.tif, this=0x92c3560)

This works fine, in fact, anything other than the extents (-82 30 -81 31) works with -at option. I suggest you take a closer look at your coordinates. I am unable to explain why this happens, but this is a workaround of sorts around the issue. If you want to check out the source code, it is available at ​https://github.com/OSGeo/gdal/blob/trunk/gdal/alg/gdalrasterize.cpp. Check the following function

CPLErr GDALRasterizeLayers() 

[Even Rouault]

In 38817:

GDALRasterize(): avoid hang in some cases with all_touched option (fixes #5580)

[Even Rouault]

In 38818:

GDALRasterize(): avoid hang in some cases with all_touched option (fixes #5580)

[Even Rouault]

In 38819:

GDALRasterize(): avoid hang in some cases with all_touched option (fixes #5580)