#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)
Change History (8)
by , 12 years ago
Attachment: | linestring.zip added |
---|
comment:1 by , 12 years ago
I should mention that this problem does not appear on a Slackware64 13.37 (x86_64) machine.
comment:2 by , 12 years ago
When I configure GDAL source, I only use:
./configure --with-python
and add --enable-debug if needed.
by , 12 years ago
Attachment: | linestring.tif added |
---|
output raster from 64-bit GDAL gdal_rasterize without --enable-debug
comment:3 by , 12 years ago
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 by , 12 years ago
Component: | default → Algorithms |
---|---|
Keywords: | rasterize added |
Resolution: | → worksforme |
Status: | new → closed |
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 by , 12 years ago
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 by , 12 years ago
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.
archive of linestring.shp and gdal_rasterize outputs of linestring.shp