[GRASS5] Re: [GRASSLIST:1775] r.in.bin

GRASS GRASS developer
1

Yan Fitterer wrote:

First, congratulations for a briliant program.

My problem (is it a bug?):
I'm getting a gtopo30 file from:
http://edcdaac.usgs.gov/gtopo30/w020n90.html

The I try to import the .DEM file into Grass with r.in.bin

I get all OK (byte swap, signed integer, etc...) except that at a level of
about 110 (going up a hill for ex.), the z (altitude) values suddently go to
-120, and then increase in line with the terrain.

Has anybody seen that behaviour?

I'm running 5.0 beta 11 on Linux RH 7.0 (2.2.16 kernel)

I get conflicting results.

If I import it into an x-y location, I seem to get the behaviour which
you describe. OTOH, If I import it into the appropriate lat-lon
location, I don't have any problems (the only areas with negative
altitude are where I would expect, i.e. Holland).

NB: I'm running the latest 5.0 CVS, and there's a bug where it ignores
the rows/cols parameters if you specify N/E/S/W (I've fixed this, but
CVS is down right now so I can't commit it).

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

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

2

On Thu, Apr 26, 2001 at 10:45:37PM +0100, Glynn Clements wrote:

Yan Fitterer wrote:

> First, congratulations for a briliant program.
>
> My problem (is it a bug?):
> I'm getting a gtopo30 file from:
> http://edcdaac.usgs.gov/gtopo30/w020n90.html
>
> The I try to import the .DEM file into Grass with r.in.bin
>
> I get all OK (byte swap, signed integer, etc...) except that at a level of
> about 110 (going up a hill for ex.), the z (altitude) values suddently go to
> -120, and then increase in line with the terrain.
>
> Has anybody seen that behaviour?
>
> I'm running 5.0 beta 11 on Linux RH 7.0 (2.2.16 kernel)

I get conflicting results.

If I import it into an x-y location, I seem to get the behaviour which
you describe. OTOH, If I import it into the appropriate lat-lon
location, I don't have any problems (the only areas with negative
altitude are where I would expect, i.e. Holland).

NB: I'm running the latest 5.0 CVS, and there's a bug where it ignores
the rows/cols parameters if you specify N/E/S/W (I've fixed this, but
CVS is down right now so I can't commit it).

Glynn,

Bob did much mork on r.in.bin, I think he will respond later this day (after
getting up in Canada). Before commiting your bugfix:
The idea was that you can import (AVHRR, xy) data by simply entering rows and
cols. It would be nice if your fix could keep this feature.

Just a remark,

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

3

Markus Neteler wrote:

On Thu, Apr 26, 2001 at 10:45:37PM +0100, Glynn Clements wrote:
>
> Yan Fitterer wrote:
>
> > First, congratulations for a briliant program.
> >
> > My problem (is it a bug?):
> > I'm getting a gtopo30 file from:
> > http://edcdaac.usgs.gov/gtopo30/w020n90.html
> >
> > The I try to import the .DEM file into Grass with r.in.bin
> >
> > I get all OK (byte swap, signed integer, etc...) except that at a level of
> > about 110 (going up a hill for ex.), the z (altitude) values suddently go to
> > -120, and then increase in line with the terrain.
> >
> > Has anybody seen that behaviour?
> >
> > I'm running 5.0 beta 11 on Linux RH 7.0 (2.2.16 kernel)
>
> I get conflicting results.
>
> If I import it into an x-y location, I seem to get the behaviour which
> you describe. OTOH, If I import it into the appropriate lat-lon
> location, I don't have any problems (the only areas with negative
> altitude are where I would expect, i.e. Holland).
>
> NB: I'm running the latest 5.0 CVS, and there's a bug where it ignores
> the rows/cols parameters if you specify N/E/S/W (I've fixed this, but
> CVS is down right now so I can't commit it).

Glynn,

Bob did much mork on r.in.bin, I think he will respond later this day (after
getting up in Canada). Before commiting your bugfix:
The idea was that you can import (AVHRR, xy) data by simply entering rows and
cols. It would be nice if your fix could keep this feature.

Just a remark,

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Hello,

I am not sure I know what the bug is that is being described above. It
sounds like there might be a problem with how the signed integers are
converted. This was a routine that I took from the original r.in.bin and
never really tested too much.

However, if it works with one projection and not another (XY & Lat Lon),
then there is probably something else wrong.

Have you applied your fix to the CVS yet Glynn? If not you could email
it to me and I will take a look to see if something jogs my memory.

--
Bob Covill

Tekmap Consulting
P.O. Box 2016 Fall River, N.S.
B2T 1K6
Canada

E-Mail: bcovill@tekmap.ns.ca
Phone: 902-860-1496
Fax: 902-860-1498

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

4

On Fri, Apr 27, 2001 at 09:30:19AM -0300, Bob Covill wrote:

I am not sure I know what the bug is that is being described above. It
sounds like there might be a problem with how the signed integers are
converted. This was a routine that I took from the original r.in.bin and
never really tested too much.

However, if it works with one projection and not another (XY & Lat Lon),
then there is probably something else wrong.

Have you applied your fix to the CVS yet Glynn? If not you could email
it to me and I will take a look to see if something jogs my memory.

I have also a problem with r.in.bin and urgently need your bug fix
(or I need to fix it on my own).

$r.in.bin -s input=/opt/geo-data/globe/l10g output=globe bytes=2 north=0 south=-50 east=180 west=90 r=6000 c=10800
Illegal row value

This error is relatively new. It was not there a while ago.

Jan

--
Jan-Oliver Wagner http://intevation.de/~jan/

Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

5

Jan-Oliver Wagner wrote:

On Fri, Apr 27, 2001 at 09:30:19AM -0300, Bob Covill wrote:
> I am not sure I know what the bug is that is being described above. It
> sounds like there might be a problem with how the signed integers are
> converted. This was a routine that I took from the original r.in.bin and
> never really tested too much.
>
> However, if it works with one projection and not another (XY & Lat Lon),
> then there is probably something else wrong.
>
> Have you applied your fix to the CVS yet Glynn? If not you could email
> it to me and I will take a look to see if something jogs my memory.

I have also a problem with r.in.bin and urgently need your bug fix
(or I need to fix it on my own).

$r.in.bin -s input=/opt/geo-data/globe/l10g output=globe bytes=2 north=0 south=-50 east=180 west=90 r=6000 c=10800
Illegal row value

This error is relatively new. It was not there a while ago.

Jan

--
Jan-Oliver Wagner http://intevation.de/~jan/

Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Jan,

I have just been duplicating the error you mention above. The problem
seems to be in the auto calculation of rows cols etc.

For a test leave the rows and cols off of the command line, and see if
your data is imported. The program will report the calculated rows and
columns which will hopefully be the same as above.

Let me know if this works, which should help track down the problem.

--
Bob Covill

Tekmap Consulting
P.O. Box 2016 Fall River, N.S.
B2T 1K6
Canada

E-Mail: bcovill@tekmap.ns.ca
Phone: 902-860-1496
Fax: 902-860-1498

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

6

Hi Bob,

On Fri, Apr 27, 2001 at 12:19:12PM -0300, Bob Covill wrote:

I have just been duplicating the error you mention above. The problem
seems to be in the auto calculation of rows cols etc.

For a test leave the rows and cols off of the command line, and see if
your data is imported. The program will report the calculated rows and
columns which will hopefully be the same as above.

I tried this already, but it did not work (default rows was 50).

Let me know if this works, which should help track down the problem.

I have just reverted the main.c to rev 1.5 and it works again.
This 'solution' is fine for me right now since I am already late with
preparing a grass rpm for the new FreeGIS CD.

Jan

--
Jan-Oliver Wagner http://intevation.de/~jan/

Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

7

Bob Covill wrote:

I am not sure I know what the bug is that is being described above. It
sounds like there might be a problem with how the signed integers are
converted. This was a routine that I took from the original r.in.bin and
never really tested too much.

However, if it works with one projection and not another (XY & Lat Lon),
then there is probably something else wrong.

Have you applied your fix to the CVS yet Glynn? If not you could email
it to me and I will take a look to see if something jogs my memory.

My fix doesn't fix Jan-Oliver's problem (negative altitudes in an x-y
location).

All I did was to change the parameter-handling logic so that the case
where you specify all six of N/S/E/W/rows/cols worked (I couldn't
correctly import into a lat-long location without this).

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

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

8

I wrote:

If I import it into an x-y location, I seem to get the behaviour which
you describe. OTOH, If I import it into the appropriate lat-lon
location, I don't have any problems (the only areas with negative
altitude are where I would expect, i.e. Holland).

Scratch that; I've just re-done it and now I get the problem
regardless of they coordinate system.

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

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

9

Jan-Oliver Wagner wrote:

> I have just been duplicating the error you mention above. The problem
> seems to be in the auto calculation of rows cols etc.
>
> For a test leave the rows and cols off of the command line, and see if
> your data is imported. The program will report the calculated rows and
> columns which will hopefully be the same as above.

I tried this already, but it did not work (default rows was 50).

Yep; you need to be able to specify all of the parameters if the image
resolution doesn't match the location's resolution.

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

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

10

Glynn Clements wrote:

> I am not sure I know what the bug is that is being described above. It
> sounds like there might be a problem with how the signed integers are
> converted. This was a routine that I took from the original r.in.bin and
> never really tested too much.
>
> However, if it works with one projection and not another (XY & Lat Lon),
> then there is probably something else wrong.
>
> Have you applied your fix to the CVS yet Glynn? If not you could email
> it to me and I will take a look to see if something jogs my memory.

My fix doesn't fix Jan-Oliver's problem (negative altitudes in an x-y
location).

Sorry, it doesn't fix Yan Fitterer's problem; it probably does fix
Jan-Oliver's problem.

It has now been comitted to CVS.

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

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

11

Glynn Clements wrote:

Yan Fitterer wrote:

> First, congratulations for a briliant program.
>
> My problem (is it a bug?):
> I'm getting a gtopo30 file from:
> http://edcdaac.usgs.gov/gtopo30/w020n90.html
>
> The I try to import the .DEM file into Grass with r.in.bin
>
> I get all OK (byte swap, signed integer, etc...) except that at a level of
> about 110 (going up a hill for ex.), the z (altitude) values suddently go to
> -120, and then increase in line with the terrain.
>
> Has anybody seen that behaviour?
>
> I'm running 5.0 beta 11 on Linux RH 7.0 (2.2.16 kernel)

Hello,

I finaly got around to downloading and importing the DEM from the above
link. I have been able to import the data successfully into both a Lat
Long and XY database using the following command:

r.in.bin input=W020N90.DEM output=W020N90.DEM north=90 south=40 east=20
west=-20 r=6000 c=4800 anull=-9999 bytes=2

I imported it on both a SUN and Linux with byteswapping set accordingly.
The minmax reported from r.describe is the correct -30 to 4536. You may
have been getting incorrect results with the -s flag which I believe was
intended for data with a range of -127 to 127. I have never actually
seen any data that requires this flag??

I imported it with the changes made to r.in.bin as discovered by Jan
earlier.

These changes are from line 211 in main.c

..
        if (! G_scan_easting (parm.east->answer, &cellhd.east,
cellhd.proj)) return 1;
        if (! G_scan_easting (parm.west->answer, &cellhd.west,
cellhd.proj)) return 1;
insert >>> if (sscanf(parm.rows->answer,"%d%1s",&cellhd.rows,
dummy) != 1) return 1;
insert>>> if (sscanf(parm.cols->answer,"%d%1s",&cellhd.cols,
dummy) != 1) return 1;
        }
        if (no_dim == 0 && no_coord == 1) { /* Get rows and cols only */
        if (sscanf(parm.rows->answer,"%d%1s",&cellhd.rows, dummy) != 1
        || cellhd.rows <= 0) return 1;
..

Hopefully this helps.

--
Bob Covill

Tekmap Consulting
P.O. Box 2016 Fall River, N.S.
B2T 1K6
Canada

E-Mail: bcovill@tekmap.ns.ca
Phone: 902-860-1496
Fax: 902-860-1498

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

12

Bob Covill wrote:

> > First, congratulations for a briliant program.
> >
> > My problem (is it a bug?):
> > I'm getting a gtopo30 file from:
> > http://edcdaac.usgs.gov/gtopo30/w020n90.html
> >
> > The I try to import the .DEM file into Grass with r.in.bin
> >
> > I get all OK (byte swap, signed integer, etc...) except that at a level of
> > about 110 (going up a hill for ex.), the z (altitude) values suddently go to
> > -120, and then increase in line with the terrain.
> >
> > Has anybody seen that behaviour?
> >
> > I'm running 5.0 beta 11 on Linux RH 7.0 (2.2.16 kernel)

I finaly got around to downloading and importing the DEM from the above
link. I have been able to import the data successfully into both a Lat
Long and XY database using the following command:

r.in.bin input=W020N90.DEM output=W020N90.DEM north=90 south=40 east=20
west=-20 r=6000 c=4800 anull=-9999 bytes=2

I imported it on both a SUN and Linux with byteswapping set accordingly.
The minmax reported from r.describe is the correct -30 to 4536. You may
have been getting incorrect results with the -s flag which I believe was
intended for data with a range of -127 to 127.

That would explain it; the case which worked for me could have been
when I "forgot" the -s flag.

I suggest that it be disabled for importing 2-/4-byte data; the code
is:

  if (sflag && cell[col] > 127) cell[col] -= 256;

which certainly doesn't implement "signed" behaviour on anything other
than bytes, but it is being used for all sizes.

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

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

13

On Fri, Apr 27, 2001 at 08:53:15PM +0100, Glynn Clements wrote:

Sorry, it doesn't fix Yan Fitterer's problem; it probably does fix
Jan-Oliver's problem.

It has now been comitted to CVS.

thanks!

Jan

--
Jan-Oliver Wagner http://intevation.de/~jan/

Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'