[GRASSLIST:1810] Re: r.in.bin

[kevin cross]

Yan:

    I have posed this question before but not with this detail.
I get a moat around the central valley of California, and
since I live here I know it doesn't exist!.  Basically it is the
same problem you are having, though I think I recalled
negative values all the way to about -450.

    I thought it might be the gtopo30 data so I tried the
GLOBE data. Same results, although I get the impression
from the material that GLOBE data is at least partially
derived from gtopo30 data.  The basic difference seems
to be that GLOBE data has a bit more quality checking
on the dataset and was developed on type machines.
GTOPO30 data is for UNIX systems. If your running
LINUX on INTEL (or other lil'endian chip) you don't
need to byteswap GLOBE data.

    If you find a solution I would GREATLY
appreciate you're sharing it!!.

    GRASS is otherwise an excellent tool.  I am still learning
many of it's features and the GUI. The GUI interface
sometimes has a bug or two in the parameter names and
values that are presented to begin child/shelled processes.
But you can normally figure this out by looking closely at
the error and then reading the documentation on the help
screens for the process you are trying to implement.

    I haven't read the current GRASS bug reports and
FAQ's so I haven't formally presented them as bugs to the
GRASS team.  I think the GUI is used enough that this
would be almost common knowledge.

Kevin

----- Original Message -----
From: "Yan Fitterer" <y.fitterer at ram.ac.uk>
To: <grasslist at baylor.edu>
Sent: Thursday, April 26, 2001 12:57 PM
Subject: [GRASSLIST:1775] r.in.bin


> Hi All,
>
> 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)
>
> Totally baffled at this - please help!
>
> Thanks in advance
>
> Yan
> PS - I know the values are otherwise read OK, as the sea is -9999 as
expected.
>
>
> --
> Yan Fitterer
> IT Manager, Royal Academy of Music
> E-mail : y.fitterer at ram.ac.uk
> Phone (+44) 20 7873 7365 Fax (+44) 20 7873 7364
>
>
>