Opened 17 years ago
Closed 17 years ago
#1662 closed defect (worksforme)
Data type limitation in gdal_rasterize
Reported by: | lukeroth | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | 1.4.2 |
Component: | GDAL_Raster | Version: | 1.4.1 |
Severity: | normal | Keywords: | rasterize |
Cc: |
Description
I've noticed a limitation in gdal_rasterize: it seems to be saving all values as 8-bit data regardless of the data type of the target image. For example, I have a shapefile for which the value of the feature being rasterized is 710, and I use gdal_rasterize and pass it an unsigned 16-bit image to rasterize to, and the value saved to the image is 195. I've browsed through the gdalrasterize.cpp code and it seems to have special-case code to handle both GDT_Byte and GDT_Float32 data, but no others. However, I don't feel I understand the code well enough yet to know if this is intentional or if it should be fixed. The code in issue is from gdalrasterize.cpp, lines 319-387 (gdal version 1.4.1), where eType is limited to GDT_Float32 for all non - GDT_Byte source image types.
Change History (2)
comment:1 by , 17 years ago
Component: | default → GDAL_Raster |
---|---|
Keywords: | rasterize added |
Milestone: | → 1.4.2 |
Status: | new → assigned |
comment:2 by , 17 years ago
Resolution: | → worksforme |
---|---|
Status: | assigned → closed |
Luke writes (via email):
Thanks for the quick followup - it looks like I jumped the gun on submitting this problem, I've re-read through the code and I think I understand how it works a bit better - I misunderstood exactly how the rasterIO functions handled the data type specification, and it was my code that was handling it incorrectly. Sorry for the trouble!
Luke
--
Closing. Please reopen if you find there is a problem.
Luke,
The code, as structured, is intended to load 16bit data into a float32 buffer, apply changes, and write back to the 16bit file. This should work properly for 16bit data. But you are apparently seeing a different behavior which surprises me. Can you attach a small 16bit raster file, shapefile and commandline that reproduces the problem?
I use Float32 as the general case because it can be used as a working format for most image values without any data loss - though there are some exceptions (float64, complex values and very large int32 values).