Re: [GRASS-user] how to calculate area of voronoi polygons considering the boundary of the catchment

[Moritz Lennert]

On 27/07/09 21:38, daljeet wrote:

Hi,

I have the point rainfall data of a region. Few of the point data are
outside the region of interest.

I am making the voronoi polygons using the v.voronoi on the vector imported
from this point ascii (x,y,z) data.

The polygon may be fully inside the region of interest or may be partially
outside the region of interest.

In case of the polygon which is partially outside the region of interest,
the area which is inside the region of interest need to be calculated. How
to calculate this?


- Define region of interest with g.region.
- Create polygon of region with v.in.region.
- Overlay voronoi polygons with region polygon with v.overlay operator=AND


How can i calculate the area of voronoi polygon.


v.report or v.to.db

Moritz
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Re: announcement of strahler stream order analysis

[Margherita Di Leo]

Hi Jarek,
I downloaded and compiled r.stream without problems but i'm afraid it 
does not work:


r.stream dir=drain...@ex_20 stream=bas...@ex_20 strahler=strahler 
shreeve=shreve class=class


dirs, 3
streams, 4
Reading maps...
*** glibc detected *** r.stream: corrupted double-linked list: 
0x0067c2c0 ***

=== Backtrace: =
/lib/libc.so.6[0x7f77dfb86322]
/lib/libc.so.6(cfree+0x8c)[0x7f77dfb89c1c]
r.stream(createMaps+0x353)[0x401df3]
r.stream(main+0x1c1)[0x402011]
/lib/libc.so.6(__libc_start_main+0xf4)[0x7f77dfb301c4]
r.stream[0x401619]
=== Memory map: 
0040-00404000 r-xp  08:03 5955752 
/usr/local/grass-6.5.svn/bin/r.stream
00603000-00604000 rw-p 3000 08:03 5955752 
/usr/local/grass-6.5.svn/bin/r.stream

00604000-41e9f000 rw-p 00604000 00:00 0 [heap]
7f77d800-7f77d8021000 rw-p 7f77d800 00:00 0
7f77d8021000-7f77dc00 ---p 7f77d8021000 00:00 0
7f77df70-7f77df70d000 r-xp  08:03 4071544 /lib/libgcc_s.so.1
7f77df70d000-7f77df90d000 ---p d000 08:03 4071544 /lib/libgcc_s.so.1
7f77df90d000-7f77df90e000 rw-p d000 08:03 4071544 /lib/libgcc_s.so.1
7f77df90e000-7f77df91 r-xp  08:03 6677083 /lib/libdl-2.7.so
7f77df91-7f77dfb1 ---p 2000 08:03 6677083 /lib/libdl-2.7.so
7f77dfb1-7f77dfb12000 rw-p 2000 08:03 6677083 /lib/libdl-2.7.so
7f77dfb12000-7f77dfc6a000 r-xp  08:03 6677080 /lib/libc-2.7.so
7f77dfc6a000-7f77dfe6a000 ---p 00158000 08:03 6677080 /lib/libc-2.7.so
7f77dfe6a000-7f77dfe6d000 r--p 00158000 08:03 6677080 /lib/libc-2.7.so
7f77dfe6d000-7f77dfe6f000 rw-p 0015b000 08:03 6677080 /lib/libc-2.7.so
7f77dfe6f000-7f77dfe74000 rw-p 7f77dfe6f000 00:00 0
7f77dfe74000-7f77dfef4000 r-xp  08:03 6677084 /lib/libm-2.7.so
7f77dfef4000-7f77e00f3000 ---p 0008 08:03 6677084 /lib/libm-2.7.so
7f77e00f3000-7f77e00f5000 rw-p 0007f000 08:03 6677084 /lib/libm-2.7.so
7f77e00f5000-7f77e010b000 r-xp  08:03 6490242 
/usr/lib/libz.so.1.2.3.3
7f77e010b000-7f77e030b000 ---p 00016000 08:03 6490242 
/usr/lib/libz.so.1.2.3.3
7f77e030b000-7f77e030c000 rw-p 00016000 08:03 6490242 
/usr/lib/libz.so.1.2.3.3
7f77e030c000-7f77e0314000 r-xp  08:03 984193 
/usr/local/grass-6.5.svn/lib/libgrass_datetime.6.5.svn.so
7f77e0314000-7f77e0513000 ---p 8000 08:03 984193 
/usr/local/grass-6.5.svn/lib/libgrass_datetime.6.5.svn.so
7f77e0513000-7f77e0514000 rw-p 7000 08:03 984193 
/usr/local/grass-6.5.svn/lib/libgrass_datetime.6.5.svn.so
7f77e0514000-7f77e0567000 r-xp  08:03 984236 
/usr/local/grass-6.5.svn/lib/libgrass_gis.6.5.svn.so
7f77e0567000-7f77e0766000 ---p 00053000 08:03 984236 
/usr/local/grass-6.5.svn/lib/libgrass_gis.6.5.svn.so
7f77e0766000-7f77e0769000 rw-p 00052000 08:03 984236 
/usr/local/grass-6.5.svn/lib/libgrass_gis.6.5.svn.so

7f77e0769000-7f77e077 rw-p 7f77e0769000 00:00 0
7f77e077-7f77e078d000 r-xp  08:03 6676548 /lib/ld-2.7.so
7f77e0926000-7f77e0965000 r--p  08:03 6521179 
/usr/lib/locale/en_GB.utf8/LC_CTYPE

7f77e0965000-7f77e0969000 rw-p 7f77e0965000 00:00 0
7f77e0982000-7f77e0983000 r--p  08:03 6521188 
/usr/lib/locale/en_GB.utf8/LC_MESSAGES/SYS_LC_MESSAGES
7f77e0983000-7f77e098a000 r--s  08:03 6496774 
/usr/lib/gconv/gconv-modules.cache

7f77e098a000-7f77e098d000 rw-p 7f77e098a000 00:00 0
7f77e098d000-7f77e098f000 rw-p 0001d000 08:03 6676548 /lib/ld-2.7.so
7fffe8979000-7fffe898e000 rw-p 7ffea000 00:00 0 [stack]
7fffe89fe000-7fffe8a0 r-xp 7fffe89fe000 00:00 0 [vdso]
ff60-ff601000 r-xp  00:00 0 [vsyscall]
Aborted



Hi list!

I just finish first version of new grass module r.stream. Module is regular
Grass module, written in C an has no addational dependencies. It was
compiled with GRASS65 devel  downloaded in last  two week. Source code you
can find here:

http://heretic.livenet.pl/heretic/r.stream.tar.gz

Module compiles and seems to work. Analysis was tested only on one dataset.

To compile it copy r.streams directory to your grassXX../raster/  cd
r.stream run make and make install

What module calculate:
- strahler stream order
- shreeve stream magnitude
- class of topological elements of drainage networks

Module use r.watershed outputs: SDF flow direction and SDF stream network.


Analysis of r.stream shall be run on same regions setings as r.watershed. If
no, run g.region rast=your_dir_file first. For now module do not check if
region and rasters are identical. It is planned to add in nearest feature.
It also do not check if dirs and streams are SDF result. Threre are no
addational description. It will be added after testing.

It works only on cells data. Floating points data are not allowed (and have
no sense).

Module is quite fast. 3000 x3000 cells all three analysis runs no more than
30 s. on AMD 3800 2GB, Ubuntu 8.04

Module is part of comprehensive project which will add full Horton analysis
and some addational terrrains analysis to Grass. More details in the
feature. Any cooperation is welcome.

[GRASS-user] i.maxlik and 'Signature 1 is not valid (ill-conditioned) - ignored'

[Thomas Becker]

Hi listers,

I am using GRASS64 on Debian Lenny and I am getting warnings about 
ill-conditioned signatures. As usual the sigfiles are created by i.cluster and 
I do not know why the first signature is ignored.

I googled the warning but haven't found a solution or workaround for this.

Cheers, Thomas
-- 
Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Re: announcement of strahler stream order analysis

[stephen sefick]

It works fine on my machine.  Mac OS X, compilied addon and compilied
GRASS from scratch.  The strahler output also looks sensable.  I do
have a question, though.  Say I have my own delineated streams with
another method, but in raster format- will this still work?  And is
there an easy way to a vector out of a raster stream network?

Stephen Sefick

On Tue, Jul 28, 2009 at 4:32 AM, Margherita Di Leo wrote:
> Hi Jarek,
> I downloaded and compiled r.stream without problems but i'm afraid it does
> not work:
>
> r.stream dir=drain...@ex_20 stream=bas...@ex_20 strahler=strahler
> shreeve=shreve class=class
>
> dirs, 3
> streams, 4
> Reading maps...
> *** glibc detected *** r.stream: corrupted double-linked list:
> 0x0067c2c0 ***
> === Backtrace: =
> /lib/libc.so.6[0x7f77dfb86322]
> /lib/libc.so.6(cfree+0x8c)[0x7f77dfb89c1c]
> r.stream(createMaps+0x353)[0x401df3]
> r.stream(main+0x1c1)[0x402011]
> /lib/libc.so.6(__libc_start_main+0xf4)[0x7f77dfb301c4]
> r.stream[0x401619]
> === Memory map: 
> 0040-00404000 r-xp  08:03 5955752
> /usr/local/grass-6.5.svn/bin/r.stream
> 00603000-00604000 rw-p 3000 08:03 5955752
> /usr/local/grass-6.5.svn/bin/r.stream
> 00604000-41e9f000 rw-p 00604000 00:00 0 [heap]
> 7f77d800-7f77d8021000 rw-p 7f77d800 00:00 0
> 7f77d8021000-7f77dc00 ---p 7f77d8021000 00:00 0
> 7f77df70-7f77df70d000 r-xp  08:03 4071544 /lib/libgcc_s.so.1
> 7f77df70d000-7f77df90d000 ---p d000 08:03 4071544 /lib/libgcc_s.so.1
> 7f77df90d000-7f77df90e000 rw-p d000 08:03 4071544 /lib/libgcc_s.so.1
> 7f77df90e000-7f77df91 r-xp  08:03 6677083 /lib/libdl-2.7.so
> 7f77df91-7f77dfb1 ---p 2000 08:03 6677083 /lib/libdl-2.7.so
> 7f77dfb1-7f77dfb12000 rw-p 2000 08:03 6677083 /lib/libdl-2.7.so
> 7f77dfb12000-7f77dfc6a000 r-xp  08:03 6677080 /lib/libc-2.7.so
> 7f77dfc6a000-7f77dfe6a000 ---p 00158000 08:03 6677080 /lib/libc-2.7.so
> 7f77dfe6a000-7f77dfe6d000 r--p 00158000 08:03 6677080 /lib/libc-2.7.so
> 7f77dfe6d000-7f77dfe6f000 rw-p 0015b000 08:03 6677080 /lib/libc-2.7.so
> 7f77dfe6f000-7f77dfe74000 rw-p 7f77dfe6f000 00:00 0
> 7f77dfe74000-7f77dfef4000 r-xp  08:03 6677084 /lib/libm-2.7.so
> 7f77dfef4000-7f77e00f3000 ---p 0008 08:03 6677084 /lib/libm-2.7.so
> 7f77e00f3000-7f77e00f5000 rw-p 0007f000 08:03 6677084 /lib/libm-2.7.so
> 7f77e00f5000-7f77e010b000 r-xp  08:03 6490242
> /usr/lib/libz.so.1.2.3.3
> 7f77e010b000-7f77e030b000 ---p 00016000 08:03 6490242
> /usr/lib/libz.so.1.2.3.3
> 7f77e030b000-7f77e030c000 rw-p 00016000 08:03 6490242
> /usr/lib/libz.so.1.2.3.3
> 7f77e030c000-7f77e0314000 r-xp  08:03 984193
> /usr/local/grass-6.5.svn/lib/libgrass_datetime.6.5.svn.so
> 7f77e0314000-7f77e0513000 ---p 8000 08:03 984193
> /usr/local/grass-6.5.svn/lib/libgrass_datetime.6.5.svn.so
> 7f77e0513000-7f77e0514000 rw-p 7000 08:03 984193
> /usr/local/grass-6.5.svn/lib/libgrass_datetime.6.5.svn.so
> 7f77e0514000-7f77e0567000 r-xp  08:03 984236
> /usr/local/grass-6.5.svn/lib/libgrass_gis.6.5.svn.so
> 7f77e0567000-7f77e0766000 ---p 00053000 08:03 984236
> /usr/local/grass-6.5.svn/lib/libgrass_gis.6.5.svn.so
> 7f77e0766000-7f77e0769000 rw-p 00052000 08:03 984236
> /usr/local/grass-6.5.svn/lib/libgrass_gis.6.5.svn.so
> 7f77e0769000-7f77e077 rw-p 7f77e0769000 00:00 0
> 7f77e077-7f77e078d000 r-xp  08:03 6676548 /lib/ld-2.7.so
> 7f77e0926000-7f77e0965000 r--p  08:03 6521179
> /usr/lib/locale/en_GB.utf8/LC_CTYPE
> 7f77e0965000-7f77e0969000 rw-p 7f77e0965000 00:00 0
> 7f77e0982000-7f77e0983000 r--p  08:03 6521188
> /usr/lib/locale/en_GB.utf8/LC_MESSAGES/SYS_LC_MESSAGES
> 7f77e0983000-7f77e098a000 r--s  08:03 6496774
> /usr/lib/gconv/gconv-modules.cache
> 7f77e098a000-7f77e098d000 rw-p 7f77e098a000 00:00 0
> 7f77e098d000-7f77e098f000 rw-p 0001d000 08:03 6676548 /lib/ld-2.7.so
> 7fffe8979000-7fffe898e000 rw-p 7ffea000 00:00 0 [stack]
> 7fffe89fe000-7fffe8a0 r-xp 7fffe89fe000 00:00 0 [vdso]
> ff60-ff601000 r-xp  00:00 0 [vsyscall]
> Aborted
>
>
 Hi list!

 I just finish first version of new grass module r.stream. Module is
 regular
 Grass module, written in C an has no addational dependencies. It was
 compiled with GRASS65 devel  downloaded in last  two week. Source code
 you
 can find here:

 http://heretic.livenet.pl/heretic/r.stream.tar.gz

 Module compiles and seems to work. Analysis was tested only on one
 dataset.

 To compile it copy r.streams directory to your grassXX../raster/  cd
 r.stream run make and make install

 What module calculate:
 - strahler stream order
 - shreeve stream magnitude
 - class of topological elements of drainage networks

 Module use r.watershed outputs: SDF flow direction and SDF stream
 network.


 Analysis of r.stream shall be run on same regions setings as
 r.watersh

Re: [GRASS-user] g.manual tries to run C:\Program Files\Internet Exporer\iexplore (the 'L' is missing from 'Explorer')

[Colin Nielsen]

The variable's value should point to a browser's exe, not the
index.html of the docs folder.

Given that, more odd behaviour of g.manual re the variable. When
running wingrass through an msys terminal (r37101)

The following all worked
export GRASS_HTML_BROWSER="c:\Program Files\Internet Explorer\iexplore.exe"
export GRASS_HTML_BROWSER=c:/Program\ Files/Internet\ Explorer/iexplore.exe
export GRASS_HTML_BROWSER=/c/Program\ Files/Internet\ Explorer/iexplore.exe
export GRASS_HTML_BROWSER="c:\Programs\Firefox\firefox.exe"
export GRASS_HTML_BROWSER="/c/Programs/Firefox/firefox.exe"

Except that it didn't release my terminal until iexplore.exe was
closed. This was not true when firefox was used instead, the terminal
was released without closing the program. (nb. on my system firefox is
in a directory without spaces but this shouldn't be the problem).

These failed:
export GRASS_HTML_BROWSER=/c/Program Files/Internet Explorer/iexplore.exe
export GRASS_HTML_BROWSER=c:\Program Files\Internet
Explorer\iexplore.exe (no quotes)
export GRASS_HTML_BROWSER=c:\Programs\Firefox\firefox.exe
("c:ProgramsFirefoxfirefox.exe: command not found")
export GRASS_HTML_BROWSER="file:///c/Program Files/Internet
Explorer/iexplore.exe"
export GRASS_HTML_BROWSER="/c/Program\ Files/Internet\ Explorer/iexplore.exe"
export GRASS_HTML_BROWSER="c:/Program\ Files/Internet\
Explorer/iexplore.exe" (c:/Program\ Files/Internet\
Explorer/iexplore.exe: No such file or directory)
export GRASS_HTML_BROWSER="\c\Program Files\Internet
Explorer\iexplore.exe" (not surprisingly)

This all seems very inconsistent, but in summary for msys:
1) URLs don't work
2) Regular windows paths are fine as long as they are in quotes
3) Unix paths are fine as long as they're not in quotes (unless there
are no spaces, then its ok) and use backslash on spaces.

However, for osgeo4w (non-msys) by putting the following in the
etc/ini/grass.bat:
This worked (though it didn't work above):
set GRASS_HTML_BROWSER=/c/Program Files/Internet Explorer/iexplore.exe

These did not work:
set GRASS_HTML_BROWSER="c:\Program Files\Internet Explorer\iexplore.exe"
set GRASS_HTML_BROWSER="c:\PROGRA~1\INTERN~1\iexplore.exe"
set GRASS_HTML_BROWSER=c:\PROGRA~1\INTERN~1\iexplore.exe
set GRASS_HTML_BROWSER=c:/Program\ Files/Internet\ Explorer/iexplore.exe
set GRASS_HTML_BROWSER=/c/Program\ Files/Internet\ Explorer/iexplore.exe

In sum, only a unix path with no quotes or space escapes will work.
This path format does not work in msys. There is no path format that I
found that works in both, clearly a problem.

> AFAICT, the "right" way to open files on Windows is to simply run them
> via the shell, e.g. pointing GRASS_HTML_BROWSER at a batch file
> containing:
>
>       �...@echo off
>        cmd /c "%1"
>
If you use "cmd /k" instead of "cmd /c" it should return the terminal
without having to terminate the command.
>
> For opening URLs:
>
>       �...@echo off
>        rundll32 url.dll,OpenURL "%1"
>
> This also appears to work with filenames, with both forward and
> backward slashes. However, it returns immediately, while "cmd /c ..."
> waits for the command to terminate.

I put the above into a batch file and it worked with the URL format,
unix and windows, but g.manual wouldn't run with this batch file with
it set as the value for GRASS_HTML_BROWSER

>
> When the command terminates depends upon the command. For Notepad, it
> means exiting Notepad. Firefox returns once it has displayed the page
> if it uses an existing instance, but waits until you exit it if it has
> to start a new instance.

Ahh this clears up the firefox exception above. However, when tested
on iexplore, it opens a new instance instead of adding it as a tab and
so won't return until that instance is closed.

>
> If we can confirm that the OpenURL approach works on most versions of
> Windows, we should use that for GRASS_HTML_BROWSER rather than
> iexplore.exe (particularly as init.bat currently uses a hard-coded
> pathname which will typically be wrong on non-English versions of
> Windows; hint: use %ProgramFiles% to get the "Program Files"
> directory).
>

I agree with Glynn, this is definitely the way to go if it can be
figured out since it would be better to use the user's preference,
already set in windows, for opening URLs. It worked on Vista, but only
by calling the batch file myself, not when it was set as the value of
GRASS_HTML_BROWSER. Perhaps because the g.manual script looks for an
exe specifically...

-Colin
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Re: announcement of strahler stream order analysis

[Annalisa Minelli]

I tried it just right now to see the strahler ordering and.. it works
greatly!
well done Jarek..:-)
I think I'm going to read the code because I've got to understand how did
you solved the problem of cleaning topology..
congratulations! great work!!!

Annalisa


2009/7/28 stephen sefick 

> It works fine on my machine.  Mac OS X, compilied addon and compilied
> GRASS from scratch.  The strahler output also looks sensable.  I do
> have a question, though.  Say I have my own delineated streams with
> another method, but in raster format- will this still work?  And is
> there an easy way to a vector out of a raster stream network?
>
> Stephen Sefick
>
> On Tue, Jul 28, 2009 at 4:32 AM, Margherita Di Leo
> wrote:
> > Hi Jarek,
> > I downloaded and compiled r.stream without problems but i'm afraid it
> does
> > not work:
> >
> > r.stream dir=drain...@ex_20 stream=bas...@ex_20 strahler=strahler
> > shreeve=shreve class=class
> >
> > dirs, 3
> > streams, 4
> > Reading maps...
> > *** glibc detected *** r.stream: corrupted double-linked list:
> > 0x0067c2c0 ***
> > === Backtrace: =
> > /lib/libc.so.6[0x7f77dfb86322]
> > /lib/libc.so.6(cfree+0x8c)[0x7f77dfb89c1c]
> > r.stream(createMaps+0x353)[0x401df3]
> > r.stream(main+0x1c1)[0x402011]
> > /lib/libc.so.6(__libc_start_main+0xf4)[0x7f77dfb301c4]
> > r.stream[0x401619]
> > === Memory map: 
> > 0040-00404000 r-xp  08:03 5955752
> > /usr/local/grass-6.5.svn/bin/r.stream
> > 00603000-00604000 rw-p 3000 08:03 5955752
> > /usr/local/grass-6.5.svn/bin/r.stream
> > 00604000-41e9f000 rw-p 00604000 00:00 0 [heap]
> > 7f77d800-7f77d8021000 rw-p 7f77d800 00:00 0
> > 7f77d8021000-7f77dc00 ---p 7f77d8021000 00:00 0
> > 7f77df70-7f77df70d000 r-xp  08:03 4071544 /lib/libgcc_s.so.1
> > 7f77df70d000-7f77df90d000 ---p d000 08:03 4071544 /lib/libgcc_s.so.1
> > 7f77df90d000-7f77df90e000 rw-p d000 08:03 4071544 /lib/libgcc_s.so.1
> > 7f77df90e000-7f77df91 r-xp  08:03 6677083 /lib/libdl-2.7.so
> > 7f77df91-7f77dfb1 ---p 2000 08:03 6677083 /lib/libdl-2.7.so
> > 7f77dfb1-7f77dfb12000 rw-p 2000 08:03 6677083 /lib/libdl-2.7.so
> > 7f77dfb12000-7f77dfc6a000 r-xp  08:03 6677080 /lib/libc-2.7.so
> > 7f77dfc6a000-7f77dfe6a000 ---p 00158000 08:03 6677080 /lib/libc-2.7.so
> > 7f77dfe6a000-7f77dfe6d000 r--p 00158000 08:03 6677080 /lib/libc-2.7.so
> > 7f77dfe6d000-7f77dfe6f000 rw-p 0015b000 08:03 6677080 /lib/libc-2.7.so
> > 7f77dfe6f000-7f77dfe74000 rw-p 7f77dfe6f000 00:00 0
> > 7f77dfe74000-7f77dfef4000 r-xp  08:03 6677084 /lib/libm-2.7.so
> > 7f77dfef4000-7f77e00f3000 ---p 0008 08:03 6677084 /lib/libm-2.7.so
> > 7f77e00f3000-7f77e00f5000 rw-p 0007f000 08:03 6677084 /lib/libm-2.7.so
> > 7f77e00f5000-7f77e010b000 r-xp  08:03 6490242
> > /usr/lib/libz.so.1.2.3.3
> > 7f77e010b000-7f77e030b000 ---p 00016000 08:03 6490242
> > /usr/lib/libz.so.1.2.3.3
> > 7f77e030b000-7f77e030c000 rw-p 00016000 08:03 6490242
> > /usr/lib/libz.so.1.2.3.3
> > 7f77e030c000-7f77e0314000 r-xp  08:03 984193
> > /usr/local/grass-6.5.svn/lib/libgrass_datetime.6.5.svn.so
> > 7f77e0314000-7f77e0513000 ---p 8000 08:03 984193
> > /usr/local/grass-6.5.svn/lib/libgrass_datetime.6.5.svn.so
> > 7f77e0513000-7f77e0514000 rw-p 7000 08:03 984193
> > /usr/local/grass-6.5.svn/lib/libgrass_datetime.6.5.svn.so
> > 7f77e0514000-7f77e0567000 r-xp  08:03 984236
> > /usr/local/grass-6.5.svn/lib/libgrass_gis.6.5.svn.so
> > 7f77e0567000-7f77e0766000 ---p 00053000 08:03 984236
> > /usr/local/grass-6.5.svn/lib/libgrass_gis.6.5.svn.so
> > 7f77e0766000-7f77e0769000 rw-p 00052000 08:03 984236
> > /usr/local/grass-6.5.svn/lib/libgrass_gis.6.5.svn.so
> > 7f77e0769000-7f77e077 rw-p 7f77e0769000 00:00 0
> > 7f77e077-7f77e078d000 r-xp  08:03 6676548 /lib/ld-2.7.so
> > 7f77e0926000-7f77e0965000 r--p  08:03 6521179
> > /usr/lib/locale/en_GB.utf8/LC_CTYPE
> > 7f77e0965000-7f77e0969000 rw-p 7f77e0965000 00:00 0
> > 7f77e0982000-7f77e0983000 r--p  08:03 6521188
> > /usr/lib/locale/en_GB.utf8/LC_MESSAGES/SYS_LC_MESSAGES
> > 7f77e0983000-7f77e098a000 r--s  08:03 6496774
> > /usr/lib/gconv/gconv-modules.cache
> > 7f77e098a000-7f77e098d000 rw-p 7f77e098a000 00:00 0
> > 7f77e098d000-7f77e098f000 rw-p 0001d000 08:03 6676548 /lib/ld-2.7.so
> > 7fffe8979000-7fffe898e000 rw-p 7ffea000 00:00 0 [stack]
> > 7fffe89fe000-7fffe8a0 r-xp 7fffe89fe000 00:00 0 [vdso]
> > ff60-ff601000 r-xp  00:00 0 [vsyscall]
> > Aborted
> >
> >
>  Hi list!
> 
>  I just finish first version of new grass module r.stream. Module is
>  regular
>  Grass module, written in C an has no addational dependencies. It was
>  compiled with GRASS65 devel  downloaded in last  two week. Source code
>  you
>  can find here:
> 
>  http://heretic.livenet.pl/heretic/r.stream.tar.gz
> 
>  Module compiles and seems to work. Analysis wa

Re: [GRASS-user] Re: announcement of strahler stream order analysis

[Annalisa Minelli]

2009/7/28 Annalisa Minelli 

> I tried it just right now to see the strahler ordering and.. it works
> greatly!
> well done Jarek..:-)
>

> I think I'm going to read the code because I've got to understand how did
> you solved the problem of cleaning topology..


oops.. forgive me.. you didn't use v.strahler so you don't pass through
vector format..
good idea!

>
> congratulations! great work!!!
>
> Annalisa
>
>
> 2009/7/28 stephen sefick 
>
> It works fine on my machine.  Mac OS X, compilied addon and compilied
>> GRASS from scratch.  The strahler output also looks sensable.  I do
>> have a question, though.  Say I have my own delineated streams with
>> another method, but in raster format- will this still work?  And is
>> there an easy way to a vector out of a raster stream network?
>>
>> Stephen Sefick
>>
>> On Tue, Jul 28, 2009 at 4:32 AM, Margherita Di Leo
>> wrote:
>> > Hi Jarek,
>> > I downloaded and compiled r.stream without problems but i'm afraid it
>> does
>> > not work:
>> >
>> > r.stream dir=drain...@ex_20 stream=bas...@ex_20 strahler=strahler
>> > shreeve=shreve class=class
>> >
>> > dirs, 3
>> > streams, 4
>> > Reading maps...
>> > *** glibc detected *** r.stream: corrupted double-linked list:
>> > 0x0067c2c0 ***
>> > === Backtrace: =
>> > /lib/libc.so.6[0x7f77dfb86322]
>> > /lib/libc.so.6(cfree+0x8c)[0x7f77dfb89c1c]
>> > r.stream(createMaps+0x353)[0x401df3]
>> > r.stream(main+0x1c1)[0x402011]
>> > /lib/libc.so.6(__libc_start_main+0xf4)[0x7f77dfb301c4]
>> > r.stream[0x401619]
>> > === Memory map: 
>> > 0040-00404000 r-xp  08:03 5955752
>> > /usr/local/grass-6.5.svn/bin/r.stream
>> > 00603000-00604000 rw-p 3000 08:03 5955752
>> > /usr/local/grass-6.5.svn/bin/r.stream
>> > 00604000-41e9f000 rw-p 00604000 00:00 0 [heap]
>> > 7f77d800-7f77d8021000 rw-p 7f77d800 00:00 0
>> > 7f77d8021000-7f77dc00 ---p 7f77d8021000 00:00 0
>> > 7f77df70-7f77df70d000 r-xp  08:03 4071544 /lib/libgcc_s.so.1
>> > 7f77df70d000-7f77df90d000 ---p d000 08:03 4071544 /lib/libgcc_s.so.1
>> > 7f77df90d000-7f77df90e000 rw-p d000 08:03 4071544 /lib/libgcc_s.so.1
>> > 7f77df90e000-7f77df91 r-xp  08:03 6677083 /lib/libdl-2.7.so
>> > 7f77df91-7f77dfb1 ---p 2000 08:03 6677083 /lib/libdl-2.7.so
>> > 7f77dfb1-7f77dfb12000 rw-p 2000 08:03 6677083 /lib/libdl-2.7.so
>> > 7f77dfb12000-7f77dfc6a000 r-xp  08:03 6677080 /lib/libc-2.7.so
>> > 7f77dfc6a000-7f77dfe6a000 ---p 00158000 08:03 6677080 /lib/libc-2.7.so
>> > 7f77dfe6a000-7f77dfe6d000 r--p 00158000 08:03 6677080 /lib/libc-2.7.so
>> > 7f77dfe6d000-7f77dfe6f000 rw-p 0015b000 08:03 6677080 /lib/libc-2.7.so
>> > 7f77dfe6f000-7f77dfe74000 rw-p 7f77dfe6f000 00:00 0
>> > 7f77dfe74000-7f77dfef4000 r-xp  08:03 6677084 /lib/libm-2.7.so
>> > 7f77dfef4000-7f77e00f3000 ---p 0008 08:03 6677084 /lib/libm-2.7.so
>> > 7f77e00f3000-7f77e00f5000 rw-p 0007f000 08:03 6677084 /lib/libm-2.7.so
>> > 7f77e00f5000-7f77e010b000 r-xp  08:03 6490242
>> > /usr/lib/libz.so.1.2.3.3
>> > 7f77e010b000-7f77e030b000 ---p 00016000 08:03 6490242
>> > /usr/lib/libz.so.1.2.3.3
>> > 7f77e030b000-7f77e030c000 rw-p 00016000 08:03 6490242
>> > /usr/lib/libz.so.1.2.3.3
>> > 7f77e030c000-7f77e0314000 r-xp  08:03 984193
>> > /usr/local/grass-6.5.svn/lib/libgrass_datetime.6.5.svn.so
>> > 7f77e0314000-7f77e0513000 ---p 8000 08:03 984193
>> > /usr/local/grass-6.5.svn/lib/libgrass_datetime.6.5.svn.so
>> > 7f77e0513000-7f77e0514000 rw-p 7000 08:03 984193
>> > /usr/local/grass-6.5.svn/lib/libgrass_datetime.6.5.svn.so
>> > 7f77e0514000-7f77e0567000 r-xp  08:03 984236
>> > /usr/local/grass-6.5.svn/lib/libgrass_gis.6.5.svn.so
>> > 7f77e0567000-7f77e0766000 ---p 00053000 08:03 984236
>> > /usr/local/grass-6.5.svn/lib/libgrass_gis.6.5.svn.so
>> > 7f77e0766000-7f77e0769000 rw-p 00052000 08:03 984236
>> > /usr/local/grass-6.5.svn/lib/libgrass_gis.6.5.svn.so
>> > 7f77e0769000-7f77e077 rw-p 7f77e0769000 00:00 0
>> > 7f77e077-7f77e078d000 r-xp  08:03 6676548 /lib/ld-2.7.so
>> > 7f77e0926000-7f77e0965000 r--p  08:03 6521179
>> > /usr/lib/locale/en_GB.utf8/LC_CTYPE
>> > 7f77e0965000-7f77e0969000 rw-p 7f77e0965000 00:00 0
>> > 7f77e0982000-7f77e0983000 r--p  08:03 6521188
>> > /usr/lib/locale/en_GB.utf8/LC_MESSAGES/SYS_LC_MESSAGES
>> > 7f77e0983000-7f77e098a000 r--s  08:03 6496774
>> > /usr/lib/gconv/gconv-modules.cache
>> > 7f77e098a000-7f77e098d000 rw-p 7f77e098a000 00:00 0
>> > 7f77e098d000-7f77e098f000 rw-p 0001d000 08:03 6676548 /lib/ld-2.7.so
>> > 7fffe8979000-7fffe898e000 rw-p 7ffea000 00:00 0 [stack]
>> > 7fffe89fe000-7fffe8a0 r-xp 7fffe89fe000 00:00 0 [vdso]
>> > ff60-ff601000 r-xp  00:00 0 [vsyscall]
>> > Aborted
>> >
>> >
>>  Hi list!
>> 
>>  I just finish first version of new grass module r.stream. Module is
>>  regular
>>  Grass module, written in C an has no addational dependenc

[GRASS-user] Changing resolution of a region after created Permanently

[stephen sefick]

I inadvertently typed 1 instead of 10 for the resolution of my mapset.
 Is there a way to permanently change this setting so that I don't
have to g.region everytime.  I want to limit my screwups.
thanks,

-- 
Stephen Sefick

Let's not spend our time and resources thinking about things that are
so little or so large that all they really do for us is puff us up and
make us feel like gods.  We are mammals, and have not exhausted the
annoying little problems of being mammals.

-K. Mullis
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] how to calculate area of voronoi polygons considering the boundary of the catchment

[daljeet]

Thanks Moritz.

I was wrongly using the term "region" in my question above. The requirement
is slightly different. Let me explain you in detail.

Inputs:
1. I have got the shapefile data of the country. I imported it using
v.in.ogr and extracted (v.extract) the vector of the desired "State" using
the "where" clause on the attribute which contains the name of the States.
So, this means i have the vector of a particular State and its area is
available using v.report.

2. I have also got the rainfall point data for the entire country in the
ascii file (x,y,z) for one week (z being the amount of rainfall)

Output required:
The volume of rainfall in the particular State (which is extracted above).

What I am doing:
I wanted to apply both, the Thiessen polygon and the Isohyetal Method to
calculate the volume  of rainfall.

Till now I am only working on Thiessen, and this is what i have done:
1. Imported the ascii rainfall point data (v.in.ascii) in the vector. This
is the vector for the whole country.
2. Created the voronoi vector on the above rainfall vector (v.voronoi)
3. Overlaid the voronoi rainfall vector of the country (from step 2) on the
extracted vector of the State (from input 1 above) with AND operator.

To verify, the sum of "area of each polygon" on the overlaid vector should
be same as area of the extracted State vector.

But this is not coming out to be same. The area of the voronoi overlaid map
is smaller than the area of the extracted shape of State.  One observation,
the voronoi overlaid map shows some white grids (both inside and at the
boundary of the map) and I suspect if these are being taken into account for
the area. Attached is the png image of the overlaid vectors. 

http://n2.nabble.com/file/n3342895/rainfall_theissen_png.png 

Any idea what could be my mistake. What I am doing which is making the loss
of area in the case of polygons.

Thanks
daljeet


Moritz Lennert wrote:
> 
> On 27/07/09 21:38, daljeet wrote:
>> Hi,
>> 
>> I have the point rainfall data of a region. Few of the point data are
>> outside the region of interest.
>> 
>> I am making the voronoi polygons using the v.voronoi on the vector
>> imported
>> from this point ascii (x,y,z) data.
>> 
>> The polygon may be fully inside the region of interest or may be
>> partially
>> outside the region of interest.
>> 
>> In case of the polygon which is partially outside the region of interest,
>> the area which is inside the region of interest need to be calculated.
>> How
>> to calculate this?
> 
> - Define region of interest with g.region.
> - Create polygon of region with v.in.region.
> - Overlay voronoi polygons with region polygon with v.overlay operator=AND
> 
>> How can i calculate the area of voronoi polygon.
> 
> v.report or v.to.db
> 
> Moritz
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
> 
> 

-- 
View this message in context: 
http://n2.nabble.com/how-to-calculate-area-of-voronoi-polygons-considering-the-boundary-of-the-catchment-tp3335923p3342895.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] prima di fare una figura da bischero

[Paolo Cavallini]

Hi all.
Sorry for crossposting - I do not know whether the problem resides in
grass or in qgis.
I'm following:
http://trac.osgeo.org/grass/wiki/HowToTestGrass6
All fine, but for the fact that the calculated ndvi map appears on grey
scale, and applying the ndvi color table does not change it.
/usr/lib/grass64/etc/colors/ndvi seems ok:

-1.000   5  24  82
-0.300   5  24  82
-0.180 255 255 255
 0.000 255 255 255
 0.025 206 197 180
 0.075 191 163 124
 0.125 179 174  96
 0.150 163 181  80
 0.175 144 170  60
 0.233 166 195  29
 0.266 135 183   3
 0.333 121 175   1
 0.366 101 163   0
 0.433  78 151   0
 0.466  43 132   4
 0.550   0 114   0
 0.650   0  90   1
 0.750   0  73   0
 0.850   0  56   0
 0.950   0  31   0
 1.000   0   0   0

I get these warnings:
Warning: QPainter::setPen: Painter not active
Warning: QPainter::setFont: Painter not active
Warning: QPainter::end: Painter not active, aborted
Warning: QPixmap::scaled: Pixmap is a null pixmap
Warning: Object::connect: No such signal
QgsRasterLayer::editingStarted() in
/storage/build/qgis_unstable/src/app/legend/qgslegend.cpp:548
Warning: Object::connect: No such signal
QgsRasterLayer::editingStopped() in
/storage/build/qgis_unstable/src/app/legend/qgslegend.cpp:549

But I do not know if they are relevant.
Any ideas on how to approach this?
All the best.
-- 
Paolo Cavallini: http://www.faunalia.it/pc

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Changing resolution of a region after created Permanently

[Milton Cezar Ribeiro]

Hi Stephen,

give a look at g.region --help
but if I am not sure you can try:
$ g.region res=10 -s (but I am not sure).

cheers

milton

2009/7/28 stephen sefick 

> I inadvertently typed 1 instead of 10 for the resolution of my mapset.
>  Is there a way to permanently change this setting so that I don't
> have to g.region everytime.  I want to limit my screwups.
> thanks,
>
> --
> Stephen Sefick
>
> Let's not spend our time and resources thinking about things that are
> so little or so large that all they really do for us is puff us up and
> make us feel like gods.  We are mammals, and have not exhausted the
> annoying little problems of being mammals.
>
>-K. Mullis
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] NDVI color table (it was a wrong object :) )

[Paolo Cavallini]

Paolo Cavallini ha scritto:
> Hi all.
> Sorry for crossposting - I do not know whether the problem resides in
> grass or in qgis.
> I'm following:
> http://trac.osgeo.org/grass/wiki/HowToTestGrass6
> All fine, but for the fact that the calculated ndvi map appears on grey
> scale, and applying the ndvi color table does not change it.
> /usr/lib/grass64/etc/colors/ndvi seems ok:
> 
> -1.000   5  24  82
> -0.300   5  24  82
> -0.180 255 255 255
>  0.000 255 255 255
>  0.025 206 197 180
>  0.075 191 163 124
>  0.125 179 174  96
>  0.150 163 181  80
>  0.175 144 170  60
>  0.233 166 195  29
>  0.266 135 183   3
>  0.333 121 175   1
>  0.366 101 163   0
>  0.433  78 151   0
>  0.466  43 132   4
>  0.550   0 114   0
>  0.650   0  90   1
>  0.750   0  73   0
>  0.850   0  56   0
>  0.950   0  31   0
>  1.000   0   0   0
> 
> I get these warnings:
> Warning: QPainter::setPen: Painter not active
> Warning: QPainter::setFont: Painter not active
> Warning: QPainter::end: Painter not active, aborted
> Warning: QPixmap::scaled: Pixmap is a null pixmap
> Warning: Object::connect: No such signal
> QgsRasterLayer::editingStarted() in
> /storage/build/qgis_unstable/src/app/legend/qgslegend.cpp:548
> Warning: Object::connect: No such signal
> QgsRasterLayer::editingStopped() in
> /storage/build/qgis_unstable/src/app/legend/qgslegend.cpp:549
> 
> But I do not know if they are relevant.
> Any ideas on how to approach this?
> All the best.


-- 
Paolo Cavallini: http://www.faunalia.it/pc
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] announcement of strahler stream order analysis

[Milton Cezar Ribeiro]

Hi Jarek

Can use this on a LatLong mapset where my unit is not meters?
Thanks for the effort!

milton

2009/7/26 Jarek Jasiewicz 

> Hi list!
>
> I just finish first version of new grass module r.stream. Module is regular
> Grass module, written in C an has no addational dependencies. It was
> compiled with GRASS65 devel  downloaded in last  two week. Source code you
> can find here:
>
> http://heretic.livenet.pl/heretic/r.stream.tar.gz
>
> Module compiles and seems to work. Analysis was tested only on one dataset.
>
> To compile it copy r.streams directory to your grassXX../raster/  cd
> r.stream run make and make install
>
> What module calculate:
> - strahler stream order
> - shreeve stream magnitude
> - class of topological elements of drainage networks
>
> Module use r.watershed outputs: SDF flow direction and SDF stream network.
>
>
> Analysis of r.stream shall be run on same regions setings as r.watershed.
> If no, run g.region rast=your_dir_file first. For now module do not check if
> region and rasters are identical. It is planned to add in nearest feature.
> It also do not check if dirs and streams are SDF result. Threre are no
> addational description. It will be added after testing.
>
> It works only on cells data. Floating points data are not allowed (and have
> no sense).
>
> Module is quite fast. 3000 x3000 cells all three analysis runs no more than
> 30 s. on AMD 3800 2GB, Ubuntu 8.04
>
> Module is part of comprehensive project which will add full Horton analysis
> and some addational terrrains analysis to Grass. More details in the
> feature. Any cooperation is welcome. The next module I plan is directional
> vectorisation of stream network.
>
> For now module is available only form web address pointed below. After
> testing and removing critical errors it will be added to grass add-ons (or
> maybe to main branch?).
>
> Any coments, improvements and critics is very welcome.
>
> More advanced Grass developers: Please check my code. Its funny, but I
> don't know C.
> General code is based on GRASS r.topindex module (by Keith Beven and Huidae
> Cho, strongly modified)
> Strahler stream order algorithm from Saga GIS (by Victor Olaya, modified)
> Shreeve stream magnitude and class of topological network are my own ideas
>
> Test and enjoy.
>
> Jarek Jasiewicz
> Adam Mickiewicz University, Poznan
> Geoecology and Geoinformation Institute
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] how to calculate area of voronoi polygons considering the boundary of the catchment

[Moritz Lennert]

On 28/07/09 16:02, daljeet wrote:

Thanks Moritz.

I was wrongly using the term "region" in my question above. The requirement
is slightly different. Let me explain you in detail.

Inputs:
1. I have got the shapefile data of the country. I imported it using
v.in.ogr and extracted (v.extract) the vector of the desired "State" using
the "where" clause on the attribute which contains the name of the States.
So, this means i have the vector of a particular State and its area is
available using v.report.

2. I have also got the rainfall point data for the entire country in the
ascii file (x,y,z) for one week (z being the amount of rainfall)

Output required:
The volume of rainfall in the particular State (which is extracted above).

What I am doing:
I wanted to apply both, the Thiessen polygon and the Isohyetal Method to
calculate the volume  of rainfall.

Till now I am only working on Thiessen, and this is what i have done:
1. Imported the ascii rainfall point data (v.in.ascii) in the vector. This
is the vector for the whole country.
2. Created the voronoi vector on the above rainfall vector (v.voronoi)
3. Overlaid the voronoi rainfall vector of the country (from step 2) on the
extracted vector of the State (from input 1 above) with AND operator.

To verify, the sum of "area of each polygon" on the overlaid vector should
be same as area of the extracted State vector.

But this is not coming out to be same. The area of the voronoi overlaid map
is smaller than the area of the extracted shape of State.  One observation,
the voronoi overlaid map shows some white grids (both inside and at the
boundary of the map) and I suspect if these are being taken into account for
the area. Attached is the png image of the overlaid vectors. 

http://n2.nabble.com/file/n3342895/rainfall_theissen_png.png 


Any idea what could be my mistake. What I am doing which is making the loss
of area in the case of polygons.


Sorry, cannot help you as such. Start by giving the exact command lines 
used with each command. Also show the results of v.voronoi. And how did 
you calculate the areas ?


Moritz
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] g.manual tries to run C:\Program Files\Internet Exporer\iexplore (the 'L' is missing from 'Explorer')

[Glynn Clements]

Colin Nielsen wrote:

> These failed:
> export GRASS_HTML_BROWSER=/c/Program Files/Internet Explorer/iexplore.exe
> export GRASS_HTML_BROWSER=c:\Program Files\Internet Explorer\iexplore.exe (no 
> quotes)

This is down to the "export" command terminating the value at the
first space.

> export GRASS_HTML_BROWSER=c:\Programs\Firefox\firefox.exe
> ("c:ProgramsFirefoxfirefox.exe: command not found")

This is down to the shell interpreting the \ character.

Both of the above issues go away if you use single quotes, e.g.:

export 'GRASS_HTML_BROWSER=c:\Programs\Firefox\firefox.exe'

Note that I'm not concerned with the syntax for specifying the
variable's value, but the syntax of its arguments.

> However, for osgeo4w (non-msys) by putting the following in the
> etc/ini/grass.bat:
> This worked (though it didn't work above):
> set GRASS_HTML_BROWSER=/c/Program Files/Internet Explorer/iexplore.exe

Windows' "set" command treats everything after the = as the value,
regardless of any spaces, whereas bash's "export" command terminates
the value at the first unquoted/unescaped space.

As for the /c/... syntax, that will work if $GRASS_HTML_BROWSER is
being used in a bash script (e.g. g.manual), but won't work natively.

> These did not work:
> set GRASS_HTML_BROWSER="c:\Program Files\Internet Explorer\iexplore.exe"
> set GRASS_HTML_BROWSER="c:\PROGRA~1\INTERN~1\iexplore.exe"

The "set" command will treat any quotes literally, as part of the
variable's value.

> set GRASS_HTML_BROWSER=c:\PROGRA~1\INTERN~1\iexplore.exe

I suspect that this is a case of the setting setting being "correct"
rather than MSys-compatible.

> set GRASS_HTML_BROWSER=c:/Program\ Files/Internet\ Explorer/iexplore.exe
> set GRASS_HTML_BROWSER=/c/Program\ Files/Internet\ Explorer/iexplore.exe

Forward slashes and MSys' /c/... syntax won't work in Windows' command
interpreter. MSys' bash will convert filename syntax if it recognises
it as such.

> In sum, only a unix path with no quotes or space escapes will work.
> This path format does not work in msys. There is no path format that I
> found that works in both, clearly a problem.

Indeed. This is why we're giving up on MSys for GRASS 7. It's
impossible to specify filenames which will work both in both MSys and
elsewhere.

> > For opening URLs:
> >
> >       �...@echo off
> >        rundll32 url.dll,OpenURL "%1"
> >
> > This also appears to work with filenames, with both forward and
> > backward slashes. However, it returns immediately, while "cmd /c ..."
> > waits for the command to terminate.
> 
> I put the above into a batch file and it worked with the URL format,
> unix and windows, but g.manual wouldn't run with this batch file with
> it set as the value for GRASS_HTML_BROWSER

Can you modify the script to print its arguments? And g.manual to
print out $GRASS_HTML_BROWSER.

-- 
Glynn Clements 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] i.atcorr with ASTER L1B

[Michael Perdue]

Hi Andy,
Yes, it looks like the right info for the SPOT sensor platforms.  
Iwave.cpp expects the data to be in 2.5nm increments so you will have  
to interpolate the data to the correct interval. It's a bit tedious,  
but is straight forward. I might be able to dedicate some time to it,  
but won't have any till the weekend now.

Cheers,
Mike

On 27-Jul-09, at 10:35 PM, andrew haywood wrote:


Hi All,

Im just adding to this discusssion. I would be interested in using  
i.atcorr with SPOT 2, 3, 4 and 5. I have found a file on the http://www.spotimage.com/web/en/555-spot-images.php 
 website that contains the spectral sensitivity data. Is this the  
same as the spectral profile? It looks like the data is in 5nm  
increments. Do i need to create 2.5nm increments or can i tell the  
function its in 5nm or 10nm increments?

Any help would be appreciated.
thanks
Andy



On 7/28/09, Michael Perdue  wrote:
Hi Markus,

Here is a text file with everything organized as I think it should  
be. I didn't add the this Iwave.cpp to submit a patch as I wasn't  
really sure how to modify GeomCond.cpp.


Cheers,
Mike

On 26-Jul-09, at 1:34 PM, Markus Neteler wrote:

Great - the header of Iwave.cpp contains instructions how to add
a new sensor like this.

thanks
Markus

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user





___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] announcement of strahler stream order analysis

[Jarek Jasiewicz]

try, I don't know I haven't  LL location to test it
but it shoud work
program do not use any inforamtuon about units and units conversion

Jarek

Milton Cezar Ribeiro pisze:

Hi Jarek

Can use this on a LatLong mapset where my unit is not meters?
Thanks for the effort!

milton

2009/7/26 Jarek Jasiewicz mailto:jar...@amu.edu.pl>>

Hi list!

I just finish first version of new grass module r.stream. Module
is regular Grass module, written in C an has no addational
dependencies. It was compiled with GRASS65 devel  downloaded in
last  two week. Source code you can find here:

http://heretic.livenet.pl/heretic/r.stream.tar.gz

Module compiles and seems to work. Analysis was tested only on one
dataset.

To compile it copy r.streams directory to your grassXX../raster/
 cd r.stream run make and make install

What module calculate:
- strahler stream order
- shreeve stream magnitude
- class of topological elements of drainage networks

Module use r.watershed outputs: SDF flow direction and SDF stream
network.


Analysis of r.stream shall be run on same regions setings as
r.watershed. If no, run g.region rast=your_dir_file first. For now
module do not check if region and rasters are identical. It is
planned to add in nearest feature. It also do not check if dirs
and streams are SDF result. Threre are no addational description.
It will be added after testing.

It works only on cells data. Floating points data are not allowed
(and have no sense).

Module is quite fast. 3000 x3000 cells all three analysis runs no
more than 30 s. on AMD 3800 2GB, Ubuntu 8.04

Module is part of comprehensive project which will add full Horton
analysis and some addational terrrains analysis to Grass. More
details in the feature. Any cooperation is welcome. The next
module I plan is directional vectorisation of stream network.

For now module is available only form web address pointed below.
After testing and removing critical errors it will be added to
grass add-ons (or maybe to main branch?).

Any coments, improvements and critics is very welcome.

More advanced Grass developers: Please check my code. Its funny,
but I don't know C.
General code is based on GRASS r.topindex module (by Keith Beven
and Huidae Cho, strongly modified)
Strahler stream order algorithm from Saga GIS (by Victor Olaya,
modified)
Shreeve stream magnitude and class of topological network are my
own ideas

Test and enjoy.

Jarek Jasiewicz
Adam Mickiewicz University, Poznan
Geoecology and Geoinformation Institute
___
grass-user mailing list
grass-user@lists.osgeo.org 
http://lists.osgeo.org/mailman/listinfo/grass-user



___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] announcement of strahler stream order analysis

[Carlos Grohmann]

Just tested in a LatLong region. works fine.

Carlos





2009/7/28 Jarek Jasiewicz :
> try, I don't know I haven't  LL location to test it
> but it shoud work
> program do not use any inforamtuon about units and units conversion
>
> Jarek
>
> Milton Cezar Ribeiro pisze:
>>
>> Hi Jarek
>>
>> Can use this on a LatLong mapset where my unit is not meters?
>> Thanks for the effort!
>>
>> milton
>>
>> 2009/7/26 Jarek Jasiewicz mailto:jar...@amu.edu.pl>>
>>
>>    Hi list!
>>
>>    I just finish first version of new grass module r.stream. Module
>>    is regular Grass module, written in C an has no addational
>>    dependencies. It was compiled with GRASS65 devel  downloaded in
>>    last  two week. Source code you can find here:
>>
>>    http://heretic.livenet.pl/heretic/r.stream.tar.gz
>>
>>    Module compiles and seems to work. Analysis was tested only on one
>>    dataset.
>>
>>    To compile it copy r.streams directory to your grassXX../raster/
>>     cd r.stream run make and make install
>>
>>    What module calculate:
>>    - strahler stream order
>>    - shreeve stream magnitude
>>    - class of topological elements of drainage networks
>>
>>    Module use r.watershed outputs: SDF flow direction and SDF stream
>>    network.
>>
>>
>>    Analysis of r.stream shall be run on same regions setings as
>>    r.watershed. If no, run g.region rast=your_dir_file first. For now
>>    module do not check if region and rasters are identical. It is
>>    planned to add in nearest feature. It also do not check if dirs
>>    and streams are SDF result. Threre are no addational description.
>>    It will be added after testing.
>>
>>    It works only on cells data. Floating points data are not allowed
>>    (and have no sense).
>>
>>    Module is quite fast. 3000 x3000 cells all three analysis runs no
>>    more than 30 s. on AMD 3800 2GB, Ubuntu 8.04
>>
>>    Module is part of comprehensive project which will add full Horton
>>    analysis and some addational terrrains analysis to Grass. More
>>    details in the feature. Any cooperation is welcome. The next
>>    module I plan is directional vectorisation of stream network.
>>
>>    For now module is available only form web address pointed below.
>>    After testing and removing critical errors it will be added to
>>    grass add-ons (or maybe to main branch?).
>>
>>    Any coments, improvements and critics is very welcome.
>>
>>    More advanced Grass developers: Please check my code. Its funny,
>>    but I don't know C.
>>    General code is based on GRASS r.topindex module (by Keith Beven
>>    and Huidae Cho, strongly modified)
>>    Strahler stream order algorithm from Saga GIS (by Victor Olaya,
>>    modified)
>>    Shreeve stream magnitude and class of topological network are my
>>    own ideas
>>
>>    Test and enjoy.
>>
>>    Jarek Jasiewicz
>>    Adam Mickiewicz University, Poznan
>>    Geoecology and Geoinformation Institute
>>    ___
>>    grass-user mailing list
>>    grass-u...@lists.osgeo.org 
>>    http://lists.osgeo.org/mailman/listinfo/grass-user
>>
>>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>



-- 
Carlos Henrique Grohmann - Geologist D.Sc.
a.k.a. Guano - Linux User #89721
ResearcherID: A-9030-2008

http://digitalelevation.blogspot.com

http://www.igc.usp.br/pessoais/guano
_
Can’t stop the signal.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] announcement of strahler stream order analysis

[Milton Cezar Ribeiro]

Thanks Carlos!!

milton

2009/7/28 Carlos Grohmann 

> Just tested in a LatLong region. works fine.
>
> Carlos
>
>
>
>
>
> 2009/7/28 Jarek Jasiewicz :
> > try, I don't know I haven't  LL location to test it
> > but it shoud work
> > program do not use any inforamtuon about units and units conversion
> >
> > Jarek
> >
> > Milton Cezar Ribeiro pisze:
> >>
> >> Hi Jarek
> >>
> >> Can use this on a LatLong mapset where my unit is not meters?
> >> Thanks for the effort!
> >>
> >> milton
> >>
> >> 2009/7/26 Jarek Jasiewicz mailto:jar...@amu.edu.pl
> >>
> >>
> >>Hi list!
> >>
> >>I just finish first version of new grass module r.stream. Module
> >>is regular Grass module, written in C an has no addational
> >>dependencies. It was compiled with GRASS65 devel  downloaded in
> >>last  two week. Source code you can find here:
> >>
> >>http://heretic.livenet.pl/heretic/r.stream.tar.gz
> >>
> >>Module compiles and seems to work. Analysis was tested only on one
> >>dataset.
> >>
> >>To compile it copy r.streams directory to your grassXX../raster/
> >> cd r.stream run make and make install
> >>
> >>What module calculate:
> >>- strahler stream order
> >>- shreeve stream magnitude
> >>- class of topological elements of drainage networks
> >>
> >>Module use r.watershed outputs: SDF flow direction and SDF stream
> >>network.
> >>
> >>
> >>Analysis of r.stream shall be run on same regions setings as
> >>r.watershed. If no, run g.region rast=your_dir_file first. For now
> >>module do not check if region and rasters are identical. It is
> >>planned to add in nearest feature. It also do not check if dirs
> >>and streams are SDF result. Threre are no addational description.
> >>It will be added after testing.
> >>
> >>It works only on cells data. Floating points data are not allowed
> >>(and have no sense).
> >>
> >>Module is quite fast. 3000 x3000 cells all three analysis runs no
> >>more than 30 s. on AMD 3800 2GB, Ubuntu 8.04
> >>
> >>Module is part of comprehensive project which will add full Horton
> >>analysis and some addational terrrains analysis to Grass. More
> >>details in the feature. Any cooperation is welcome. The next
> >>module I plan is directional vectorisation of stream network.
> >>
> >>For now module is available only form web address pointed below.
> >>After testing and removing critical errors it will be added to
> >>grass add-ons (or maybe to main branch?).
> >>
> >>Any coments, improvements and critics is very welcome.
> >>
> >>More advanced Grass developers: Please check my code. Its funny,
> >>but I don't know C.
> >>General code is based on GRASS r.topindex module (by Keith Beven
> >>and Huidae Cho, strongly modified)
> >>Strahler stream order algorithm from Saga GIS (by Victor Olaya,
> >>modified)
> >>Shreeve stream magnitude and class of topological network are my
> >>own ideas
> >>
> >>Test and enjoy.
> >>
> >>Jarek Jasiewicz
> >>Adam Mickiewicz University, Poznan
> >>Geoecology and Geoinformation Institute
> >>___
> >>grass-user mailing list
> >>grass-user@lists.osgeo.org 
> >>http://lists.osgeo.org/mailman/listinfo/grass-user
> >>
> >>
> > ___
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/grass-user
> >
>
>
>
> --
> Carlos Henrique Grohmann - Geologist D.Sc.
> a.k.a. Guano - Linux User #89721
> ResearcherID: A-9030-2008
>
> http://digitalelevation.blogspot.com
>
> http://www.igc.usp.br/pessoais/guano
> _
> Can’t stop the signal.
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Vector from Raster Problems (r.stream)

[Annalisa Minelli]

Yes, I found this problems too for using v.strahler..
so we tried to solve with r.strahler.. but we still have some problems for
low values of (r.wateshed) threshold..
but maybe Jarek has a better way with this new approach to the problem..
just "no dependencies" sounds good..
so we wait for good news!

Annalisa

2009/7/28 Jarek Jasiewicz 

>
>
> stephen sefick pisze:
>
>> I have compiled and used Jarek's stream order script and the results
>> look to be satisfactory- good job!.
>>
> You use windows as I remember, isn't it It is very important for me if
> program also work on windows. Please send me aslo feeback about time of
> analysis and size of maps
>
>>  I am having a hard time creating
>> vectors from this raster representation.  r.thin -> r.to.vect creates
>> lots of erroneous squares that I believe are there as an artifact of
>> the larger stream networks.
>>
> It is problem that no streams are marked as 0 (for now, it will be fixed to
> null). For now try to
> convert 0 to null with mapcalc formula: neworder=if(order=0,null(),order)
> and try again.
>
>>  The lower order (smaller) streams look
>> fine, but when you start getting to the higher order streams +5  I
>> think the r.thin algorithm may have problems delineating a stream.
>>
>
>  Is
>> there a way around this?  I would be happy with a line that ran
>> through the middle of the stream for now.  Some trick converting to
>> points and then to lines?  Or something along those lines.  Is there a
>> way to connect centroids?  I have made an area map of the streams
>> raster- can I connect the areas together?  Thanks for any help.
>> thanks,
>>
>>
>>
> I just work on another module which will be convert stream netowork to
> correct vector stream network (in most cases r.to.vect  do not it well) i
> thing it is metter of next week.
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] how to calculate area of voronoi polygons considering the boundary of the catchment

[daljeet]

Hi Moritz,

I am new to GRASS and the basic concepts of this field. Below, I tried my
best to share all the information. Please write if I have missed anything.

List of commands issued in sequence:

//import of shapefile data of country
v.in.ogr -e dsn="IND_adm2.shp" output="Ind_adm2_v" min_area=0.0001 snap=-1

//extract the desired State (in my case it is the state of Kerala)
v.extract input=Ind_adm2_v output=Ind_adm2_ker new=1 where="(Name_1 =
'Kerala')"

//set to region to the vector created for the State
g.region vect=Ind_adm2_ker

//displays as
d.vect Ind_adm2_ker

http://n2.nabble.com/file/n3344342/Ind_adm2_ker.png 

//area of Kerala state
v.report Ind_adm2_ker option=area units=k
cat|area
1|37700.7050169835

//import of rainfall data of the country for a week (available in ascii
format)
v.in.ascii
input="/home/daljeet/grassdata/India_Data_From_DST/india_rain_orig.txt"
output="Ind_rain_orig" format="point" fs="\t" skip=1 columns="x double
precision, y double precision, rain_info double precision" x=2 y=1 z=0 cat=0

//creating the voronoi
v.voronoi input="Ind_rain_orig" output="Ind_rain_ker_vor"

//display the voronoi
d.vect "Ind_rain_ker_vor"

http://n2.nabble.com/file/n3344342/Ind_rain_ker_vor.png 

//overlay
v.overlay ainput="Ind_adm2_ker" atype="area" alayer=1
binput="Ind_rain_ker_vor" btype="area" blayer=1 output="ker_rain_vor_over"
operator="and" olayer=1,0,0

//show the overlaid vector 
d.vect ker_rain_vor_over

http://n2.nabble.com/file/n3344342/ker_rain_vor_over.png 

//storing the area of each polygon to a csv file
v.report ker_rain_vor_over option=area units=k >ker_area.csv --o

attached is the csv file ker_area.csv

http://n2.nabble.com/file/n3344342/ker_area.csv ker_area.csv 

Sum of the area of polygon in the last column is 23881.22 (which is not
equal to the one which is calculated above for Kerala Stata, 
37700.7050169835)

Thanks
Daljeet


Moritz Lennert wrote:
> 
> On 28/07/09 16:02, daljeet wrote:
>> Thanks Moritz.
>> 
>> I was wrongly using the term "region" in my question above. The
>> requirement
>> is slightly different. Let me explain you in detail.
>> 
>> Inputs:
>> 1. I have got the shapefile data of the country. I imported it using
>> v.in.ogr and extracted (v.extract) the vector of the desired "State"
>> using
>> the "where" clause on the attribute which contains the name of the
>> States.
>> So, this means i have the vector of a particular State and its area is
>> available using v.report.
>> 
>> 2. I have also got the rainfall point data for the entire country in the
>> ascii file (x,y,z) for one week (z being the amount of rainfall)
>> 
>> Output required:
>> The volume of rainfall in the particular State (which is extracted
>> above).
>> 
>> What I am doing:
>> I wanted to apply both, the Thiessen polygon and the Isohyetal Method to
>> calculate the volume  of rainfall.
>> 
>> Till now I am only working on Thiessen, and this is what i have done:
>> 1. Imported the ascii rainfall point data (v.in.ascii) in the vector.
>> This
>> is the vector for the whole country.
>> 2. Created the voronoi vector on the above rainfall vector (v.voronoi)
>> 3. Overlaid the voronoi rainfall vector of the country (from step 2) on
>> the
>> extracted vector of the State (from input 1 above) with AND operator.
>> 
>> To verify, the sum of "area of each polygon" on the overlaid vector
>> should
>> be same as area of the extracted State vector.
>> 
>> But this is not coming out to be same. The area of the voronoi overlaid
>> map
>> is smaller than the area of the extracted shape of State.  One
>> observation,
>> the voronoi overlaid map shows some white grids (both inside and at the
>> boundary of the map) and I suspect if these are being taken into account
>> for
>> the area. Attached is the png image of the overlaid vectors. 
>> 
>> http://n2.nabble.com/file/n3342895/rainfall_theissen_png.png 
>> 
>> Any idea what could be my mistake. What I am doing which is making the
>> loss
>> of area in the case of polygons.
> 
> Sorry, cannot help you as such. Start by giving the exact command lines 
> used with each command. Also show the results of v.voronoi. And how did 
> you calculate the areas ?
> 
> Moritz
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
> 
> 

-- 
View this message in context: 
http://n2.nabble.com/how-to-calculate-area-of-voronoi-polygons-considering-the-boundary-of-the-catchment-tp3335923p3344342.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Horton's streams order - has it sense?

[Jarek Jasiewicz]

Hi list!

I've just thinked how to create horton stream order based on my module 
strahler module and accumulation file. Hortons stream order differs 
sligty form strahler order, see for example here fig. 1 page 78 
http://iahs.info/hsj/134/134008.pdf


Because I have some tests results from some of you (many thanks for your 
courage) i'm about to finish module, modify code to meet grass 
requiments and officialy anouce it on grass-dev, but If I will add 
horton stream order it  will may take a bit more time.


So I have 2 question  about that (horton):

Did you think taht horton stream order has already sense (it is almost 
not in use)


Does any body know any program (commercial or not) which calculate 
horton's stream order


Thanks for ansvers
Jarek
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] how to calculate area of voronoi polygons considering the boundary of the catchment

[Moritz Lennert]

On 28/07/09 18:42, daljeet wrote:

Hi Moritz,

I am new to GRASS and the basic concepts of this field. Below, I tried my
best to share all the information. Please write if I have missed anything.


This is perfect, thanks !


//creating the voronoi
v.voronoi input="Ind_rain_orig" output="Ind_rain_ker_vor"

//display the voronoi
d.vect "Ind_rain_ker_vor"

http://n2.nabble.com/file/n3344342/Ind_rain_ker_vor.png 



The problem is here, with v.voronoi, as you can see the white spots 
here. What do the original points (Ind_rain_orig) look like ?


I don't know the module well enough, but I think you might have hit a 
bug there (I've just tried a simple example for myself and also get 
weird white spots). Please file a report in the bug tracker.





//storing the area of each polygon to a csv file
v.report ker_rain_vor_over option=area units=k >ker_area.csv --o


Note that you can use v.addcol and v.to.db upload the polygon areas to 
the attribute table.


Moritz
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] announcement of strahler stream order analysis

[stephen sefick]

First, if I haven't said this yet, wonderful job.  Is there a way to
extract things like total lengths of streams from the raster.  Like
length of stream order 1, 2, etc., so that percentage of occurrence
could be calculated- length order1/length total?  On an unrelated note
I added this package to the raster set in the source and recompiled on
Mac.  I have lost the ability to use the python GUI.  I am having a
hard time figuring out how to do this.  Should I reinstall the Binary
version, add r.streams to the add on packages, or is there a simpler
way to add a flag in the ./configure argument?
Thanks,

Stephen Sefick

On Tue, Jul 28, 2009 at 11:14 AM, Milton Cezar
Ribeiro wrote:
> Thanks Carlos!!
>
> milton
>
> 2009/7/28 Carlos Grohmann 
>>
>> Just tested in a LatLong region. works fine.
>>
>> Carlos
>>
>>
>>
>>
>>
>> 2009/7/28 Jarek Jasiewicz :
>> > try, I don't know I haven't  LL location to test it
>> > but it shoud work
>> > program do not use any inforamtuon about units and units conversion
>> >
>> > Jarek
>> >
>> > Milton Cezar Ribeiro pisze:
>> >>
>> >> Hi Jarek
>> >>
>> >> Can use this on a LatLong mapset where my unit is not meters?
>> >> Thanks for the effort!
>> >>
>> >> milton
>> >>
>> >> 2009/7/26 Jarek Jasiewicz > >> >
>> >>
>> >>    Hi list!
>> >>
>> >>    I just finish first version of new grass module r.stream. Module
>> >>    is regular Grass module, written in C an has no addational
>> >>    dependencies. It was compiled with GRASS65 devel  downloaded in
>> >>    last  two week. Source code you can find here:
>> >>
>> >>    http://heretic.livenet.pl/heretic/r.stream.tar.gz
>> >>
>> >>    Module compiles and seems to work. Analysis was tested only on one
>> >>    dataset.
>> >>
>> >>    To compile it copy r.streams directory to your grassXX../raster/
>> >>     cd r.stream run make and make install
>> >>
>> >>    What module calculate:
>> >>    - strahler stream order
>> >>    - shreeve stream magnitude
>> >>    - class of topological elements of drainage networks
>> >>
>> >>    Module use r.watershed outputs: SDF flow direction and SDF stream
>> >>    network.
>> >>
>> >>
>> >>    Analysis of r.stream shall be run on same regions setings as
>> >>    r.watershed. If no, run g.region rast=your_dir_file first. For now
>> >>    module do not check if region and rasters are identical. It is
>> >>    planned to add in nearest feature. It also do not check if dirs
>> >>    and streams are SDF result. Threre are no addational description.
>> >>    It will be added after testing.
>> >>
>> >>    It works only on cells data. Floating points data are not allowed
>> >>    (and have no sense).
>> >>
>> >>    Module is quite fast. 3000 x3000 cells all three analysis runs no
>> >>    more than 30 s. on AMD 3800 2GB, Ubuntu 8.04
>> >>
>> >>    Module is part of comprehensive project which will add full Horton
>> >>    analysis and some addational terrrains analysis to Grass. More
>> >>    details in the feature. Any cooperation is welcome. The next
>> >>    module I plan is directional vectorisation of stream network.
>> >>
>> >>    For now module is available only form web address pointed below.
>> >>    After testing and removing critical errors it will be added to
>> >>    grass add-ons (or maybe to main branch?).
>> >>
>> >>    Any coments, improvements and critics is very welcome.
>> >>
>> >>    More advanced Grass developers: Please check my code. Its funny,
>> >>    but I don't know C.
>> >>    General code is based on GRASS r.topindex module (by Keith Beven
>> >>    and Huidae Cho, strongly modified)
>> >>    Strahler stream order algorithm from Saga GIS (by Victor Olaya,
>> >>    modified)
>> >>    Shreeve stream magnitude and class of topological network are my
>> >>    own ideas
>> >>
>> >>    Test and enjoy.
>> >>
>> >>    Jarek Jasiewicz
>> >>    Adam Mickiewicz University, Poznan
>> >>    Geoecology and Geoinformation Institute
>> >>    ___
>> >>    grass-user mailing list
>> >>    grass-u...@lists.osgeo.org 
>> >>    http://lists.osgeo.org/mailman/listinfo/grass-user
>> >>
>> >>
>> > ___
>> > grass-user mailing list
>> > grass-user@lists.osgeo.org
>> > http://lists.osgeo.org/mailman/listinfo/grass-user
>> >
>>
>>
>>
>> --
>> Carlos Henrique Grohmann - Geologist D.Sc.
>> a.k.a. Guano - Linux User #89721
>> ResearcherID: A-9030-2008
>>
>> http://digitalelevation.blogspot.com
>>
>> http://www.igc.usp.br/pessoais/guano
>> _
>> Can’t stop the signal.
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
>



-- 
Stephen Sefick

Let's not spend our time and resources 

[GRASS-user] r.stream with stream maps generated with other methods

[stephen sefick]

Jarek et al.,
I have used r.terraflow (MFD8) to create a flow accumulation grid.  I
have then used a baseflow index for the conterminous US to multiply by
the average annual runoff, and then multiply this result by the flow
accumulation grid to get cubic meters/second base flow map.  Is there
a way to use your stream ordering algorithm with my newly created base
flow map.  I can use direction from r.terraflow?
thanks for the help.
kind regards,

-- 
Stephen Sefick

Let's not spend our time and resources thinking about things that are
so little or so large that all they really do for us is puff us up and
make us feel like gods.  We are mammals, and have not exhausted the
annoying little problems of being mammals.

-K. Mullis
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] announcement of strahler stream order analysis

[Jarek Jasiewicz]

stephen sefick pisze:

First, if I haven't said this yet, wonderful job.  Is there a way to
extract things like total lengths of streams from the raster. 

In the feature module is only introducion to  full Hortonian analysis

 Like
length of stream order 1, 2, etc., so that percentage of occurrence
could be calculated- length order1/length total?  On an unrelated note
I added this package to the raster set in the source and recompiled on
Mac.  I have lost the ability to use the python GUI.  I am having a
hard time figuring out how to do this.  Should I reinstall the Binary
version, add r.streams to the add on packages, or is there a simpler
way to add a flag in the ./configure argument?
  

I don't know nothhing about wxGUI except that it exist so I cannot help.

Thanks,

Stephen Sefick

On Tue, Jul 28, 2009 at 11:14 AM, Milton Cezar
Ribeiro wrote:
  

Thanks Carlos!!

milton

2009/7/28 Carlos Grohmann 


Just tested in a LatLong region. works fine.

Carlos





2009/7/28 Jarek Jasiewicz :
  

try, I don't know I haven't  LL location to test it
but it shoud work
program do not use any inforamtuon about units and units conversion

Jarek

Milton Cezar Ribeiro pisze:


Hi Jarek

Can use this on a LatLong mapset where my unit is not meters?
Thanks for the effort!

milton

2009/7/26 Jarek Jasiewicz mailto:jar...@amu.edu.pl>>

   Hi list!

   I just finish first version of new grass module r.stream. Module
   is regular Grass module, written in C an has no addational
   dependencies. It was compiled with GRASS65 devel  downloaded in
   last  two week. Source code you can find here:

   http://heretic.livenet.pl/heretic/r.stream.tar.gz

   Module compiles and seems to work. Analysis was tested only on one
   dataset.

   To compile it copy r.streams directory to your grassXX../raster/
cd r.stream run make and make install

   What module calculate:
   - strahler stream order
   - shreeve stream magnitude
   - class of topological elements of drainage networks

   Module use r.watershed outputs: SDF flow direction and SDF stream
   network.


   Analysis of r.stream shall be run on same regions setings as
   r.watershed. If no, run g.region rast=your_dir_file first. For now
   module do not check if region and rasters are identical. It is
   planned to add in nearest feature. It also do not check if dirs
   and streams are SDF result. Threre are no addational description.
   It will be added after testing.

   It works only on cells data. Floating points data are not allowed
   (and have no sense).

   Module is quite fast. 3000 x3000 cells all three analysis runs no
   more than 30 s. on AMD 3800 2GB, Ubuntu 8.04

   Module is part of comprehensive project which will add full Horton
   analysis and some addational terrrains analysis to Grass. More
   details in the feature. Any cooperation is welcome. The next
   module I plan is directional vectorisation of stream network.

   For now module is available only form web address pointed below.
   After testing and removing critical errors it will be added to
   grass add-ons (or maybe to main branch?).

   Any coments, improvements and critics is very welcome.

   More advanced Grass developers: Please check my code. Its funny,
   but I don't know C.
   General code is based on GRASS r.topindex module (by Keith Beven
   and Huidae Cho, strongly modified)
   Strahler stream order algorithm from Saga GIS (by Victor Olaya,
   modified)
   Shreeve stream magnitude and class of topological network are my
   own ideas

   Test and enjoy.

   Jarek Jasiewicz
   Adam Mickiewicz University, Poznan
   Geoecology and Geoinformation Institute
   ___
   grass-user mailing list
   grass-user@lists.osgeo.org 
   http://lists.osgeo.org/mailman/listinfo/grass-user


  

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user




--
Carlos Henrique Grohmann - Geologist D.Sc.
a.k.a. Guano - Linux User #89721
ResearcherID: A-9030-2008

http://digitalelevation.blogspot.com

http://www.igc.usp.br/pessoais/guano
_
Can’t stop the signal.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
  

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user







  

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Horton's streams order - has it sense?

[Francisco Alonso Sarria]

Hi:

I do think it could be interesting, in fact I am using a couple of  
modules that performs Horton and Strahler ordering with my students. I  
just regret not be able to be more participative in this list.


I attach you the code in case it could be helpful.

The code it's a bit of a mess (not to mention that the comments are in  
Spanish ;-)


It assumes that the tables linked to the vector data are in postgresql.

There are two modules:

v.ordena_red (network ordering), performs Strahler or Shreve ordering  
(crit parameter). "desembocadura" means outlet (you have to pass the  
cat value of the oulet reach).


v.str2hor converts an ordering from Horton to Strahler.

They work fine as long as your network nodes have only 3 links.

In case have any problem, you should delete all the created files and  
tables to rerun them.


Good luck.

Paco

Jarek Jasiewicz  escribió:


Hi list!

I've just thinked how to create horton stream order based on my  
module strahler module and accumulation file. Hortons stream order  
differs sligty form strahler order, see for example here fig. 1 page  
78 http://iahs.info/hsj/134/134008.pdf


Because I have some tests results from some of you (many thanks for  
your courage) i'm about to finish module, modify code to meet grass  
requiments and officialy anouce it on grass-dev, but If I will add  
horton stream order it  will may take a bit more time.


So I have 2 question  about that (horton):

Did you think taht horton stream order has already sense (it is  
almost not in use)


Does any body know any program (commercial or not) which calculate  
horton's stream order


Thanks for ansvers
Jarek
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user



#include "grass/gis.h"
#include "grass/Vect.h"
#include "grass/display.h"
#include "grass/raster.h"
#include "grass/colors.h"
#include 
#include 
#include "libreria.h"
#include "math.h"

int crea_db(char* nombre_tabla,int *ordenacion,struct Map_info *map);

int main (int argc,char *argv[]){

  struct GModule *module; //Definición del módulo
  struct Map_info map,map2;   //Mapas
  struct Option *input, *output,*crit,*des;  //Opciones de usuario
  struct line_pnts *linea,*linea1,*linea2;  //Secuencias de puntos
  struct line_cats *cats;


  int lev,n1,n2,criterio,desemb,busc;
  int i,ii,l,k,l1,l2,l3,l4,ll,n_lines,n_nodes,fin,p,prev;
  char *mapset, err_msg[200],buf[1024],*name,*name2;
  double *recta,*sinuosidad,*longit,long2,recta2,sinu2;
  int *orden,*sigue1,*sigue2,*tocado,*coming,*desem,*att,*n_lineas,*fuente1,*fuente2,*fuente3;
  double x,y;
  char *colorin;


  //Variables de la base de datos
  char *db_nombre, *driver_nombre, *ordenc;

  dbDriver *driver;
  dbHandle handle;
  dbTable *tabla;
  dbColumn *columna;

  dbString orden_sql;

  ordenc=(char *) malloc(200);
  colorin=(char *) malloc(11);

  G_gisinit (argv[0]);


  // Gestión de la linea de comandos

  module = G_define_module();
  module->description ="Ordena una red de drenaje generada artificialmente";

  input = G_define_option();
  input->key = "input";
  input->type = TYPE_STRING;
  input->required = YES;
  input->description = "Nombre del mapa vectorial que vas a abrir";
  input->gisprompt = "viejo,vectorial,mapa vectorial";

  output = G_define_option();
  output->key = "output";
  output->type = TYPE_STRING;
  output->required = YES;
  output->description = "Nombre del mapa vectorial que vas a crear";
  output->gisprompt = "nuevo,vectorial,mapa vectorial";

  crit = G_define_option();
  crit->key = "crit";
  crit->type = TYPE_INTEGER;
  crit->required = YES;
  crit->description = "Criterio de ordenación (1:Strahler 2:Shreve 3:Crea tabla)";
  crit->gisprompt = "";

  des = G_define_option();
  des->key = "desembocadura";
  des->type = TYPE_INTEGER;
  des->required = YES;
  des->description = "cat del tramo de desembocadura de la red";
  des->gisprompt = "";

  if (G_parser(argc,argv))  exit(1);

  criterio=atoi(crit->answer);
  desemb=atoi(des->answer);


  //Inicialización de comandos gráficos
  if (R_open_driver()!=0) G_fatal_error("No hay monitor\n");
  D_setup(0);//R_standard_color(0);
  G_setup_plot(D_get_d_north(),D_get_d_south(),D_get_d_west(),D_get_d_east(),D_move_abs,D_cont_abs);



  //COMENZAR LA CREACION DE LA BASE DE DATOS

  //Establecer parámetros de la conexión  
  driver_nombre=db_get_default_driver_name();
  db_nombre=db_get_default_database_name();
 

  //Abrimos
  driver=db_start_driver(driver_nombre);
  db_init_handle(&handle);
  db_set_handle(&handle,db_nombre,NULL);
  if(db_open_database(driver,&handle)!=DB_OK){exit(ERROR);}


  //Generar y comprobar la orden SQL de creación de tabla
  db_init_string(&orden_sql);
  db_zero_string (&orden_sql);
  sprintf(ordenc,"create table %s ( cat integer, ",output->answer);
  db_append_string(&orden_sql,ordenc);  
  db_append_string(&orden_sql,"orden integer, longitud double precisio

Re: [GRASS-user] how to calculate area of voronoi polygons considering the boundary of the catchment

[daljeet]

These white spots in the voronoi vector may be the cause. But i ran the
voronoi module on the "archsites" vector of the Spearfish60 dataset and its
runs fine. The cmd was

v.voronoi input="archsites" output="arch_voronoi"

The only difference is that the region of archsites has got less points 
(around 25) whereas in Ind_rain_orig the total points were 93,000. Can this
be an issue. Can you test the module at your end with less and huge data
points and see if you also get similar results in both the cases. This would
be a great help. 

Also, i checked and the data of rain fall on voronoi vector is NOT NULL on
these white spots (checked using v.what.vect).

//d.vect Ind_rain_orig
//The  Ind_rain_orig looks like this - when the region is set to vector of
Kerala
//g.region vect=ker_rain_v

http://n2.nabble.com/file/n3345107/Ind_rain_orig_reg_ker.png 

But when the region is set to Ind_adm2_v (whole  country) the image is like 
//g.region vect=Ind_adm2_v
//d.vect Ind_rain_orig

http://n2.nabble.com/file/n3345107/Ind_rain_orig_reg_adm2.png 

Thanks
Daljeet

Moritz Lennert wrote:
> 
> On 28/07/09 18:42, daljeet wrote:
>> Hi Moritz,
>> 
>> I am new to GRASS and the basic concepts of this field. Below, I tried my
>> best to share all the information. Please write if I have missed
>> anything.
> 
> This is perfect, thanks !
> 
>> //creating the voronoi
>> v.voronoi input="Ind_rain_orig" output="Ind_rain_ker_vor"
>> 
>> //display the voronoi
>> d.vect "Ind_rain_ker_vor"
>> 
>> http://n2.nabble.com/file/n3344342/Ind_rain_ker_vor.png 
>> 
> 
> The problem is here, with v.voronoi, as you can see the white spots 
> here. What do the original points (Ind_rain_orig) look like ?
> 
> I don't know the module well enough, but I think you might have hit a 
> bug there (I've just tried a simple example for myself and also get 
> weird white spots). Please file a report in the bug tracker.
> 
> 
>> 
>> //storing the area of each polygon to a csv file
>> v.report ker_rain_vor_over option=area units=k >ker_area.csv --o
> 
> Note that you can use v.addcol and v.to.db upload the polygon areas to 
> the attribute table.
> 
> Moritz
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
> 
> 

-- 
View this message in context: 
http://n2.nabble.com/how-to-calculate-area-of-voronoi-polygons-considering-the-boundary-of-the-catchment-tp3335923p3345107.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Re: Horton's streams order - has it sense?

[Margherita Di Leo]

Hi Jarek!

I think that, with Horton and Strahler, it would be useful also Hack stream 
order, it is very nice because assigns value 1 to the main channel and so it is 
simple to achieve the main channel lenght. (Please see 
http://jgrass.wiki.software.bz.it/jgrass/Horton_Machine#head-f736e2e27c29fa8a71f227370b71a091fc03078f).

Cheers

margherita


Hi:

I do think it could be interesting, in fact I am using a couple of  
modules that performs Horton and Strahler ordering with my students. I  
just regret not be able to be more participative in this list.


I attach you the code in case it could be helpful.

The code it's a bit of a mess (not to mention that the comments are in  
Spanish  ;-) 


It assumes that the tables linked to the vector data are in postgresql.

There are two modules:

v.ordena_red (network ordering), performs Strahler or Shreve ordering  
(crit parameter). "desembocadura" means outlet (you have to pass the  
cat value of the oulet reach).


v.str2hor converts an ordering from Horton to Strahler.

They work fine as long as your network nodes have only 3 links.

In case have any problem, you should delete all the created files and  
tables to rerun them.


Good luck.

Paco

Jarek Jasiewicz  escribió:



> Hi list!
>
> I've just thinked how to create horton stream order based on my  
> module strahler module and accumulation file. Hortons stream order  
> differs sligty form strahler order, see for example here fig. 1 page  
> 78 http://iahs.info/hsj/134/134008.pdf

>
> Because I have some tests results from some of you (many thanks for  
> your courage) i'm about to finish module, modify code to meet grass  
> requiments and officialy anouce it on grass-dev, but If I will add  
> horton stream order it  will may take a bit more time.

>
> So I have 2 question  about that (horton):
>
> Did you think taht horton stream order has already sense (it is  
> almost not in use)

>
> Does any body know any program (commercial or not) which calculate  
> horton's stream order

>
> Thanks for ansvers
> Jarek
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
  


--
Eng. Margherita Di Leo
Ph.D. Student 
Methods and Technologies for Environmental Monitoring

Department of Environmental Engineering and Physics (DIFA)

University of Basilicata 
Campus Macchia Romana
85100 - Potenza 
Italy


Office: +39-0971205363
Fax: +39-0971205160
E-mail: dileomargherita AT gmail DOT com
Skype: dileomargherita
URL: http://www.difa.unibas.it/A_Manager_PP.do?azione=visualizzaHomePage&id=106





___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] how to calculate area of voronoi polygons considering the boundary of the catchment

[daljeet]

http://www.intevation.de/rt/webrt?serial_num=4292&display=History

The problem that we are facing may be related to above issue.

Thanks
Daljeet 
 

daljeet wrote:
> 
> These white spots in the voronoi vector may be the cause. But i ran the
> voronoi module on the "archsites" vector of the Spearfish60 dataset and
> its runs fine. The cmd was
> 
> v.voronoi input="archsites" output="arch_voronoi"
> 
> The only difference is that the region of archsites has got less points 
> (around 25) whereas in Ind_rain_orig the total points were 93,000. Can
> this be an issue. Can you test the module at your end with less and huge
> data points and see if you also get similar results in both the cases.
> This would be a great help. 
> 
> Also, i checked and the data of rain fall on voronoi vector is NOT NULL on
> these white spots (checked using v.what.vect).
> 
> //d.vect Ind_rain_orig
> //The  Ind_rain_orig looks like this - when the region is set to vector of
> Kerala
> //g.region vect=ker_rain_v
> 
>  http://n2.nabble.com/file/n3345107/Ind_rain_orig_reg_ker.png 
> 
> But when the region is set to Ind_adm2_v (whole  country) the image is
> like 
> //g.region vect=Ind_adm2_v
> //d.vect Ind_rain_orig
> 
>  http://n2.nabble.com/file/n3345107/Ind_rain_orig_reg_adm2.png 
> 
> Thanks
> Daljeet
> 
> Moritz Lennert wrote:
>> 
>> On 28/07/09 18:42, daljeet wrote:
>>> Hi Moritz,
>>> 
>>> I am new to GRASS and the basic concepts of this field. Below, I tried
>>> my
>>> best to share all the information. Please write if I have missed
>>> anything.
>> 
>> This is perfect, thanks !
>> 
>>> //creating the voronoi
>>> v.voronoi input="Ind_rain_orig" output="Ind_rain_ker_vor"
>>> 
>>> //display the voronoi
>>> d.vect "Ind_rain_ker_vor"
>>> 
>>> http://n2.nabble.com/file/n3344342/Ind_rain_ker_vor.png 
>>> 
>> 
>> The problem is here, with v.voronoi, as you can see the white spots 
>> here. What do the original points (Ind_rain_orig) look like ?
>> 
>> I don't know the module well enough, but I think you might have hit a 
>> bug there (I've just tried a simple example for myself and also get 
>> weird white spots). Please file a report in the bug tracker.
>> 
>> 
>>> 
>>> //storing the area of each polygon to a csv file
>>> v.report ker_rain_vor_over option=area units=k >ker_area.csv --o
>> 
>> Note that you can use v.addcol and v.to.db upload the polygon areas to 
>> the attribute table.
>> 
>> Moritz
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
>> 
>> 
> 
> 

-- 
View this message in context: 
http://n2.nabble.com/how-to-calculate-area-of-voronoi-polygons-considering-the-boundary-of-the-catchment-tp3335923p3345998.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] how to calculate area of voronoi polygons considering the boundary of the catchment

[Micha Silver]

On Tue, 28 Jul 2009 11:24:19 -0700 (PDT)
daljeet  wrote:

> 
> 
> 
> //d.vect Ind_rain_orig
> //The  Ind_rain_orig looks like this - when the region is set to
> vector of Kerala
> //g.region vect=ker_rain_v
> 
> http://n2.nabble.com/file/n3345107/Ind_rain_orig_reg_ker.png 
> 
> But when the region is set to Ind_adm2_v (whole  country) the image
> is like //g.region vect=Ind_adm2_v
> //d.vect Ind_rain_orig
> 
> http://n2.nabble.com/file/n3345107/Ind_rain_orig_reg_adm2.png 
> 

Since you seem to have a rigid matrix of data points, what's the
purpose of the voronoi polygons??
Can't you just run v.surf.rst to get a rain_info raster surface, then
r.contour to make your isohyetal lines? Finallly v.rast.stats will add
columns to the vector table with all the rainfall statistics.


 
> Thanks
> Daljeet
> 
> Moritz Lennert wrote:
> > 
> > On 28/07/09 18:42, daljeet wrote:
> >> Hi Moritz,
> >> 
> >> I am new to GRASS and the basic concepts of this field. Below, I
> >> tried my best to share all the information. Please write if I have
> >> missed anything.
> > 
> > This is perfect, thanks !
> > 
> >> //creating the voronoi
> >> v.voronoi input="Ind_rain_orig" output="Ind_rain_ker_vor"
> >> 
> >> //display the voronoi
> >> d.vect "Ind_rain_ker_vor"
> >> 
> >> http://n2.nabble.com/file/n3344342/Ind_rain_ker_vor.png 
> >> 
> > 
> > The problem is here, with v.voronoi, as you can see the white spots 
> > here. What do the original points (Ind_rain_orig) look like ?
> > 
> > I don't know the module well enough, but I think you might have hit
> > a bug there (I've just tried a simple example for myself and also
> > get weird white spots). Please file a report in the bug tracker.
> > 
> > 
> >> 
> >> //storing the area of each polygon to a csv file
> >> v.report ker_rain_vor_over option=area units=k >ker_area.csv --o
> > 
> > Note that you can use v.addcol and v.to.db upload the polygon areas
> > to the attribute table.
> > 
> > Moritz
> > ___
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/grass-user
> > 
> > 
> 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] i.atcorr with ASTER L1B

[andrew haywood]

Hi Mike

thanks for this supporting information. I will start the interpolation. Is
there any prefered method for this? Can I use a bilinear approach.
I think this is as far as I can take it though - as I have no understanding
of lwave.cpp and the file construct. Will it be ok to post a txt file on the
list with the interpretation results?

Cheers
Andrew


On 7/29/09, Michael Perdue  wrote:
>
> Hi Andy, Yes, it looks like the right info for the SPOT sensor platforms.
> Iwave.cpp expects the data to be in 2.5nm increments so you will have to
> interpolate the data to the correct interval. It's a bit tedious, but is
> straight forward. I might be able to dedicate some time to it, but won't
> have any till the weekend now.
> Cheers,
> Mike
>
>  On 27-Jul-09, at 10:35 PM, andrew haywood wrote:
>
>  Hi All,
>
> Im just adding to this discusssion. I would be interested in using i.atcorr
> with SPOT 2, 3, 4 and 5. I have found a file on the
> http://www.spotimage.com/web/en/555-spot-images.php website that contains
> the spectral sensitivity data. Is this the same as the spectral profile? It
> looks like the data is in 5nm increments. Do i need to create 2.5nm
> increments or can i tell the function its in 5nm or 10nm increments?
> Any help would be appreciated.
> thanks
> Andy
>
>
>
> On 7/28/09, Michael Perdue  wrote:
>>
>> Hi Markus,
>>
>> Here is a text file with everything organized as I think it should be. I
>> didn't add the this Iwave.cpp to submit a patch as I wasn't really sure how
>> to modify GeomCond.cpp.
>>
>> Cheers,
>> Mike
>>
>> On 26-Jul-09, at 1:34 PM, Markus Neteler wrote:
>>
>>>
>>> Great - the header of Iwave.cpp contains instructions how to add
>>> a new sensor like this.
>>>
>>> thanks
>>> Markus
>>>
>>
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>
>>
>>
>
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] error: Incompatible library version for module. You need to rebuild GRASS or untangle multiple installations.

[Nikos Alexandris]

Hi dev's and advanced useRs,

I have seen this message for the X-th time now :-( while trying to load
(anything) data using readRAST6 or readVECT6.

I've rebuild grass-6.4.0svn 2-3 times now. I've re-installed R 2-3 times
as well. Not to mention how many attempts to get "spgrass6".

Which is the "incompatible library" and to which "module" does it refer
to? Is this an R error or a grass error? Any help is *higly*
appreciated.

Kind regards, Nikos

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] g.manual tries to run C:\Program Files\Internet Exporer\iexplore (the 'L' is missing from 'Explorer')

[Hamish]

Glynn wrote:
> Can you modify the script to print its arguments? And
> g.manual to print out $GRASS_HTML_BROWSER.

note1 that until Maris's space-in-filename fixes in 6.5svn have been
reviewed & backported to 6.4 we may just be chasing things already
fixed and not being efficient in our use of time.

note2 until osgeo4w has a new release, diito with anything having
to do with that version.

note3 (a contingent of) the MSys devs has made it clear that they
won't even apply patches fixing spaces in pathname issues because
if it works at all they worry about being flooded with bug reports
for every GNU util they ship with etc which fails with that. I
don't really agree with that strategy, but it's their project so
whatever. I've got a conglomerate patch in their SF bug tracker
solving some core spaces in pathnames problems which Colin applies
(plus his own improvements). But AFAIK that's just the startup
stuff.

For GRASS_HTML_BROWSER, it is read in a number of contexts by e.g.
by g.manual shell script (6.x), g.manual python (7.x), wxGUI,
tcl/tk GUI, grass-run.bat, gui startups, ...

so it needs to be both cross-platform, cross-language, and cross-
environment (msys vs dos). thus IMO the only portable solution will
be to store it in the OS's native FS format and have each client
code translate downstream as needed rather than guess that up
front.

"C:\Program Files" is not portable due to i18n, 
the above-mentioned MSys patch has long -> 8.3 DOS filena~1
batch file translation magic for reference, I assume python has
all the tools you need built in, tcltk can be pursuaded, ...
which leaves msys's /bin/sh.

I find msys to be too large complex to simply say "msys does or
does not support this or that" as a blanket statement.


Hamish



  

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] error: Incompatible library version for module. You need to rebuild GRASS or untangle multiple installations.

[stephen sefick]

What computer architecture, operating system, what R version etc.?
What is the error message?  I am using 6.4RC5 GRASS and R 2.9.1 on mac
OS X 10.5.7, and it is working fine.  I remember there being a problem
with something, but I don't remember exactly what.  If you were to
provide the error message then maybe it would jog my memory.  Also, it
may be a good idea to search the R-sig-geo list archive, as your
problem may have already been solved (assuming it is the same one that
I had).
hth,

Stephen Sefick

On Tue, Jul 28, 2009 at 8:39 PM, Nikos
Alexandris wrote:
> Hi dev's and advanced useRs,
>
> I have seen this message for the X-th time now :-( while trying to load
> (anything) data using readRAST6 or readVECT6.
>
> I've rebuild grass-6.4.0svn 2-3 times now. I've re-installed R 2-3 times
> as well. Not to mention how many attempts to get "spgrass6".
>
> Which is the "incompatible library" and to which "module" does it refer
> to? Is this an R error or a grass error? Any help is *higly*
> appreciated.
>
> Kind regards, Nikos
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>



-- 
Stephen Sefick

Let's not spend our time and resources thinking about things that are
so little or so large that all they really do for us is puff us up and
make us feel like gods.  We are mammals, and have not exhausted the
annoying little problems of being mammals.

-K. Mullis
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] error: Incompatible library version for module. You need to rebuild GRASS or untangle multiple installations.

[Nikos Alexandris]

stephen sefick wrote:

> What computer architecture, operating system, what R version etc.?

Right, I assume that people know that I am using Ubuntu Jaunty 64-bit, R
2.9.1, latest rpy2, grass-6.4.0svn from source.

> What is the error message? 

The message is the title of this thread.

> I am usingce 6.4RC5 GRASS and R 2.9.1 on mac
> OS X 10.5.7, and it is working fine. I remember there being a problem
> with something, but I don't remember exactly what.  If you were to
> provide the error message then maybe it would jog my memory.

Sorry, that's all the prog prints.

> Also, it may be a good idea to search the R-sig-geo list archive, as your
> problem may have already been solved (assuming it is the same one that
> I had).

Before doing countless compilations/installations I filtered the web for
an hour! I've found some similar messages in grass-dev's mailing-list
but nothing specific.

I thought that /etc/ld.so.conf is my problem... and I commented out all
grass-versions but grass-6.4.0svn. I even removed all other
grass-versions, (re-)installed X-times spgrass6 but no luck.

It's the first time I see this message. I also tried to do some
debugging but R requires, I guess, special treatment (meaning other than
gdb, etc.) !?

Nikos

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] error: Incompatible library version for module. You need to rebuild GRASS or untangle multiple installations.

[stephen sefick]

WOW!  I don't have a clue.  That is nowhere close to the problem that
I had.  Sorry if I am asking obvious, or redundant questions.  Are you
installing within R, or from the commandline (R CMD install)?  I will
help if I can, but I think this may be over my paygrade.
good luck!

Stephen Sefick

On Tue, Jul 28, 2009 at 9:46 PM, Nikos
Alexandris wrote:
>
> stephen sefick wrote:
>
>> What computer architecture, operating system, what R version etc.?
>
> Right, I assume that people know that I am using Ubuntu Jaunty 64-bit, R
> 2.9.1, latest rpy2, grass-6.4.0svn from source.
>
>> What is the error message?
>
> The message is the title of this thread.
>
>> I am usingce 6.4RC5 GRASS and R 2.9.1 on mac
>> OS X 10.5.7, and it is working fine. I remember there being a problem
>> with something, but I don't remember exactly what.  If you were to
>> provide the error message then maybe it would jog my memory.
>
> Sorry, that's all the prog prints.
>
>> Also, it may be a good idea to search the R-sig-geo list archive, as your
>> problem may have already been solved (assuming it is the same one that
>> I had).
>
> Before doing countless compilations/installations I filtered the web for
> an hour! I've found some similar messages in grass-dev's mailing-list
> but nothing specific.
>
> I thought that /etc/ld.so.conf is my problem... and I commented out all
> grass-versions but grass-6.4.0svn. I even removed all other
> grass-versions, (re-)installed X-times spgrass6 but no luck.
>
> It's the first time I see this message. I also tried to do some
> debugging but R requires, I guess, special treatment (meaning other than
> gdb, etc.) !?
>
> Nikos
>
>



-- 
Stephen Sefick

Let's not spend our time and resources thinking about things that are
so little or so large that all they really do for us is puff us up and
make us feel like gods.  We are mammals, and have not exhausted the
annoying little problems of being mammals.

-K. Mullis
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] error: Incompatible library version for module. You need to rebuild GRASS or untangle multiple installations.

[Nikos Alexandris]

On Tue, 2009-07-28 at 22:06 -0500, stephen sefick wrote:
> WOW!  I don't have a clue.  That is nowhere close to the problem that
> I had.  Sorry if I am asking obvious, or redundant questions.  Are you
> installing within R, or from the commandline (R CMD install)?

>From within R with root access (e.g. sudo R, then the rest).

>   I will 
> help if I can, but I think this may be over my paygrade.
> good luck!

Thanks for your concern Stephen.
Kind regards, Nikos

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] error: Incompatible library version for module. You need to rebuild GRASS or untangle multiple installations.

[stephen sefick]

Nikos,
I am sorry I couldn't be of more help.  When you resolve the issue
would you mind telling me what you found.  My interest is peaked.

Stephen Sefick

On Tue, Jul 28, 2009 at 10:35 PM, Nikos
Alexandris wrote:
> On Tue, 2009-07-28 at 22:06 -0500, stephen sefick wrote:
>> WOW!  I don't have a clue.  That is nowhere close to the problem that
>> I had.  Sorry if I am asking obvious, or redundant questions.  Are you
>> installing within R, or from the commandline (R CMD install)?
>
> >From within R with root access (e.g. sudo R, then the rest).
>
>>   I will
>> help if I can, but I think this may be over my paygrade.
>> good luck!
>
> Thanks for your concern Stephen.
> Kind regards, Nikos
>
>



-- 
Stephen Sefick

Let's not spend our time and resources thinking about things that are
so little or so large that all they really do for us is puff us up and
make us feel like gods.  We are mammals, and have not exhausted the
annoying little problems of being mammals.

-K. Mullis
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.buffer segmentation fault

[Martin Landa]

Hi,

2009/7/24 Corrado :

[...]

> Where do I get those datasets?

http://grass.osgeo.org/download/data.php

Martin

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Interactive digitizing tool (wxPython) doesn't work and v.out.ogr always crashes under Windows Vista

[Martin Landa]

Hi,

2009/7/22 Frank Bilki :
> I tried to use the interactive digitizing tool in the wxPython UI by
> displaying the new vector map, right-clicking it in the map layer
> tree, and choosing 'Start editing' from the context menu. It displays
> fine, but no matter how often I select my vector map, every tool I use
> says, "No vector map selected for editing." I can see the correct map
> name right there on the toolbar in the Map Display, so either I'm
> doing something fundamentally wrong or there is another problem that
> I'm too inexperienced with GRASS to figure out.

wxGUI extension (vector digitizer and 3D view mode) unfortunately do
not work on MS Windows. I hope it will be fixed soon (probably after
6.4.0).

Martin

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] Interactive digitizing tool (wxPython) doesn't work and v.out.ogr always crashes under Windows Vista

[Frank Bilki]

Thanks Martin.

I was a bit hasty in posting the question -- I later found out from reading
the documentation that the wxPython interface is still a work in progress,
so I understand its limitations now.

Regards,

Frank


-Original Message-
From: Martin Landa [mailto:landa.mar...@gmail.com] 
Sent: Wednesday, 29 July 2009 2:30 PM
To: Frank Bilki
Cc: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] Interactive digitizing tool (wxPython) doesn't
work and v.out.ogr always crashes under Windows Vista

Hi,

< snip >

wxGUI extension (vector digitizer and 3D view mode) unfortunately do
not work on MS Windows. I hope it will be fixed soon (probably after
6.4.0).

Martin


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user