[GRASS5] problems with i.in.erdas in GRASS 5.3

GRASS GRASS developer
,
1

I just tried use i.in.erdas to read in a multiband *.lan file of LandsatTM images. It didn't work and produced the error listed below. With i.in.erdas out of commission, there seems to be no way to get multiband images into GRASS. I tried r.in.gdal (I have 1.1.9 installed) and it wouldn't read *.lan images or geotiffs in multiband format. Any suggestions?

I am using GRASS 5.3 (12 January 04 build) on a Mac OSX 10.2.8 system. The *.lan file is a version 7.4 format file of 7 Landsat TM bands, with a size of 375 Mb. Note below that it does recognize the file and read the header correctly.

  - - - i.in.erdas error - - -

Swapping Enabled
HEAD74
pack type ------------- 0 == 8 bit/pixel
number bands----------- 7
number cols,rows------- 7768, 7225
starting coordinate --- 1, 1
map type (int, float) - 1
number classes -------- 0
unit-type: ------------ N (N=None A=Acre H=Hectare O=Other)
area per pixel -------- 1.000000
map coordinate -------- 67089.500000, 4414792.500000
pixel size ------------ 28.500000, 28.500000

UTM coordinates used remember that the UTM zone is unknown
and must be set using the grass support function on the header file.
WARNING: G_set_fp_type() can only be called with FCELL_TYPE or DCELL_TYPE
WARNING: G_set_fp_type() can only be called with FCELL_TYPE or DCELL_TYPE
WARNING: G_set_fp_type() can only be called with FCELL_TYPE or DCELL_TYPE
WARNING: G_set_fp_type() can only be called with FCELL_TYPE or DCELL_TYPE
WARNING: G_set_fp_type() can only be called with FCELL_TYPE or DCELL_TYPE
WARNING: G_set_fp_type() can only be called with FCELL_TYPE or DCELL_TYPE
WARNING: G_set_fp_type() can only be called with FCELL_TYPE or DCELL_TYPE

____________________
C. Michael Barton, Professor
Department of Anthropology
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671

2

Michael Barton wrote:

I just tried use i.in.erdas to read in a multiband *.lan file of
LandsatTM images. It didn't work and produced the error listed below.
With i.in.erdas out of commission, there seems to be no way to get
multiband images into GRASS. I tried r.in.gdal (I have 1.1.9 installed)
and it wouldn't read *.lan images or geotiffs in multiband format. Any
suggestions?

I am using GRASS 5.3 (12 January 04 build) on a Mac OSX 10.2.8 system.
The *.lan file is a version 7.4 format file of 7 Landsat TM bands, with
a size of 375 Mb. Note below that it does recognize the file and read
the header correctly.

  - - - i.in.erdas error - - -

Swapping Enabled
HEAD74
pack type ------------- 0 == 8 bit/pixel
number bands----------- 7
number cols,rows------- 7768, 7225
starting coordinate --- 1, 1
map type (int, float) - 1
number classes -------- 0
unit-type: ------------ N (N=None A=Acre H=Hectare O=Other)
area per pixel -------- 1.000000
map coordinate -------- 67089.500000, 4414792.500000
pixel size ------------ 28.500000, 28.500000

UTM coordinates used remember that the UTM zone is unknown
and must be set using the grass support function on the header file.
WARNING: G_set_fp_type() can only be called with FCELL_TYPE or
DCELL_TYPE

i.in.erdas doesn't like the map type field, and appears not to like
floating-point at all:

  if(erdashd.maptyp == 0) /* integer data */
    data_type = CELL_TYPE;
  if(erdashd.maptyp == 99) { /* floating-point data */
    data_type = FCELL_TYPE;
    G_fatal_error("Floating point import doesn't work yet.");
  }

As neither of these two conditions are met, data_type ends up as -1,
which isn't a valid map type.

Do you know how map type 1 differs from map type 0?

--
Glynn Clements <glynn.clements@virgin.net>

3

Glynn Clements wrote:

> I just tried use i.in.erdas to read in a multiband *.lan file of
> LandsatTM images. It didn't work and produced the error listed below.
> With i.in.erdas out of commission, there seems to be no way to get
> multiband images into GRASS. I tried r.in.gdal (I have 1.1.9 installed)
> and it wouldn't read *.lan images or geotiffs in multiband format. Any
> suggestions?
>
> I am using GRASS 5.3 (12 January 04 build) on a Mac OSX 10.2.8 system.
> The *.lan file is a version 7.4 format file of 7 Landsat TM bands, with
> a size of 375 Mb. Note below that it does recognize the file and read
> the header correctly.
>
> - - - i.in.erdas error - - -
>
> Swapping Enabled
> HEAD74
> pack type ------------- 0 == 8 bit/pixel
> number bands----------- 7
> number cols,rows------- 7768, 7225
> starting coordinate --- 1, 1
> map type (int, float) - 1
> number classes -------- 0
> unit-type: ------------ N (N=None A=Acre H=Hectare O=Other)
> area per pixel -------- 1.000000
> map coordinate -------- 67089.500000, 4414792.500000
> pixel size ------------ 28.500000, 28.500000
>
> UTM coordinates used remember that the UTM zone is unknown
> and must be set using the grass support function on the header file.
> WARNING: G_set_fp_type() can only be called with FCELL_TYPE or
> DCELL_TYPE

i.in.erdas doesn't like the map type field, and appears not to like
floating-point at all:

  if(erdashd.maptyp == 0) /* integer data */
    data_type = CELL_TYPE;
  if(erdashd.maptyp == 99) { /* floating-point data */
    data_type = FCELL_TYPE;
    G_fatal_error("Floating point import doesn't work yet.");
  }

As neither of these two conditions are met, data_type ends up as -1,
which isn't a valid map type.

Do you know how map type 1 differs from map type 0?

This is a bug which was introduced in:

----------------------------
revision 1.9
date: 2003/09/18 16:54:57; author: markus; state: Exp; lines: +58 -23
added potential support for floating point maps, but I don't get the pixel values decoded, so still disabled.
----------------------------

[Note 5.0.0 to 5.0.3 inclusive all use revision 1.7 of this file, so
this only applies to 5.3.]

AFAICT, the maptyp field is actually the projection type:

  if ((erdashd.maptyp == 1) || (mapcoord->answer)) {
    if (set_uwindow(&erdashd,firstrow,lastrow,firstcol,lastcol) <0) {
      fprintf(stderr,"Error in setting GRASS window cordsn");
      exit(0);
    }
  }
  else
    if (set_window(firstrow,lastrow,firstcol,lastcol) <0) {
      fprintf(stderr,"Error in setting GRASS window cordsn");
      exit(0);
    }

[set_uwindow() is UTM, set_window() is XY.]

The code which I cited in my original reply should probably look like
this:

  if(erdashd.maptyp == 99) { /* floating-point data */
    data_type = FCELL_TYPE;
    G_fatal_error("Floating point import doesn't work yet.");
  }

  data_type = CELL_TYPE;

I've committed this to CVS.

--
Glynn Clements <glynn.clements@virgin.net>

4

On Mon, Jan 26, 2004 at 09:52:13AM +0000, Glynn Clements wrote:

Glynn Clements wrote:

> > I just tried use i.in.erdas to read in a multiband *.lan file of
> > LandsatTM images. It didn't work and produced the error listed below.
> > With i.in.erdas out of commission, there seems to be no way to get
> > multiband images into GRASS. I tried r.in.gdal (I have 1.1.9 installed)
> > and it wouldn't read *.lan images or geotiffs in multiband format. Any
> > suggestions?
> >
> > I am using GRASS 5.3 (12 January 04 build) on a Mac OSX 10.2.8 system.
> > The *.lan file is a version 7.4 format file of 7 Landsat TM bands, with
> > a size of 375 Mb. Note below that it does recognize the file and read
> > the header correctly.
> >
> > - - - i.in.erdas error - - -
> >
> > Swapping Enabled
> > HEAD74
> > pack type ------------- 0 == 8 bit/pixel
> > number bands----------- 7
> > number cols,rows------- 7768, 7225
> > starting coordinate --- 1, 1
> > map type (int, float) - 1
> > number classes -------- 0
> > unit-type: ------------ N (N=None A=Acre H=Hectare O=Other)
> > area per pixel -------- 1.000000
> > map coordinate -------- 67089.500000, 4414792.500000
> > pixel size ------------ 28.500000, 28.500000
> >
> > UTM coordinates used remember that the UTM zone is unknown
> > and must be set using the grass support function on the header file.
> > WARNING: G_set_fp_type() can only be called with FCELL_TYPE or
> > DCELL_TYPE
>
> i.in.erdas doesn't like the map type field, and appears not to like
> floating-point at all:
>
> if(erdashd.maptyp == 0) /* integer data */
> data_type = CELL_TYPE;
> if(erdashd.maptyp == 99) { /* floating-point data */
> data_type = FCELL_TYPE;
> G_fatal_error("Floating point import doesn't work yet.");
> }
>
> As neither of these two conditions are met, data_type ends up as -1,
> which isn't a valid map type.
>
> Do you know how map type 1 differs from map type 0?

This is a bug which was introduced in:

----------------------------
revision 1.9
date: 2003/09/18 16:54:57; author: markus; state: Exp; lines: +58 -23
added potential support for floating point maps, but I don't get the pixel values decoded, so still disabled.
----------------------------

Thanks for pointing that out.
Sorry for the bug.

[Note 5.0.0 to 5.0.3 inclusive all use revision 1.7 of this file, so
this only applies to 5.3.]

AFAICT, the maptyp field is actually the projection type:

  if ((erdashd.maptyp == 1) || (mapcoord->answer)) {
    if (set_uwindow(&erdashd,firstrow,lastrow,firstcol,lastcol) <0) {
      fprintf(stderr,"Error in setting GRASS window cordsn");
      exit(0);
    }
  }
  else
    if (set_window(firstrow,lastrow,firstcol,lastcol) <0) {
      fprintf(stderr,"Error in setting GRASS window cordsn");
      exit(0);
    }

[set_uwindow() is UTM, set_window() is XY.]

I found right now some docs:
http://www2.erdas.com/SupportSite/documentation/files/erdas7xfiles.pdf

In fact maptyp is the projection (the bug was introduced by reading other,
wrong documents).
Page 10 states:
"
The first number is the projection type. Valid values are numbers 1-20,
which correspond to the supported map projection types, listed below:
Type Projection
1 UTM
2 State Plane
[...]

It's not clear to me, how floating point LANs are read (that
was the motivation for my changes).

The module i.in.erdas seems to need an overhaul.
Or simply reverted to CVS version 1.8

Markus