[Gdal-dev] File extensions

[Ray Gardener]

You're welcome Matt. Hmm... well, if you're generating intermediate 
files only, then filenames shouldn't even matter. For drivers that 
process data which is contained in multiple files in a folder (e.g., 
GTOPO30, SDTS), I prefer the folder name instead and anything inside is 
a driver detail, so the files inside the folder can have their names 
processed by the driver. I think Frank had abstract dataset references 
as a design goal, but the drivers didn't really take him up on it 
(sigh). (I even allow for filenames to be URLs, because who's to say 
that a person picks something off their local storage. And if the URL is 
a zip file, then it's no biggie, because you know the real filetype and 
can then download/unzip to get the real data. A form of future 
proofing... it's entirely possible that future file I/O dialogs become 
generalized to browse local, remote, and Internet dataspaces).

But in practical terms, I understand that some GDAL drivers want 
extensions and/or one of the leaf filenames. I only got around that by 
wrapping GDAL in a higher abstraction, which could be overkill for a 
simple app. But if I understand you right, you're trying to have a 
generalized solution, so I think wrapping may be called for. I wouldn't 
mind pushing some stuff down to GDAL or having an official wrapper 
included with GDAL, but that's longer term of course, GDAL 2.0 if Frank 
wants to do that.

Ray


Matt Hanson wrote:
> Ray - thanks for the insight, it makes sense and now I understand why
> ENVI treats files the way it does (you always deal with the binary file,
> which can have any extension or none, then it looks for the hdr file
> rather then the other way around)
> 
> Frank - Thanks for the heads up on the Metadataitem for the extension.
> Didn't even think about the possibility of it existing in the driver.
> Makes sense.
> 
> The tricky think about my app is that I really don't know the format
> when I create it.   The user provides the output format, but not the
> filename!  The reason is that in this app there may not be a single
> output file.  Output files are created as intermediate files during
> processing and thus the filename is generated randomly, with no explicit
> knowledge of what the format is (though if it doesn't support Create an
> error is generated of course).   I'm actually using the boost filesystem
> libraries which provide filename parsing functions....getting the
> preferred extension from the driver sounds like the perfect solution.