[gdal-dev] Re: gdal_rasterize output off by one pixel/cell

[Hermann Peifer]

Matthew,

An absolute kludge-type of "solution" would be a) to make sure that the 
GeoTIFF is larger than the shapefile when rasterising (in order to not 
loose points at the edges) and b) to shift the GeoTIFF NW by 0.5 pixel 
after rasterising, as I already wrote in my previous mail.

There has been no traffic on Eli's ticket 
http://trac.osgeo.org/gdal/ticket/3774 during the last 11 months, so my 
guess is that the bug will remain for a while. It's strange that there 
aren't more people stumbling across the issue.

Hermann


On 26/08/2011 22:07, Burton-Kelly, Matthew wrote:
> Eli,
>
> I finally got around to looking at the example shapefile and running the same operation on my machine, and it does indeed seem like the same bug.  Thanks for the good eye, this almost seems like two separate issues; first being the missing edge points and second being the weird offset.  I only say this because the offset persists even when I set the extents of the output raster as larger than the input layer.
>
> Matt
>
>
> On 22 Aug, 2011, at 11:50 AM, Eli Adam wrote:
>
>> Matt,
>>
>>      You may want to look at this ticket and see if it is the same thing. If so, you can add yourself to the cc list and you will get emails when there are updates to the ticket.  You can also add any additional relevant information to the ticket.
>>
>> http://trac.osgeo.org/gdal/ticket/3774
>>
>> Regards, Eli
>>
>>
>>
>>>>> On 8/20/2011 at 11:06 AM, in message
>> <AA52F8AC-89DC-4543-A210-0DD0BA9E58FD at my.und.edu>, "Burton-Kelly, Matthew"
>> <matthew.burton.kelly at my.und.edu>  wrote:
>>> Hello,
>>>
>>> I'm attempting to create a raster from a shapefile of point data, with grid
>>> cells 1 degree square.  Although the area I have defined matches up with the
>>> origin coordinates I want, and the grid cells match up with a vector 1-degree
>>> grid I produced in QGIS, the squares supposedly containing the point data are
>>> shifted, it looks like down and to the right.  Has anyone encountered this
>>> issue before?
>>>
>>> Here is the command I used:
>>> gdal_rasterize -a<column name>  -ts 360 180 -te -180 -90 180 90 -l<source layer name
>>> in source file>  <source file>  <destination file>
>>>
>>> I have uploaded a screenshot of the output I am describing here:
>>> http://www.flickr.com/photos/matthewbk/6059112633
>>>
>>> Thanks for any insight,
>>> Matt
>>>
>>>
>>>