[GRASSLIST:1819] Re: r.in.bin
y.fitterer at ram.ac.uk
Tue May 8 04:45:24 EDT 2001
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
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!
---- On 4 May 2001, at 11:02, kevin cross wrote: ----
> 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.
> ----- 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
> > -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
> > --
> > 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
IT Manager, Royal Academy of Music
E-mail : y.fitterer at ram.ac.uk
Phone (+44) 20 7873 7365 Fax (+44) 20 7873 7364
More information about the grass-user