[gdal-dev] RasterBand::IWriteBlock

[Jerry Tol]

Thank you - interesting theory but none of the carriage returns occur after
a null, and I'm using gdalwarp to test the driver, so I see no reason for
character io to occur on the output.

Another useful bit of info: the problem does not occur if I specify -ot
Int16. I get random carriage returns only with 32bit float output.

...much obliged...

Tom

On Monday, December 14, 2015, George Watson <watson at sierracmp.com> wrote:

> 0x0d is a carriage return. Someone is using character I/O somewhere. It’s
> possible they are appearing after ‘nul’ characters 0x00 bytes or some such.
>
> George Watson
> Principal, Sierra Computing
> watson at sierracmp.com
> <javascript:_e(%7B%7D,'cvml','watson at sierracmp.com');>
>
>
>
> On Dec 14, 2015, at 10:52 AM, Jerry Tol <jertol52 at gmail.com
> <javascript:_e(%7B%7D,'cvml','jertol52 at gmail.com');>> wrote:
>
> Hello,
> I'm implementing a gdal raster driver for an internal file format and am
> getting results I do not understand. The output is a binary raster of
> 32-bit floating point data, but the resulting file contains single bytes of
> value 0x0D at seemingly random intervals throughout the data.
>
> Within my implementation of IWriteBlock, I see that the buffer pointed to
> by pImage *does not* contain these 0x0D's, however after calling
> VSIFWrite the output file does indeed have these individual bytes
> scattered throughout. In all cases, I am creating a new output file (not
> overwriting an existing file). Sometimes the 0D's occur in the middle of a
> 4-byte float, others are between two 4-byte float sequences. I cannot
> figure how/when/why these random 0D's are occurring in my output.
>
> Thank you for any help provided. Here is my implementation of IWriteBlock
>
> CPLErr RLYRRasterBand::IWriteBlock(int nBlockXOff, int nBlockYOff, void *pImage)
> {
> 	RLYRDataset *poGDS = (RLYRDataset *)poDS;
> 	if (poGDS->fp == 0) {
> 		CPLError(CE_Failure, CPLE_FileIO, "IWriteBlock: fp is NULL");
> 		return CE_Failure;
> 	}
> 	nBlockYOff = poDS->GetRasterYSize() - nBlockYOff - 1;
>
> 	size_t cdtSize = GDALGetDataTypeSize(GetRasterDataType()) / 8;
> 	size_t nSeek = RLYRMeta::offset_data +
> 		cdtSize * (nBlockXOff * nBlockYSize + nBlockYOff * nBlockXSize);
> 	int zeeksez = VSIFSeek(poGDS->fp, nSeek, SEEK_SET);
> 	if (zeeksez != 0) {
> 		CPLError(CE_Warning, CPLE_FileIO, "VSIFSeek returns %d", zeeksez);
> 		return CE_Failure;
> 	}
>
> 	size_t nBlockLen = nBlockXSize * nBlockYSize;
> 	size_t nWrit = VSIFWrite(pImage, cdtSize, nBlockLen, poGDS->fp);
> 	if (nWrit != nBlockLen) {
> 		CPLError(CE_Warning, CPLE_FileIO, "VSIFWrite returns %d", nWrit);
> 		return CE_Failure;
> 	}
>
> 	// test code - 'foo' does not exhibit bad data but the output file does
> 	//if (nBlockYOff == 1130) {
> 	//	FILE *tfp = VSIFOpen("h:\\rasters\\o\\foo", "wb");
> 	//	size_t nWrit2 = fwrite(pImage, cdtSize, nBlockLen, tfp);
> 	//	VSIFClose(tfp);
> 	//}
>
> 	return CE_None;
> }
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> <javascript:_e(%7B%7D,'cvml','gdal-dev at lists.osgeo.org');>
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20151214/6246e30a/attachment.html>