[gdal-dev] ENVI driver patch

[Even Rouault]

Wilson,

at first sight, I'd say it looks reasonable, but could you post your below 
analysis, patch and samples files as a ticket ( 
http://trac.osgeo.org/gdal/newticket ) so that it doesn't get lost ?

But there's one thing I didn't understand well. In your patch, you changed 
"Unknown" to "Arbitrary" because that's what ENVI requires ?

Even

> Hi all,
> 
> I've been working with ENVI files lately and have come across a few
> issues. I'm hoping you can point out if I'm doing something wrong or if
> I should create a GDAL bug with the attached patch.
> 
> We found our ENVI .hdr files were being corrupted whenever opened in
> write mode with GDAL. No changes to the data or metadata are required to
> corrupt the file, simply opening the file in write mode was enough. I've
> attached example before and after .hdr files. These files have map info
> projection set to "Arbitrary" (we're not storing map data. It's long
> skinny images of underground drill core).
> 
> This is the process causing the corruption in ENVIDataset:
> 1) open envi file in read/write mode uses OPEN_EXISTING flag on .hdr
> 2) ENVIDataset::Open() doesn't understand "Arbitrary" projection so
> generates a "LOCAL_CS" projection string
> 3) close dataset causing ENVIDataset::FlushCache() to be called
> 4) FlushCache() re-writes hdr file as the bHeaderDirty was set in the
> Open() function. map info field is omitted for some reason?
> 5) FlushCache() overwrites the old hdr file without clearing first
> causing trailing data in the file
> 
> As far as I can tell there are four bugs in the ENVIDataset related to this
> 1) ENVIDataset::ProcessMapinfo() Doesn't understand the "Arbitrary"
> projection and defaults to LOCAL_CS - which is probably ok, but;
> 2) ENVIDataset::WriteProjectionInfo fails to write map info field when
> projection is LOCAL_CS
> 3) ENVIDataset::Open() causes bHeaderDirty to be set (should only happen
> when something external updates the image?)
> 4) ENVIDataset::FlushCache() should truncate existing file before
> overwriting
> 
> We're using GDAL 1.11 on windows, though I think the behaviour would be
> the same on any OS.
> 
> Any pointers on whether I'm doing the right thing and if I should submit
> a trac bug?
> 
> Cheers,
> Wilson.

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html