[gdal-dev] ENVI driver patch

Wilson Waters "gdal-dev-list-mail" at alintech.com.au
Wed May 14 02:13:21 PDT 2014


Hi Even,

I just created ticket http://trac.osgeo.org/gdal/ticket/5467

I'm no expert in ENVI files but found the only way to get the .hdr files 
working in the ENVI application was to change the "Unknown" map info 
projection to "Arbitrary". The best reference I've found for this is 
http://www.exelisvis.com/docs/ENVI_MAP_INFO_CREATE.html

Regards,
Wilson

On 14/05/2014 4:45 PM, Even Rouault wrote:
> 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.


More information about the gdal-dev mailing list