AAIGrid Issues - EW Bug #1505

[mclark@…]

There is a test suite available on the EarthWhere ftp server:  
ftp://ewdemo.earthwhere.com as AAIGrid.tgz, login is ftpuser, pw is 
earthwhere.  There are a number of issues associated with this:
1.  Please see the arcmap_metadata.txt file associated with this AAIGrid data 
(fyi-the hdr.adf file can be found in the knp_cc subdir).  It states the 
null/no data value is -128.  gdalinfo and image_info do not pick this value up, 
they state that the null/no data value is 255.  Even if the null/no data value 
is specified as -128 via the .omd file, this value does not get written when an 
output product is created.  Please see the .spec file and .asc files starting 
with the naming convention of ossimJob_3736 in the output subdir.  The output 
product (i.e. .asc file) states a null/no data value of -4503599627370496.  Why 
isn't the proper null/no data value of -128 kept on output?
2.  Please see the .asc and .txt files starting with the naming convention 
ossimJob_3736 in the output subdir.  The lower left Y coordinates in these 
files should be the same, or at least more similar.  The lower left Y 
coordinates in the .txt file represent the values that were passed to igen via 
the .spec file, so why is the output product's lower left Y off as much as it 
is?  This same issue can be seen in the other .jgw and .txt outputs produced 
when attempting to do Grayscale and Color output products for the same AOI from 
the same source file, .spec files provided for all of these also.
3.  The section of the AAIGrid source file that is subset into an output 
product should contain data other than 0s.  The source file, hdr.adf, can be 
found in the knp_cc subdir, and the output product, ossimJob_3736_319147.asc, 
can be found in the output subdir.  Why are all 0s output?  This same issue can 
be seen in the other .jpg output products that were created from the same 
source file and for the same AOI but for Grayscale and Color outputs rather 
than Raw Elevation, .spec files provided for all of these also.

This issue is EarthWhere's #4 to be addressed.

[potts@…]

The spec files did not have valid input files for the image handler. For example:  /data/4_1/ArcASCIIGrid/
usgs_1/info is not a valid file name and should have pointed to /data/4_1/ArcASCIIGrid/usgs_1/knp_cc/
hdr.adf


Doing this created good product outputs.

[mclark@…]

I agree that images are now produced, however there are still a few issues when 
generating raw elevation output to an output type of gdal_AAIGrid.  Please 
reference the spec file ossimJob_3736_606716.spec to reproduce these issues 
with the source data.  The issues are:

1.  The no data value is not kept.  A no data value of -128 was specified in 
the .omd file by using cmm --null -128 hdr.adf.  When the raw elevation output 
is created it states a no data value of 255.  Interestingly enough, the null 
value in the .geom file is 255.  Is this where the value gets pulled from when 
using igen with the spec file, i.e. the .geom file rather than the .omd file?  
If so, is there a way to override this value in the .geom file when it is 
created, or to override it in the .spec file?

2.  The lower left coordinate value is off in the output file.  The .spec file 
contains a lower left y coordinate value of 36.84177686173473, whereas the .asc 
output product file contains a lower left y coordinate value of 36.841526769273.

[potts@…]

Problem 1 

where no data value is getting read was caused by an invalid .omd file.  The speparator was an = and 
should have been a :

Was:

band1.max_value=95.000000000000000
band1.min_value=0.000000000000000
band1.null_value=-128

and should have been:

band1.max_value:95.000000000000000
band1.min_value:0.000000000000000
band1.null_value:-128

If the omd file is removed the data type that is returned is a byte type so the -128 is really invalid.  The 
gdalinfo and image_info returns a byte sclara type for this particular dataset.

Problem 2

The cut would have to be on a view boundary in order for the image_info to report the same result as 
the cut in the igen spec file.  The grounds points are mapped to image space for the cut and the image 
space isa a discrete sample.  The tie point that is saved is the center of pixel.  There are an infinite 
number (well to the precision of double points) that lie within a single pixel and all would yield the 
same result.  The ony way it would be the same is to be snapped to a view boundardy and then do a cut 
that is center of the pixel