Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#4274 closed defect (worksforme)

gdal_rasterize gives different rasters depending on whether GDAL compiled with --enable-debug on 32-bit linux

Reported by: dustymugs Owned by: warmerdam
Priority: normal Milestone: 1.9.0
Component: Algorithms Version: svn-trunk
Severity: normal Keywords: rasterize
Cc:

Description

I'm currently running GDAL trunk r23174 on a Slackware 13.37 32-bit machine. If I use the following gdal_rasterize command on the linestring.shp found in the attached zip file:

gdal_rasterize -burn 1 -init 0 -a_nodata 0 -tr 0.01 0.01 -ot Byte -l linestring linestring.shp linestring.tif

The generated raster differs depending on whether or not --enable-debug flag is set when configuring the GDAL source.

The linestring is simple (expressed as a PostGIS SQL statement):

ST_MakeLine(ARRAY[
			ST_MakePoint(-1.1, 1.1),
			ST_MakePoint(1.1, 1.1),
			ST_MakePoint(1.1, -1.1),
			ST_MakePoint(-1.1, -1.1),
			ST_MakePoint(-1.1, 1.1)
		])

The zip file also contains the gdal_rasterize outputs:

linestring.tif : GDAL without --enable-debug

linestring-debug.tif : GDAL with --enable-debug

I'm ignoring the fact that neither raster generated is true to the input linestring. I'll file a separate ticket for that. I'm only interested in the fact that the rasters generated with and without --enable-debug are different.

Attachments (2)

linestring.zip (1.8 KB) - added by dustymugs 9 years ago.
archive of linestring.shp and gdal_rasterize outputs of linestring.shp
linestring.tif (48.1 KB) - added by dustymugs 9 years ago.
output raster from 64-bit GDAL gdal_rasterize without --enable-debug

Download all attachments as: .zip

Change History (8)

Changed 9 years ago by dustymugs

Attachment: linestring.zip added

archive of linestring.shp and gdal_rasterize outputs of linestring.shp

comment:1 Changed 9 years ago by dustymugs

I should mention that this problem does not appear on a Slackware64 13.37 (x86_64) machine.

comment:2 Changed 9 years ago by dustymugs

When I configure GDAL source, I only use:

./configure --with-python

and add --enable-debug if needed.

Changed 9 years ago by dustymugs

Attachment: linestring.tif added

output raster from 64-bit GDAL gdal_rasterize without --enable-debug

comment:3 Changed 9 years ago by dustymugs

The output of gdal_rasterize on a 64-bit linux machine without --enable-debug is identical to that of the 32-bit machine with debug-enabled GDAL. See attached linestring.tif

comment:4 Changed 9 years ago by warmerdam

Component: defaultAlgorithms
Keywords: rasterize added
Resolution: worksforme
Status: newclosed

The TIFF file in question has these extents:

Upper Left  (  -1.1000000,   1.1000000) (  1d 6' 0.00"W,  1d 6' 0.00"N)
Lower Left  (  -1.1000000,  -1.1000000) (  1d 6' 0.00"W,  1d 6' 0.00"S)
Upper Right (   1.1000000,   1.1000000) (  1d 6' 0.00"E,  1d 6' 0.00"N)
Lower Right (   1.1000000,  -1.1000000) (  1d 6' 0.00"E,  1d 6' 0.00"S)
Center      (   0.0000000,   0.0000000) (  0d 0' 0.01"E,  0d 0' 0.01"N)

The linestring therefor runs exactly along the edges of pixels and which side of the edge it is evaluated to be on will depend on local system rounding which can be affected by debug options, etc. When a linestring tracks along a pixel edge it is undefined which side it will be evaluated as being on. This is expected behavior - "working as intended".

So, I don't see a bug here. Show me a case where the linestring is not along the edge (and line/edge intersections are not at vertices) and I will review further.

comment:5 Changed 9 years ago by dustymugs

Thanks for the response Frank. For my use of GDALRasterizeGeometries(), should I be increasing the extent used in a fashion similar to that done for points?

comment:6 Changed 9 years ago by warmerdam

Bborie,

Hmm, good question. Creating a geotiff file that exactly matches the bounding box is pretty reasonable for polygon geometries, but it suffers from this danger for lines and points. So yes, if you have expansion logic for points it should likely be applied to lines as well.

Note: See TracTickets for help on using tickets.