[gdal-dev] gdalinfo -stats Misses invalid data value in ENVI header

[Peter Willis]

Hello,

I have a curious problem with 'gdalinfo'   (gdal version 1.9.0 ).

I have an input ENVI file with the following .HDR entry:

 data ignore value = -9.99000000e+002

gdalinfo for the IMG file provides stats that exclude all values  -999.0 as
expected.

I then create a masked output file using 'gdal_rasterize' from that input
file once again using -999.0 as the mask value.
'gdal_rasterize' produces an ENVI format output with an accompanying .HDR
file.

The resulting 'gdal_rasterize' HDR  *does not* contain the previous 'data
ignore value'  entry. This is something that should 
be fixed in future versions of that utility. The work around is, of course,
to simply concatenate the 'data ignore value'
to the end of the HDR file. This is a quick step:

echo ""  >> myfile.hdr
echo "data ignore value = -9.99000000+e2"  >> myfile.hdr 
echo ""  >> myfile.hdr

[NOTE: There are some other issues with ENVI HDR generation in GDAL that
should also be addressed but I won't go into those here.]

PROBLEM: 
gdalinfo does not parse the value for the concatenated header entry if it is
placed at the end of the HDR file.
In fact, the HDR file may be edited to move the entry to a location near the
top of the file whereby it remains unacknowledged by gdalinfo.

QUESTION:
Does gdalinfo expect the header entries to be in a specific order?

I have appended some parsing information to the end of this email.
You are probably aware of most, if not all, of this information.

Thanks,

Peter


------ENVI TEXT HEADERS-------

The ENVI header file is not an 'ordered' data file. 
The entries may appear in any order. 
The generic format for entries is:

<NAME> = <VALUE>[EOL]


Equals  '='  normally appears on the same line as <NAME> without intervening
carriage return characters.
It is normal for '=' to be preceded by one space character although not
necessary.  
Equals  '=' is considered to be the primary delimiter between <NAME>  and
<VALUE>.

---NAMES---
'<Name>'  may be any string without carriage returns, and the <NAME> may
include space characters.

All names (and values) are trimmed of preceding and trailing white space
characters at parse time.
TAB    '\t'  is not normally used as whitespace but is parsed as though it
were a space ' ' character.

---VALUES---

'<VALUE>'  may be a singular value (ie: a number or a string with no
whitespace ) or a 'list'  bounded by curly braces  { }. 

Examples of singular string values would be:

Interleave = BSQ
Sensor type = Unknown
Wavelength units = nanometers

where 'BSQ' , 'Unknown', and 'nanometers' are singular strings containing no
whitespace characters.

In the context of the <VALUE> strings containing necessary whitespace should
be encoded as a list. String values may contain carriage return characters.
The comma ','  is considered to 
be the default delimiter for list type data.

Ie: 

My List = {   some string data ,  another string data , yet another data
string , 
 etc data strings ad infinitum 
 }


Number formats associated with <VALUE>

Singular Integers:

My Integer = 9
My Integer = -99
My Integer = 0

Singular Reals:

My Real =  0.9
My Real =  .9
My Real =  -9.000000000+e8

Lists of numbers:

My Integer List = {
	1 , 2 , 3,  4 , 5 , 6
}

My Real List = {
	1.0 , -2.00e+2 , 3.0e-4,  4.0 , .5 , 6.00001
}