[gdal-dev] Strategies for non-standard ascii format drivers

[Reed Copsey, Jr.]

I was wondering if anybody has any suggestions for good strategies for
implementing ascii GDAL raster drivers.
I'm looking at reworking and correcting the GSAG driver (we need this up and
running ASAP here).  Unfortunately, it's an ascii file format where it's
specified with the lower left pixel first, instead of the upper left pixel.

I've been trying to figure out a good strategy to get this working
correctly.  As far as I can tell, none of the existing GDAL drivers are
dealing with this.  It seems like there are three options for reading -

1) Pre-parse the entire file to get the line starting locations (ie: fill in
panLineOffset[] in advance).  This has the advantage of allowing the files
to be very large, since it's not loading large amounts of data into memory,
but would, for practical purposes, mean reading the entire file twice.  I
can think of some tricks that could be done to reduce the number of reads if
the entire raster isn't requested, but it would still probably require
reading most of the file 2x.

2) Read the file into memory and store the image in memory.  This really
restricts the size of file that could be read in, since it'd require the
entire image to be held in memory.

3) Read in the file upside down as it is now, and try to adjust the
georeferencing to match and handle the flipping.  This might be the most
elegant approach, since it'd make the driver more "standard" like the other
drivers.

For writing, I'm not sure there is a good option.  I'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's "upside down".  This might be a good way to fix the
GSBG driver as well, since it's writing upside down (even though it's
reading correctly).

As I said - We're in a bit of a rush to get this working correctly.  I'd be
happy to work on implementing this and submitting patches, but I'd like
suggestions as to what approaches people like to have a functional driver.
 The Golden Surfer drivers have all been problematic for a while now, and
I'd like to get all three corrected here as soon as possible.

Thanks,
Reed Copsey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20080205/877f42cc/attachment.html