The results of -tap are what I expect, pixels aligned with 0,0. Although I have a separate question at the end.
Prior to the patch I ran this: gdal_rasterize -tr 100 100 -a Elevation -l town town.shp townrasterb.tif and got this: gdalinfo townrasterb.tif ... Origin = (7267911.066051597706974,512434.991065477312077) Pixel Size = (100.000000000000000,-100.000000000000000) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 7267911.066, 512434.991) (124d 6'49.77"W, 45d 0'53.75"N) Lower Left ( 7267911.066, 290634.991) (124d 4'33.15"W, 44d24'25.68"N) Upper Right ( 7392811.066, 512434.991) (123d37'52.26"W, 45d 1'45.22"N) Lower Right ( 7392811.066, 290634.991) (123d35'53.84"W, 44d25'16.61"N) Center ( 7330361.066, 401534.991) (123d51'17.02"W, 44d43' 6.24"N) Band 1 Block=1249x1 Type=Float64, ColorInterp=Gray After the patch I ran this: gdal_rasterize -tr 100 100 -tap -a Elevation -l town town.shp townrasterd.tif and got this: gdalinfo townrasterd.tif ... Origin = (7267900.000000000000000,512500.000000000000000) Pixel Size = (100.000000000000000,-100.000000000000000) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 7267900.000, 512500.000) (124d 6'49.97"W, 45d 0'54.39"N) Lower Left ( 7267900.000, 290600.000) (124d 4'33.28"W, 44d24'25.33"N) Upper Right ( 7392900.000, 512500.000) (123d37'51.05"W, 45d 1'45.90"N) Lower Right ( 7392900.000, 290600.000) (123d35'52.60"W, 44d25'16.29"N) Center ( 7330400.000, 401550.000) (123d51'16.49"W, 44d43' 6.41"N) Band 1 Block=1250x1 Type=Float64, ColorInterp=Gray town.shp is a point layer with 12 points, 11 of those points have values in -a Elevation (1 is null), and in the output tif, 9 pixels have values. The far south and far east points do not have corresponding pixels with values. If this needs review, I can open a ticket and attach a very small example. I include this info in this thread since that is the case before -tap and after -tap I get the same thing, except the far east point has a corresponding pixel with -tap. This probably doesn't have anything (much) to do with -tap. Thanks, Eli >>> Hermann Peifer <pei...@gmx.eu> 10/06/10 7:43 AM >>> On 06/10/2010 16:34, Frank Warmerdam wrote: > Hermann Peifer wrote: >>> $ gdal_rasterize --debug on --config GDAL_CACHEMAX 2000 -ot byte >>> -a_nodata 0 -co compress=lzw -tr 255 255 -tap -l lu001l_luxembourg -burn >>> 1 -where CODE=111 lu001l_luxembourg.shp out.tif >>> OGR: OGROpen(lu001l_luxembourg.shp/0x1978ae0) succeeded as ESRI >>> Shapefile. >>> GDAL: QuietDelete(out.tif) invoking Delete() >>> GDAL: GDALOpen(out.tif, this=0x19cbe00) succeeds as GTiff. >>> GDAL: GDALDefaultOverviews::OverviewScan() >>> GDAL: GDALClose(out.tif, this=0x19cbe00) >>> GDAL: GDALDriver::Create(GTiff,out.tif,224,321,1,Byte,0x1979ab0) >>> ERROR 1: Type mismatch or improper type of arguments to = operator. > ... >> I see: ERROR 1 can be avoided by using: -where CODE=\'50000\' (CODE is >> a string field). In any case: I rasterize via a shell script and I did >> not get the same error when running the same script last week. > > Herman, > > Were you using GDAL 1.7 last week? No, but an earlier version of 1.8dev (a few months old, perhaps) Hermann _______________________________________________ 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