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 } _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev