Re: [gdal-dev] Re: gdal_rasterize output off by one pixel/cell
Thanks Even for making the fix! Is there documentation anywhere for how to apply changes like this? I apologize but I am just getting into this type of development. I thought I was able to install the latest nightly build today, but I'm not sure. Running Mac OS X. If anyone has any pointers I would really appreciate them off-list. Thanks, Matt On 28 Aug, 2011, at 11:20 PM, Eli Adam wrote: Even, This works for me and the test case included with the initial report. Thank you very much, Eli Even Rouault even.roua...@mines-paris.org 08/28/11 5:25 AM I've applied a fix in trunk in http://trac.osgeo.org/gdal/changeset/22998 . Please test and confirm if it works for you. - Matthew Burton-Kelly, M.S. Graduate Student Department of Geology and Geological Engineering University of North Dakota Mobile: (802) 922-3696 matthew.burton.ke...@my.und.edu matthew.burtonke...@gmail.com http://www.protichnoctem.com http://und.academia.edu/MatthewBurtonKelly About thirty years ago there was much talk that geologists ought only to observe and not theorize; and I well remember someone saying that at this rate a man might as well go into a gravelpit and count the pebbles and describe the colors. How odd it is that anyone should not see that all observation must be for or against some view if it is to be of any service! -Charles Darwin, in an 1861 letter to Henry Fawcett. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: gdal_rasterize output off by one pixel/cell
On 29-08-2011 22:10, Burton-Kelly, Matthew wrote: Thanks Even for making the fix! Is there documentation anywhere for how to apply changes like this? I apologize but I am just getting into this type of development. I thought I was able to install the latest nightly build today, but I'm not sure. Running Mac OS X. If anyone has any pointers I would really appreciate them off-list. Thanks, Matt Matt, I never tried it as I always (re)build from SVN but that implies having previously built the dependencies, but homebrew (no Fink, no MacPorts, HOMEBREW) has a GDAL formula that contemplates svn build. Maybe it's worth to give it a try. Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: gdal_rasterize output off by one pixel/cell
Le samedi 27 août 2011 11:14:00, Hermann Peifer a écrit : 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. I've applied a fix in trunk in http://trac.osgeo.org/gdal/changeset/22998 . Please test and confirm if it works for you. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: gdal_rasterize output off by one pixel/cell
I can confirm that the offset fix works for me, using geographic CRS with SAD69 and WGS84 datums. I can't comment on the edge problem. great job! Etienne - Original Message - From: Even Rouault even.roua...@mines-paris.org To: gdal-dev@lists.osgeo.org Cc: Hermann Peifer pei...@gmx.eu; Eli Adam ea...@co.lincoln.or.us Sent: Sunday, August 28, 2011 9:25:05 AM Subject: Re: [gdal-dev] Re: gdal_rasterize output off by one pixel/cell Le samedi 27 août 2011 11:14:00, Hermann Peifer a écrit : 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. I've applied a fix in trunk in http://trac.osgeo.org/gdal/changeset/22998 . Please test and confirm if it works for you. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: gdal_rasterize output off by one pixel/cell
On 28/08/2011 14:25, Even Rouault wrote: Le samedi 27 août 2011 11:14:00, Hermann Peifer a écrit : 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. I've applied a fix in trunk in http://trac.osgeo.org/gdal/changeset/22998 . Please test and confirm if it works for you. Even, After some testing, I can confirm that both issues (half-pixel shift and lost point at edges) are gone. This is great. Thanks for spending your time fixing this issue, on a sunny Sunday afternoon. Hermann ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: gdal_rasterize output off by one pixel/cell
Even, This works for me and the test case included with the initial report. Thank you very much, Eli Even Rouault even.roua...@mines-paris.org 08/28/11 5:25 AM I've applied a fix in trunk in http://trac.osgeo.org/gdal/changeset/22998 . Please test and confirm if it works for you. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: gdal_rasterize output off by one pixel/cell
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-0dd0ba9e5...@my.und.edu, Burton-Kelly, Matthew matthew.burton.ke...@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 -acolumn name -ts 360 180 -te -180 -90 180 90 -lsource 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: gdal_rasterize output off by one pixel/cell
Eli, Matt, I just rasterised some point data with GDAL 1.9dev from svn and can confirm both observations: a) points are lost at the edges b) points and pixels do not line up correctly in qgis I can align points and pixels by shifting the corner coordinates of the resulting GeoTIFF by 0.5 pixel, but this is hardly a fix: gdal_translate test.tif test_shifted.tif -a_ullr -180.5 90.5 179.5 -89.5 I was able to reproduce the same results with GDAL 1.6.3, so I am wondering for how long the issue is already lurking around -- or are we just doing something terribly wrong? Hopefully not. Hermann On 22/08/2011 18:50, 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-0dd0ba9e5...@my.und.edu, Burton-Kelly, Matthew matthew.burton.ke...@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 -acolumn name -ts 360 180 -te -180 -90 180 90 -lsource 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
