I was wondering if anybody has any suggestions for good strategies for implementing ascii GDAL raster drivers.<div><br class="webkit-block-placeholder"></div><div>I&#39;m looking at reworking and correcting the GSAG driver (we need this up and running ASAP here). &nbsp;Unfortunately, it&#39;s an ascii file format where it&#39;s specified with the lower left pixel first, instead of the upper left pixel.</div>
<div><br class="webkit-block-placeholder"></div><div>I&#39;ve been trying to figure out a good strategy to get this working correctly. &nbsp;As far as I can tell, none of the existing GDAL drivers are dealing with this. &nbsp;It seems like there are three options for reading -</div>
<div><br class="webkit-block-placeholder"></div><div>1) Pre-parse the entire file to get the line starting locations (ie: fill in panLineOffset[] in advance). &nbsp;This has the advantage of allowing the files to be very large, since it&#39;s not loading large amounts of data into memory, but would, for practical purposes, mean reading the entire file twice. &nbsp;I can think of some tricks that could be done to reduce the number of reads if the entire raster isn&#39;t requested, but it would still probably require reading most of the file 2x.</div>
<div><br class="webkit-block-placeholder"></div><div>2) Read the file into memory and store the image in memory. &nbsp;This really restricts the size of file that could be read in, since it&#39;d require the entire image to be held in memory.</div>
<div><br class="webkit-block-placeholder"></div><div>3) Read in the file upside down as it is now, and try to adjust the georeferencing to match and handle the flipping. &nbsp;This might be the most elegant approach, since it&#39;d make the driver more &quot;standard&quot; like the other drivers.</div>
<div><br class="webkit-block-placeholder"></div><div>For writing, I&#39;m not sure there is a good option. &nbsp;I&#39;m thinking the best approach would be to restrict it to the CreateCopy() form of object construction, since that would allow the file to be written out in a single pass even though it&#39;s &quot;upside down&quot;. &nbsp;This might be a good way to fix the GSBG driver as well, since it&#39;s writing upside down (even though it&#39;s reading correctly).</div>
<div><br class="webkit-block-placeholder"></div><div>As I said - We&#39;re in a bit of a rush to get this working correctly. &nbsp;I&#39;d be happy to work on implementing this and submitting patches, but I&#39;d like suggestions as to what approaches people like to have a functional driver. &nbsp;The Golden Surfer drivers have all been problematic for a while now, and I&#39;d like to get all three corrected here as soon as possible.</div>
<div><br class="webkit-block-placeholder"></div><div>Thanks,</div><div>Reed Copsey</div>