On 9/22/2014 2:18 PM, Jan Tosovsky wrote: > On 2014-09-21 David Strip wrote: >> Looking back at the code, the actual output file is created with >> this line: >> self.out_drv.CreateCopy(tilefilename, dstile, strict=0) > Hmm, I have no idea how to pass this info into CreateCopy: > http://www.gdal.org/classGDALDriver.html
This was bad advice. CreateCopy uses the same datatype as the raster it's copying, so it couldn't be the source of your problem (and there's no way to specify a datatype, since it's just copied). > >> If this still doesn't fix it, the first thing to do is run gdalinfo >> against one of the tiles and let us know the result. > Thanks for the hint. I've checked the tiling source (correct file): > > ... > Metadata: > AREA_OR_POINT=Area > Image Structure Metadata: > INTERLEAVE=BAND > Corner Coordinates: > ... > Band 1 Block=256x256 Type=Int16, ColorInterp=Gray > NoData Value=0 > > > While my tile is: > ... > Image Structure Metadata: > INTERLEAVE=PIXEL > Corner Coordinates: > ... > Band 1 Block=256x8 Type=UInt16, ColorInterp=Gray > Band 2 Block=256x8 Type=UInt16, ColorInterp=Undefined > > I've changed UInt16 to Int16, but in this case there are 'ERROR 1: Buffer > too small' errors when tiles are produced (but they are somehow generated > anyway). It fixes the type to Int16, but there are still some differences. I have no idea what this is about. It does appear to be some sort of numpy error msg from within the routine, but why it occurs and you can still get output is a mystery to me. > > What exactly is 'Block=256x256' and is 'Block=256x8' in the second case > correct? The block describes how the pixels are laid out in the file. The fact that the input and output block sizes are different is not an error. Likewise, interleave = band vs. pixel is a matter of internal organization and shouldn't matter. > Are other differences cosmetic or fatal ones? gdal2tiles automatically creates a mask band (band2) for the tile, so the addition of the second band is not surprising or incorrect. This also accounts for the removal of the NoData Value > > Thanks, Jan > > _______________________________________________ > 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
