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

[Yan Fitterer]

Kevin,

I solved my (import) problem by going to v4. They DO say that 5 is _beta_ - so 
beware! I saw on the last message from Glynn that she copied Bob Covil on the 
message, so I guess that he'll deal with it when he's got a minute.

In any case, we didn't use the output of Grass, as the quality of the topology 
lines didn't match what we could get elsewhere. The input worked OK under Grass 
4 though.

Sorry I don't have a proper solution, but I'm not (really) a programmer - so I 
won't be able to go in the code and sort it out!

Bye
Yan

----  On 4 May 2001, at 11:02, kevin cross wrote:  ----

> 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
> >
> >
> >
> 


-- 
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