[gdal-dev] RasterBand::IWriteBlock

[Jerry Tol]

Problem Solved.

Mr. G Watson provided the solution. Specifically, I had specified "w" in my
call to VSIFOpen. The carriage returns rightfully disappeared
after changing the mode to "wb".

What threw me off was the fact that the problem did not occur when using
Int16 output. Ugh, another beginner mistake on my part.

Thanks again G Watson!

Tom

On Monday, December 14, 2015, Jerry Tol <jertol52 at gmail.com> wrote:

> 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
> <javascript:_e(%7B%7D,'cvml','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
>>
>>
>>
>> On Dec 14, 2015, at 10:52 AM, Jerry Tol <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
>> 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/165fa70f/attachment.html>