[Gdal-dev] Drivers for Golden Software Grid Formats (long)

[Kevin Locke]

Hello All,

I have recently written drivers for the Golden Software ASCII and
Binary Grid formats that includes read, write, create, delete, and
copy capabilities.  I was hoping to get some constructive criticism
and, if no major problems are present, that it could be considered for
inclusion in future releases of GDAL.

I have attached the diff against revision 10704 with my
changes/additions.  If this is not the preferred form for submissions,
please let me know.  [Correction:  Message got stuck waiting for
moderator approval so now the patch is downloadable from
http://kevinlocke.name/gdal/gdal-driver_for_gsg.patch ]

I have also accumulated a few questions during development that I
would very much appreciate input on from those who have the time.

First, is there a portable file truncate function?  I didn't see any
VSIFTruncate() or a commonly used alternative in existing drivers.  I
was envisioning something that would call fileno() then ftruncate() or
ftruncate64() on *nix systems and fileno() then _chsize() or
_chsize_s() on Windows systems, but I didn't see anything similar in
the source.  Also, is there a VSIFPrintfL() or similar function?

Next, I am concerned about how to best handle negative values in
positions 1 or 5 of the GeoTransform.  The grid formats that I am
working with always keep grid values in the same alignment (min X, min
Y in the upper left corner), so when SetGeoTransform() is called with
a negative value in these positions, what should be done?  At the
moment I just push it to the PAM SetGeoTransform() if possible and
error otherwise.  Would it make more sense to flip the rows and/or
columns in the file; in which case the data would have the arrangement
requested but the next call to GetGeoTransform() would still return
positive numbers for positions 1 and 5 of the transform?  This makes a
lot of sense to me (especially in order to translate from the Arc grid
formats), but would this break anything expecting successful
SetGeoTransform()s to mean that subsequent GetGeoTransform()s will
return those values?

The last question is somewhat less technical; both of these grid
formats record a minimum and maximum data value as part of the format.
This requires some solution for what to do when writing to the grid
file in cases where the minimum or maximum may be overwritten.  My
solution was to store the minimum and maximum value for each row
(since blocks correspond to grid rows) in memory.  This avoids any
need for file scans during writes that overwrite minimum or maximum
values, but it does consume a bit of memory and require an initial
scan of the file (which I delay until the first write operation).  Is
this acceptable or is there some other preferred method of handling
such values?

Thanks for your time and input,
Kevin