Problem Solved. <div><br></div><div>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". <br><br>What threw me off was the fact that the problem did not occur when using Int16 output. Ugh, another beginner mistake on my part. </div><div><br></div><div>Thanks again G Watson!</div><div><br></div><div>Tom</div><div><span></span><br>On Monday, December 14, 2015, Jerry Tol <<a href="mailto:jertol52@gmail.com">jertol52@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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. <div><br></div><div>Another useful bit of info<span></span>: the problem does not occur if I specify -ot Int16. I get random carriage returns only with 32bit float output. </div><div><br></div><div>...much obliged...</div><div><br></div><div>Tom<br><br>On Monday, December 14, 2015, George Watson <<a href="javascript:_e(%7B%7D,'cvml','watson@sierracmp.com');" target="_blank">watson@sierracmp.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">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.<div><br><div>
<div>George Watson</div><div>Principal, Sierra Computing</div><div><a>watson@sierracmp.com</a></div><div><br></div><br>
</div>
<br><div><blockquote type="cite"><div>On Dec 14, 2015, at 10:52 AM, Jerry Tol <<a>jertol52@gmail.com</a>> wrote:</div><br><div><div dir="ltr">Hello,<div>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. </div><div><br></div><div>Within my implementation of IWriteBlock, I see that the buffer pointed to by pImage <b>does not</b> contain these 0x0D's, however after calling <span style="font-family:Consolas">VSIFWrite </span>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.</div><div><br></div><div>Thank you for any help provided. Here is my implementation of IWriteBlock</div><div><pre style="font-family:Consolas;background-repeat:initial initial">CPLErr RLYRRasterBand::IWriteBlock(<span style="color:blue">int</span> nBlockXOff, <span style="color:blue">int</span> nBlockYOff, <span style="color:blue">void</span> *pImage)
{
RLYRDataset *poGDS = (RLYRDataset *)poDS;
<span style="color:blue">if</span> (poGDS->fp == 0) {
CPLError(CE_Failure, CPLE_FileIO, <span style="color:rgb(163,21,21)">"IWriteBlock: fp is NULL"</span>);
<span style="color:blue">return</span> CE_Failure;
}
nBlockYOff = poDS->GetRasterYSize() - nBlockYOff - 1;
size_t cdtSize = GDALGetDataTypeSize(GetRasterDataType()) / 8;
size_t nSeek = RLYRMeta::offset_data +
cdtSize * (nBlockXOff * nBlockYSize + nBlockYOff * nBlockXSize);
<span style="color:blue">int</span> zeeksez = VSIFSeek(poGDS->fp, nSeek, SEEK_SET);
<span style="color:blue">if</span> (zeeksez != 0) {
CPLError(CE_Warning, CPLE_FileIO, <span style="color:rgb(163,21,21)">"VSIFSeek returns %d"</span>, zeeksez);
<span style="color:blue">return</span> CE_Failure;
}
size_t nBlockLen = nBlockXSize * nBlockYSize;
size_t nWrit = VSIFWrite(pImage, cdtSize, nBlockLen, poGDS->fp);
<span style="color:blue">if</span> (nWrit != nBlockLen) {
CPLError(CE_Warning, CPLE_FileIO, <span style="color:rgb(163,21,21)">"VSIFWrite returns %d"</span>, nWrit);
<span style="color:blue">return</span> CE_Failure;
}
<span style="color:green">// test code - 'foo' does not exhibit bad data but the output file does</span>
<span style="color:green">//if (nBlockYOff == 1130) {</span>
<span style="color:green">// FILE *tfp = VSIFOpen("h:<a>\\rasters\\o\\foo</a>", "wb");</span>
<span style="color:green">// size_t nWrit2 = fwrite(pImage, cdtSize, nBlockLen, tfp);</span>
<span style="color:green">// VSIFClose(tfp);</span>
<span style="color:green">//}</span>
<span style="color:blue">return</span> CE_None;
}
</pre></div></div>
_______________________________________________<br>gdal-dev mailing list<br><a>gdal-dev@lists.osgeo.org</a><br><a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a></div></blockquote></div><br></div></div></blockquote></div>
</blockquote></div>