Hamish wrote:
Hamish:
see the man page for an example of making a nicely colored accum map
based on standard deviations.
MMetz:
Why not setting colors for accum in the module?
If you like, but a simple linear color model will not work well:
Hmm, it does work with
Markus Metz wrote:
In my personal opinion, flow accumulation of r.watershed is also more
realistic than flow accumulation of r.terraflow (SFD), but I have
admittedly not tested it in detail.
I just wanted to add that I have, in fact, compared the results of the
r.watershed with r.terraflow, as
Markus Metz wrote:
Why not setting colors for accum in the module?
Hamish:
If you like, but a simple linear color model will not work well:
MMz:
Since the bulk of the flow accumulation output has little flow, a simple
fixed linear model would work in most cases as it does for the visual
I very much agree with Hamish:
it is really nice to have two independent methods to use race
against
each other, and compare the results of. ie apply the scientific
method.
Each will have its strength and weaknesses and now we can quantify
more
what those are.
I am a big proponent and
On Tue, Dec 2, 2008 at 8:20 PM, Helena Mitasova [EMAIL PROTECTED] wrote:
I very much agree with Hamish:
it is really nice to have two independent methods to use race against
each other, and compare the results of. ie apply the scientific method.
Each will have its strength and weaknesses and
Markus Metz:
The new version of r.watershed produces results identical to the
original version at a substantial speed increase by optimizing the A *
search method.
that reminds me, the man page needs updating too,
Both versions use the AT least-cost search algorithm to determine the
Hi,
r.watershed2 changes are now merged into r.watershed1 in SVN devbr6,
trunk. Hopefully without further problems.
Markus Metz wrote:
Actually I wanted to apply the changes of the r.watershed version in
grass-7 to r.watershed2, especially naming of options without points
and uppercase, but
Hamish wrote:
Markus Metz wrote:
Actually I wanted to apply the changes of the r.watershed version in
grass-7 to r.watershed2, especially naming of options without points
and uppercase, but didn't get yet to it.
done. ('svn merge' did 99% of the work after devbr6 was solved)
On Dec 1, 2008, at 1:52 AM, [EMAIL PROTECTED] wrote:
Date: Mon, 1 Dec 2008 00:52:47 -0800 (PST)
From: Hamish [EMAIL PROTECTED]
Subject: Re: [GRASS-dev] testing results of r.watershed2 against old
r.watershed
To: grass-dev@lists.osgeo.org, Markus Metz [EMAIL PROTECTED]
Cc: Helena
Markus Metz wrote:
Change option names also for r.watershed.ram and
r.watershed.seg? There are some options in uppercase.
those do not use G_parser() and are not exposed to the user, so not a
priority for standardization.
Hamish:
see the man page for an example of making a nicely colored
It seems that I am at least in part responsible for the confusion about
svn versions of r.watershed2/r.watershed.fast, sorry for that!
The initial request was to make the changes to r.watershed available as
a separate module in the grass-addons svn repository, and I created a
new directory
Markus Neteler wrote:
[EMAIL PROTECTED] wrote:
And presumably the clean-up I've done on watershed in 7.0 has all now
been discarded?
No - since I didn't *replace* the old version.
If you add a near-clone of an existing directory and mark the old one
as deprecated, then for all practical
Glynn Clements wrote:
In that regard, anything which is a derivative of existing code
doesn't belong in grass-addons. If it's too radical even for 7.0, then
it should go into its own branch, so that SVN *knows* that it is a
branch of existing code.
Looking further, grass-addons is part of
Hi,
I did a bit more syncing between what is now in devbr6 for r.watershed1
and 2.
a minimized diff for review can be found here:
https://trac.osgeo.org/grass/attachment/ticket/344/r.w2.diff
after review, that patch should be applied to r.watershed/ in devbr6 and
trunk, and r.watershed2/
On Fri, Nov 14, 2008 at 10:32 PM, Isaac Ullah [EMAIL PROTECTED] wrote:
Hi all, I'd like to report the results of testing I just did with the new
r.watershed2 module from the addons svn.
...
Results: both modules successfully produce quality output maps. In fact,
when the output maps are
Markus Neteler wrote:
Hi all, I'd like to report the results of testing I just did with the new
r.watershed2 module from the addons svn.
...
Results: both modules successfully produce quality output maps. In fact,
when the output maps are compared (subtracted with mapcalc) there is
Markus:
I have moved the code to GRASS 6.4.svn and 7.svn now and deactivated
the old version.
Glynn:
And presumably the clean-up I've done on watershed in 7.0 has all now
been discarded?
not fully - in devbr6 modifications need to me made to r.watershed2
to keep the old option names:
Hamish wrote:
Markus:
I have moved the code to GRASS 6.4.svn and 7.svn now and deactivated
the old version.
Glynn:
And presumably the clean-up I've done on watershed in 7.0 has all now
been discarded?
FWIW, that was a rhetorical question. I resolved the issue with
svn remove
Hamish:
As such it should be merged into the old r.watershed code not get its
own new directory. A suggested way forward: indent and modify
r.watershed2 so that a minimal diff is created and apply that to
r.watershed(1) keeping an eye on option name changes and new unmerged
developments.
Hi all, I'd like to report the results of testing I just did with the new
r.watershed2 module from the addons svn. I am using the latest svn source
version of grass6.4, compiled on a dual processor dell with 2 gigs ram, and
running the latest ubuntu 8.10 OS. I used the dataset that I've used for
20 matches
Mail list logo
