Jarek Jasiewicz | 1 Aug 16:30 2009
Picon

r.stream: new features

Dear GRASS Users!

I announce new features of r.stream: Horton stream order. More details 
and actual source code:

http://heretic.livenet.pl/heretic/

The release of full version is planned at the fall of August.

Test and enjoy.

Jarek
_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

stephen sefick | 1 Aug 20:15 2009
Picon

idxstats - where is this file

I have tracked down most all of the other things needed to run top
model, save this one.

--

-- 
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 <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Pavel Iacovlev | 1 Aug 22:36 2009
Picon

Flood simulation

Good day all,

I want to simulate a simple flood situation. My steps are
1. Download the elevation data
2. Use r.lake to generate the raster image of the flood area

No problem with this, works like a charm. Now I would like to get the
"vector" variant of the flood area so I can run intersects with my
other vector data to see what is flooded and whats not.

Any tips with what tool or combination of commands I can achieve this ?

--

-- 
http://iap.md, The future is open
_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

stephen sefick | 2 Aug 00:52 2009
Picon

Re: Flood simulation

r.to.vect with the area argument?

On Sat, Aug 1, 2009 at 3:36 PM, Pavel Iacovlev<iacovlev.pavel <at> gmail.com> wrote:
> Good day all,
>
> I want to simulate a simple flood situation. My steps are
> 1. Download the elevation data
> 2. Use r.lake to generate the raster image of the flood area
>
> No problem with this, works like a charm. Now I would like to get the
> "vector" variant of the flood area so I can run intersects with my
> other vector data to see what is flooded and whats not.
>
> Any tips with what tool or combination of commands I can achieve this ?
>
> --
> http://iap.md, The future is open
> _______________________________________________
> grass-user mailing list
> grass-user <at> 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.
(Continue reading)

Micha Silver | 2 Aug 10:49 2009
Picon

"ladders" in watershed delineation

How can I avoid the problem of strings of single cells when creating 
basins with r.watershed? I think this is referred to as "ladders". 
Here's [1] an image showing what I mean.

In my example, the purple colored catchment has two "tails" of width 1 
cell. One tail separates between the light green and the pale blue 
catchments. The other (northern) tail splits the dark green catchment 
into two.

After running r.to.vect to get the catchment vectors, I'm left with the 
two "strings" or "ladders" of tiny vector areas. The southern string can 
be removed with v.clean tool=rmarea with no ill effects.

However when I remove those small areas in the northern "ladder" I'm 
left with the stream running *along the drainage divide* or even 
zigzagging across the divide, neither of which is correct.

Can this problem be avoided? I've tried with a couple of different dem 
sources, and at different resolutions and threshold values, but these 
ladder phenomena always seem to appear.

This example was done with the ASTER DEM data, using a threshold of 
11000 and resolution like the original data (1 arcsec ~= 30 m.)

Thanks,

Micha

[1] http://my.arava.co.il/~micha/ladders.html

(Continue reading)

Markus Neteler | 2 Aug 11:11 2009

Re: idxstats - where is this file

On Sat, Aug 1, 2009 at 8:15 PM, stephen sefick<ssefick <at> gmail.com> wrote:
> I have tracked down most all of the other things needed to run top model,
> save this one.

Perhaps using
r.stats -Anc topidxmap
which prints out averaged statistics for topographic index generated with
r.topidx?

Markus

PS: Please consider to post your findings later in a Wiki page for Topmodel
_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Stefan Sylla | 2 Aug 11:27 2009
Picon
Picon

Re: i.spec.unmix module


Hi, as there has not been an answer on that matter I would like to ask again,
if someone can give an explanation on the i.spec.unmix AddOn problem with
grass64.svn, as I got exactly the same messages as quoted below.

Is it possible, that it has not yet been fitted with the sources of grass64?
And if so, what can I do to get i.spec.unmix running?

Best regards
Stefan

Pedro Camilo Alcantara wrote:
> 
> Hi everyone
> 
> I saw that there is a module on spectral unmixing on the add-ons
> subversion
> repository, so, I downloaded and compiled the last grass 6.4 snapshot
> (grass-6.4.svn_src_snapshot_2008_06_14), download the addons with svn (svn
> checkout https://svn.osgeo.org/grass/grass-addons/ grass-addons). and
> compiled the module as described in the README I found on the addons (make
> MODULE_TOPDIR=/home/camilo/grass-6.4.svn_src_snapshot_2008_06_14).
> I got this messages:
> 
> /home/camilo/grass-addons/imagery/i.spec.unmix# make
> MODULE_TOPDIR=/home/camilo/grass-6.4.svn_src_snapshot_2008_06_14
> gcc
> -I/home/camilo/grass-6.4.svn_src_snapshot_2008_06_14/dist.i686-pc-linux-gnu/include
> -g -O2       -DPACKAGE=\""grassmods"\"
> -I/home/camilo/grass-6.4.svn_src_snapshot_2008_06_14/dist.i686-pc-linux-gnu/include
(Continue reading)

Nikos Alexandris | 2 Aug 11:40 2009
Picon

Re: i.spec.unmix module


Stefan Sylla:

> Hi, as there has not been an answer on that matter I would like to ask again,
> if someone can give an explanation on the i.spec.unmix AddOn problem with
> grass64.svn, as I got exactly the same messages as quoted below.
> 
> Is it possible, that it has not yet been fitted with the sources of grass64?
> And if so, what can I do to get i.spec.unmix running?

Same error here using grass-6.4.0svn.
Nikos
---

> Pedro Camilo Alcantara wrote:
> > 
> > Hi everyone
> > 
> > I saw that there is a module on spectral unmixing on the add-ons
> > subversion
> > repository, so, I downloaded and compiled the last grass 6.4 snapshot
> > (grass-6.4.svn_src_snapshot_2008_06_14), download the addons with svn (svn
> > checkout https://svn.osgeo.org/grass/grass-addons/ grass-addons). and
> > compiled the module as described in the README I found on the addons (make
> > MODULE_TOPDIR=/home/camilo/grass-6.4.svn_src_snapshot_2008_06_14).
> > I got this messages:
> > 
> > /home/camilo/grass-addons/imagery/i.spec.unmix# make
> > MODULE_TOPDIR=/home/camilo/grass-6.4.svn_src_snapshot_2008_06_14
> > gcc
(Continue reading)

Jarek Jasiewicz | 2 Aug 12:02 2009
Picon

Re: "ladders" in watershed delineation


Micha Silver pisze:
> How can I avoid the problem of strings of single cells when creating 
> basins with r.watershed? I think this is referred to as "ladders". 
> Here's [1] an image showing what I mean.
>
> In my example, the purple colored catchment has two "tails" of width 1 
> cell. One tail separates between the light green and the pale blue 
> catchments. The other (northern) tail splits the dark green catchment 
> into two.
>
> After running r.to.vect to get the catchment vectors, I'm left with 
> the two "strings" or "ladders" of tiny vector areas. The southern 
> string can be removed with v.clean tool=rmarea with no ill effects.
>
> However when I remove those small areas in the northern "ladder" I'm 
> left with the stream running *along the drainage divide* or even 
> zigzagging across the divide, neither of which is correct.
>
> Can this problem be avoided? I've tried with a couple of different dem 
> sources, and at different resolutions and threshold values, but these 
> ladder phenomena always seem to appear.
>
> This example was done with the ASTER DEM data, using a threshold of 
> 11000 and resolution like the original data (1 arcsec ~= 30 m.)
>
>
> Thanks,
>
> Micha
(Continue reading)

Markus Neteler | 2 Aug 12:27 2009

Re: i.spec.unmix module

On Sun, Aug 2, 2009 at 11:40 AM, Nikos
Alexandris<nikos.alexandris <at> felis.uni-freiburg.de> wrote:
>
> Stefan Sylla:
>
>> Hi, as there has not been an answer on that matter I would like to ask again,
>> if someone can give an explanation on the i.spec.unmix AddOn problem with
>> grass64.svn, as I got exactly the same messages as quoted below.
>>
>> Is it possible, that it has not yet been fitted with the sources of grass64?
>> And if so, what can I do to get i.spec.unmix running?
>
> Same error here using grass-6.4.0svn.

The module needs yet to be ported to GRASS 6. Brad Douglas had worked
on it but never send his modifications. So I am afraid to say that someone
has to redo it.

Sorry for no better news,
Markus
_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Gmane