[GRASS-user] Multiple usage of r.water.outlet

GRASS GRASS user
1

If you run g.region to set the computational region to just the area of each
basin before doing the other calculations, it might run a lot faster.

Michael

On 5/15/08 5:02 AM, "grass-user-request@lists.osgeo.org"
<grass-user-request@lists.osgeo.org> wrote:

Date: Thu, 15 May 2008 14:00:14 +0200
From: Christian Schwartze <Christian.Schwartze@uni-jena.de>
Subject: [GRASS-user] Multiple usage of r.water.outlet
To: grass-user@lists.osgeo.org
Message-ID: <1210852814.482c25ceebafb@webmail.uni-jena.de>
Content-Type: text/plain; charset=ISO-8859-1

Dear GRASS user,

the problem I have is using r.water.outlet for some scripting in Python. Below
I
want to explain the proceeding in detail. It should be mentioned in advance
that
the necessary drainage raster has nearly 10000 rows and columns, so it's not
really small...
I have a point shape file (or generally point coordinates, more than 100
pairs)
that presents the input for multiple calls of r.water.outlet. To produce a map
representing the corresponding watersheds of all these points I thought of the
three following approaches:

(A) At certain intervals (of the r.water.outlet iteration) I sort the
previous
calculated basins by area and use the resulting and ascending order as an
input
for r.patch. So the basins can not hide each other.

(B) At certain intervals I execute r.cross for overlaying the previous basins.

(C) I use r.mapcalc in every iteration step with an expression like
"allbasins = allbasins +
if(isnull(allbasins),basin<x>,if(allbasins>=1&&basin<x>==1,<newBasinID>,allbas
ins))"
where allbasins is initially a "novalue" raster.

All methods above are working right, but have the same lack: the performance -
too slow!
Remember that the working raster has an extent of 10000x10000 pixel. The
single
calculated basins and their extents compared to entire drainage raster are
very
small (see the attachment). While the duration of r.water.outlet is barely
acceptable, the merging step (regardless of the technique in A, B or C) takes
too long.
What do you think about the three approaches for a script in Python and how
can
i minimize the performance problem when bringing the basins together within a
large area? Many thanks for any advice!

Regards,
Christian.

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

2

Yes, thats right, and I tried this with g.region zoom=basin<x> for example. But
I have to merge more than one area and they could be distributed far away each
other, in worst case.

Regards,
Christian.

Zitat von Michael Barton <michael.barton@asu.edu>:

If you run g.region to set the computational region to just the area of each
basin before doing the other calculations, it might run a lot faster.

Michael

On 5/15/08 5:02 AM, "grass-user-request@lists.osgeo.org"
<grass-user-request@lists.osgeo.org> wrote:

> Date: Thu, 15 May 2008 14:00:14 +0200
> From: Christian Schwartze <Christian.Schwartze@uni-jena.de>
> Subject: [GRASS-user] Multiple usage of r.water.outlet
> To: grass-user@lists.osgeo.org
> Message-ID: <1210852814.482c25ceebafb@webmail.uni-jena.de>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Dear GRASS user,
>
> the problem I have is using r.water.outlet for some scripting in Python.
Below
> I
> want to explain the proceeding in detail. It should be mentioned in advance
> that
> the necessary drainage raster has nearly 10000 rows and columns, so it's
not
> really small...
> I have a point shape file (or generally point coordinates, more than 100
> pairs)
> that presents the input for multiple calls of r.water.outlet. To produce a
map
> representing the corresponding watersheds of all these points I thought of
the
> three following approaches:
>
> (A) At certain intervals (of the r.water.outlet iteration) I sort the
> previous
> calculated basins by area and use the resulting and ascending order as an
> input
> for r.patch. So the basins can not hide each other.
>
> (B) At certain intervals I execute r.cross for overlaying the previous
basins.
>
> (C) I use r.mapcalc in every iteration step with an expression like
> "allbasins = allbasins +
>
if(isnull(allbasins),basin<x>,if(allbasins>=1&&basin<x>==1,<newBasinID>,allbas
> ins))"
> where allbasins is initially a "novalue" raster.
>
>
> All methods above are working right, but have the same lack: the
performance -
> too slow!
> Remember that the working raster has an extent of 10000x10000 pixel. The
> single
> calculated basins and their extents compared to entire drainage raster are
> very
> small (see the attachment). While the duration of r.water.outlet is barely
> acceptable, the merging step (regardless of the technique in A, B or C)
takes
> too long.
> What do you think about the three approaches for a script in Python and how
> can
> i minimize the performance problem when bringing the basins together within
a
> large area? Many thanks for any advice!
>
> Regards,
> Christian.

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

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

----------------------------------------------------------------
This mail was sent through http://webmail.uni-jena.de