Erdas File Import

[Wang Song]

Tom:

	I try to answer your question briefly here. If you require more details,
please write me a mail. Hope this helps.

> 
> I am looking for some answers regarding GRASS raster files
> created using i.in.erdas.  I received some enhanced panchromatic
> SPOTview quads (with SPOT's permission) in *.lan format, which I
> was later informed was from ERDAS.  I was successful in using
> i.in.erdas to create the cell file, used r.support, and was able
> to view the files, create postscripts, etc.

	Most SPOTView products are distributed in BIL format with 
the header information stored in separate file. If your file was
confirmed in ERDAS (7.3 version) ".lan" format, it should be pretty 
straight forward with "i.in.erdas". In your situation (single band),
The ".lan" file could be understood as 128 header on top of a raw
uncompressed GRASS cell file. Both i.in.erdas and i.in.other could
do this.
  
> 
> However, the GRASS cell file, which I assume is supposed to be in
> BIL file format, don't seem the correct size.  The GRASS manual
> says that the cell file size should be the number of rows times
> the number of pixels times 1 byte.  My cell file is larger than
> that by about 7,000 bytes. 

	The GRASS cell file has two optional format: raw binary format
(uncompressed) and run length encoding format (compressed). In either
case, GRASS cell file doesn't contain any header info in it. When you
output GRASS cell to other softwares (ERDAS, PCI, etc.), make sure your
cell file is in uncompressed format. Since you only has one GRASS cell
file, it doesn't matter that you called it BIL or BSQ, they are same
in your case.
 
> 
> I then imported that cell file into another image processing
> software (Easi-Pace v 5.0) as a BIL file format, and it came in,
> but not correctly.  It was apparent that at the top of the image
> created there is a bunch of garbage pixels, which makes me
> believe that there was header information in the GRASS cell file. 

	I guess that you used IMAGERD command to read in GRASS file.
Two things you may want to check. (1) make sure GRASS file is uncompressed.
(2) Make sure that you have exactly same num of rows/cols and resolution
in both GRASS and PCI. I mean exactly same including decimal digits.
ROUND-OFF mathematics would not work for raster convertion (pay 
special attention to spatial resolutions).

> 
> My question is, is this extra data header data from the .lan file
> in the GRASS cell file?  If so, is there anyway to get rid of
> this data, or to create another cell file without this data? 
> (This problem of file transfers will correct itself when we get
> V.5.2 of EASI-PACE, which is supposed to seamlessly read GRASS
> files). 

	i.in.erdas gets rid of ".lan" header automatically. Also
i.tape.other could be used to read in ".lan" file. (Don't have to
read from a tape drive). PCI EASI-PACE IMAGERD command could read
GRASS uncompressed cell file straight forward, no headers.
 
> 
> Another question.  I received data for each SPOT quad also,
> including the top left and bottom right x and y coordinates (in
> UTM 11) and the number of rows and columns, and pixel size (10
> meter).  Using simple mathematics, the top left corner of the
> file given is the top left corner of the top left pixel, and the
> bottom right corner of the file is the bottom right corner of the
> bottom right pixel.  In GRASS, is the top left corner of the file
> the top left corner of the pixel, or the center of the top left
> pixel?  I think it uses the middle of the pixel, because to get
> the SPOT image into EASI-PACE correctly (or at least with north
> going up) I had to increase the number of columns by one (from
> 1195 pixels in a row to 1196).  Also, the cellhd file in GRASS 
> has the top left and bottom right off by 5 meters.  

	 I guess that you are right about this. This is why GRASS
setup an initial image window with each coordinates offset by a half
pixel. You should be able to do this by using i.tape.other to
read in your ".lan" file into a X-Y coordinate LOCATION with following
default window setting:

north: -0.5,  south:-1000.5    west: 0.5    east:1000.5

	The reason that Y coordinates use negative numbers is because
that GRASS requires north coordinate greater than south and the origin
setting in GRASS is at lower left corner.....

-------------------
Song Wang
CAST/NCRI
12 Ozark Hall
Univ. of Arkansas
Fayetteville, AR 72701

> 
> Thanks for any help or advice.  
>  
> Tom Hawkins
> California Department of Water Resources