[Gdal-dev] Re: [GDAL] #1662: Data type limitation in gdal_rasterize

[Luke Roth]

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

On 6/8/07, GDAL <trac at osgeo.org> wrote:
> #1662: Data type limitation in gdal_rasterize
> -------------------------+--------------------------------------------------
>  Reporter:  lukeroth     |        Owner:  warmerdam
>      Type:  defect       |       Status:  assigned
>  Priority:  normal       |    Milestone:  1.4.2
> Component:  GDAL_Raster  |      Version:  1.4.1
>  Severity:  normal       |   Resolution:
>  Keywords:  rasterize    |
> -------------------------+--------------------------------------------------
> Changes (by warmerdam):
>
>   * keywords:  => rasterize
>   * status:  new => assigned
>   * component:  default => GDAL_Raster
>   * milestone:  => 1.4.2
>
> Comment:
>
>  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).
>
> --
> Ticket URL: <http://trac.osgeo.org/gdal/ticket/1662#comment:1>
> GDAL <http://trac.osgeo.org/gdal/>
> Geospatial Data Abstraction Library is a translator library for raster and vector geospatial data formats.