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 <[email protected]> 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 > [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');> > > > > On Dec 14, 2015, at 10:52 AM, Jerry Tol <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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 > [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');> > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > >
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
