hi,
i want to install the latest version of grass6.3,on 32 bit processor i.e i386 fedora
On grass.itc.it the tar file is for 64bit.
Can anyone tell me the exact path from where i can install latest update version og grass6.3
Thanking you
On Nov 30, 2007 12:34 PM, <ec.jkd@tpcsed.com> wrote:
hi,
i want to install the latest version of grass6.3,on 32 bit processor i.e i386 fedora
On grass.itc.it the tar file is for 64bit.
Can anyone tell me the exact path from where i can install latest update version og grass6.3
What about source at: http://grass.itc.it/grass63/source/grass-6.3.0RC2.tar.gz
or CVS.
You may have to read
http://grass.gdf-hannover.de/wiki/Compile_and_Install for getting help
on compiling from source code.
Thanking you
--
Dr. H.S.Rai
http://hs.raiandrai.com/
Hi List,
I am experimenting with r.in/out.xyz. As far as I understand, r.out.xyz take a
cell center coordinate and writes this and the associated z value into
something(stout/file).
Now I have recognised while importing the output with r.in.xyz that there is a
different cell count with different rasters while the region is the same.
I have a region with 670480 cells (986 x 680). Each test raster (srtm data and
derived slope from srtm) says the same with r.info.
Now I get different messages from r.in.xyz for the cell count: The correct
number of cells for the srtm data (670480 ) but another for the slope raster
(667152). Checking the output files, the number of lines differ: 67048 lines
for the srtm and 667152 lines for the slope raster.
I am sorting the output by the z value in order to create classes of equal
area and the import from the slope raster doesn't work as expected, there's a
large amount of cells associated to the * - value (Null I presume) instead of
the classes I defined.
From the manual I read that NULL values are not exported by r.out.xyz. Is
there maybe a problem with 0 (degree) values from slope?
Greetings Frank
Frank Broniewski wrote:
I am experimenting with r.in/out.xyz. As far as I understand, r.out.xyz take a
cell center coordinate and writes this and the associated z value into
something(stout/file).
Now I have recognised while importing the output with r.in.xyz that there is a
different cell count with different rasters while the region is the same.I have a region with 670480 cells (986 x 680). Each test raster (srtm data and
derived slope from srtm) says the same with r.info.Now I get different messages from r.in.xyz for the cell count: The correct
number of cells for the srtm data (670480 ) but another for the slope raster
(667152). Checking the output files, the number of lines differ: 67048 lines
for the srtm and 667152 lines for the slope raster.I am sorting the output by the z value in order to create classes of equal
area and the import from the slope raster doesn't work as expected, there's a
large amount of cells associated to the * - value (Null I presume) instead of
the classes I defined.From the manual I read that NULL values are not exported by r.out.xyz. Is
there maybe a problem with 0 (degree) values from slope?
667152 = 984 * 678 = (986-2) * (680-2)
IIRC, r.slope.aspect needs a 3x3 window to compute the slope, so it
cannot compute the slope for the boundary cells, so the result has a
1-cell-wide border of null cells.
--
Glynn Clements <glynn@gclements.plus.com>
Frank Broniewski wrote:
I am experimenting with r.in/out.xyz. As far as I understand, r.out.xyz take
a cell center coordinate and writes this and the associated z value into
something(stout/file).
Now I have recognised while importing the output with r.in.xyz that there is
a different cell count with different rasters while the region is the same.
[Glynn answered this probably comes from r.slope.aspect]
I am sorting the output by the z value in order to create classes of equal
area
perhaps 'r.univar -e percentile=' for percentile in n*(100/num classes) makes
this much easier?
Hamish
____________________________________________________________________________________
Get easy, one-click access to your favorites.
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs
Am Samstag, 1. Dezember 2007 00:08:08 schrieb Hamish:
Frank Broniewski wrote:
> I am experimenting with r.in/out.xyz. As far as I understand, r.out.xyz
> take a cell center coordinate and writes this and the associated z value
> into something(stout/file).
> Now I have recognised while importing the output with r.in.xyz that there
> is a different cell count with different rasters while the region is the
> same.[Glynn answered this probably comes from r.slope.aspect]
> I am sorting the output by the z value in order to create classes of
> equal areaperhaps 'r.univar -e percentile=' for percentile in n*(100/num classes)
makes this much easier?Hamish
___________________________________________________________________________
_________ Get easy, one-click access to your favorites.
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs
I tried the percentile option from r.univar already, but this only works good
for normal distributed data. I got quite nice (but not perfect) results for
my terrain model, but really no good results for slope and other similar
distributed data with a single very high peak.
Counting cells for equal area is more robust towards the z-value than any
statisticial method I tried so far, although I always have trouble when it
comes to statistics in general 
I am just writing a perl script for this, so that things can be automated as
much as possible.
r.slope.aspect seems really to blame for the null values. I just overlayed the
slope map over the terrain map with the d.rast overlay option and there is
indeed a 1-cell wide boundary. I would have never figured that out.
Thanks alot.
Frank