[gdal-dev] Re: gdal_rasterize -tr and -te

Eli Adam eadam at co.lincoln.or.us
Wed Oct 6 12:42:14 EDT 2010


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 <peifer at 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 at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev



More information about the gdal-dev mailing list