[GRASS-user] r.watershed: output basin map

Thu Apr 19 01:23:11 EDT 2012

Can you post please some more information related to your query.
For example : region, resolution of raster dem, command used to generated
the basin.
What do you get when you query the white area.

On Thu, Apr 19, 2012 at 4:19 AM, <grass-user-request at lists.osgeo.org> wrote:

> Send grass-user mailing list submissions to
>        grass-user at lists.osgeo.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://lists.osgeo.org/mailman/listinfo/grass-user
> or, via email, send a message with subject or body 'help' to
>        grass-user-request at lists.osgeo.org
>
> You can reach the person managing the list at
>        grass-user-owner at lists.osgeo.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of grass-user digest..."
>
>
> Today's Topics:
>
>   1. v.rast.stats for just a single statistic, in a python loop
>      (Ismael G?mez)
>   2. Re: v.rast.stats for just a single statistic, in a python
>      loop (Moritz Lennert)
>   3. Re: Simultaneous r.horizon processes (Hamish)
>   4. Re: v.rast.stats for just a single statistic, in a        python
>      loop (Ismael G?mez)
>   5. r.watershed: output basin map (Rich Shepard)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 18 Apr 2012 20:54:37 +0200
> From: Ismael G?mez <gomez.ismael at gmail.com>
> Subject: [GRASS-user] v.rast.stats for just a single statistic, in a
>        python loop
> To: grass mailing list <grass-user at lists.osgeo.org>
> Message-ID:
>        <CAN4+wUjD-9TMs_AD1Z6W5zi3TRvUsVPYfP60VUSYgeBNXLqVvQ at mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hello,
>
> I would like to use the v.rast.stats inside a loop in a python script.
> The thing is I just need to get one of the nine columns it generates (sum).
> As it runs many times in the loop, it takes a lot of (unnecessary, for this
> script) time and also creates a huge table with too many (unnecessary, for
> this script) columns.
> I was wondering then if there was a way to specify the calculation for just
> that single statistic.
>
> Also, I wanted to ask you if there is a way to access the source code of a
> specific module (in this case, v.rast.stats) via web (without downloading
> the whole source code), just to have a quick look at it (and try to adapt
> it to my needs, eventually contribute to it if possible, ... I don't know,
> ... just wondering what's the right way to do it ...).
> This might be a stupid question, but please take into account that i'm
> still quite new in all this (fascinating) stuff.
>
> Thank you very much in advance.
> Regards
>
> --
> Ismael G.
> Ingeniero de Caminos (UPM). Ingénieur des Ponts et Chaussées (ENPC).
> PhD researcher @ Urban & Land Planning Department @ ETSICCP UPM
> www.caminos.upm.es +34 91 336 67 83
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.osgeo.org/pipermail/grass-user/attachments/20120418/8ab10514/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Wed, 18 Apr 2012 21:25:51 +0200
> From: Moritz Lennert <mlennert at club.worldonline.be>
> Subject: Re: [GRASS-user] v.rast.stats for just a single statistic, in
>        a python        loop
> To: Ismael G?mez <gomez.ismael at gmail.com>
> Cc: grass mailing list <grass-user at lists.osgeo.org>
> Message-ID: <4F8F153F.5080203 at club.worldonline.be>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 18/04/12 20:54, Ismael Gómez wrote:
> > Hello,
> >
> > I would like to use the v.rast.stats inside a loop in a python script.
> > The thing is I just need to get one of the nine columns it generates
> (sum).
> > As it runs many times in the loop, it takes a lot of (unnecessary, for
> > this script) time and also creates a huge table with too many
> > (unnecessary, for this script) columns.
> > I was wondering then if there was a way to specify the calculation for
> > just that single statistic.
>
> v.rast.stats is a script, so fairly easy to modify (see below for
> accessing it).
>
>
> >
> > Also, I wanted to ask you if there is a way to access the source code of
> > a specific module (in this case, v.rast.stats) via web (without
> > downloading the whole source code), just to have a quick look at it (and
> > try to adapt it to my needs, eventually contribute to it if possible,
>
> http://trac.osgeo.org/grass/browser/grass
>
> For the development version (aka grass7) go to trunk, for other version
> to branches.
>
> For v.rast.stats in the 6.4 release branch:
>
>
> http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/scripts/v.rast.stats/v.rast.stats
> .
>
> See "Download in other formats" at the bottom for downloading it.
>
> A quick and dirty guess would be that modifying
>
> line 247: BASECOLS="n min max range mean stddev variance cf_var sum"
>
> and
>
> line 368    sed -e '1d' "$STATSTMP" | awk -F "|" '{printf "\nUPDATE
> '${TABLE}' SET '${col1}' = %i , '${col2}' = %.2f , '${col3}' = %.2f ,
> '${col4}' = %.2f , '${col5}' = %.2f , '${col6}' = %.2f , '${col7}' =
> %.2f , '${col8}' = %.2f , '${col9}' = %.2f WHERE '${KEYCOL}' = %i;",
> $2,$3,$4,$5,$6,$7,$8,$9,$10,$1}' > "$SQLTMP"
>
> could actually be enough.
>
> Moritz
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 18 Apr 2012 12:31:34 -0700 (PDT)
> From: Hamish <hamish_b at yahoo.com>
> Subject: Re: [GRASS-user] Simultaneous r.horizon processes
> To: Collin Bode <collin at berkeley.edu>, Daniel Lee
>        <lee at isi-solutions.org>
> Cc: GRASS user list <grass-user at lists.osgeo.org>
> Message-ID:
>        <1334777494.42576.YahooMailClassic at web110008.mail.gq1.yahoo.com>
> Content-Type: text/plain; charset=iso-8859-1
>
> Daniel wrote:
> > What do you mean, r.sun can do multithreading? I've heard that
> > r.sun uses multithreading in GRASS 7, but is that implemented
> > in GRASS 6? Or are you talking about "poor man's
> > multithreading," like on the GRASS wiki?
>
> there is OpenCL GPU accel. support, but it has not yet been
> merged into grass 7. (mea culpa)
>
> for r.sun being run 365 (or whatever) times in a row the "poor
> man's" method is fine, in fact the r3.in.xyz script in addons
> is perhaps the most efficient multi-CPUing in grass to date.
> (to my surprise)
>
>
> I've just read through the r.horizon code in devbr6 and I don't
> see anything which makes the module unable to be run multiple
> times in the same mapset. (no external region setting, no
> generically named temp files, no gratuitous use of grass library
> global variables)   ... are you running under NFS or similar as
> addressed by Markus's script? aka maybe the trouble is rooted
> elsewhere?
>
> > I did a little debugging today and think it's due to the large
> > size of my study area (~36 km², 0.5m resolution).
>
> 72000x72000, how much ram does r.horizon use?
> maybe processes are being killed as you run out of RAM.
> in that case set max num of parallel jobs so that it fits
> into memory without going into swap space instead of num of CPUs.
> and error handling in the script (test for '$? -ne 0') could
> help try failing runs again.
>
> > If I spatially partition the area and then stitch everything
> > back together, I hope it works - tests on smaller regions have
> > worked correctly thus far but I'll need to wait a while to see
> > the real results.
>
> for r.horizon the mountains in the distance can matter (that's
> the whole point) so I'd be careful with cutting up the region.
> temporarily lowering the region resolution during r.horizon
> may be less-bad of a compromise.
>
>
> FWIW I've tentatively given up on using r.horizon, see the "r.sun
> commissioning trials" trac ticket and wiki page. since sun
> placement changes each day, and for sub degree placement of the
> sun you need so many horizon maps as to make the loading of them
> all more expensive than just re-calculating it on-the-fly but
> with the exact placement. (I generally try for slow exactness
> instead of fast processing time though, YMMV)
> but maybe I don't correctly understand what r.horizon is doing..
>
>
> Hamish
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 18 Apr 2012 23:44:12 +0200
> From: Ismael G?mez <gomez.ismael at gmail.com>
> Subject: Re: [GRASS-user] v.rast.stats for just a single statistic, in
>        a       python loop
> To: Moritz Lennert <mlennert at club.worldonline.be>
> Cc: grass mailing list <grass-user at lists.osgeo.org>
> Message-ID:
>        <CAN4+wUjvUULZoQsPp0_VtjU79ACi2DMFWmiFo4Z2Y2dH-XFFQg at mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> Thanks a million, Moritz.
> Yours,
> Ismael
>
> 2012/4/18 Moritz Lennert <mlennert at club.worldonline.be>
>
> > On 18/04/12 20:54, Ismael Gómez wrote:
> >
> >> Hello,
> >>
> >> I would like to use the v.rast.stats inside a loop in a python script.
> >> The thing is I just need to get one of the nine columns it generates
> >> (sum).
> >> As it runs many times in the loop, it takes a lot of (unnecessary, for
> >> this script) time and also creates a huge table with too many
> >> (unnecessary, for this script) columns.
> >> I was wondering then if there was a way to specify the calculation for
> >> just that single statistic.
> >>
> >
> > v.rast.stats is a script, so fairly easy to modify (see below for
> > accessing it).
> >
> >
> >
> >
> >> Also, I wanted to ask you if there is a way to access the source code of
> >> a specific module (in this case, v.rast.stats) via web (without
> >> downloading the whole source code), just to have a quick look at it (and
> >> try to adapt it to my needs, eventually contribute to it if possible,
> >>
> >
> > http://trac.osgeo.org/grass/**browser/grass<
> http://trac.osgeo.org/grass/browser/grass>
> >
> > For the development version (aka grass7) go to trunk, for other version
> to
> > branches.
> >
> > For v.rast.stats in the 6.4 release branch:
> >
> > http://trac.osgeo.org/grass/**browser/grass/branches/**
> > releasebranch_6_4/scripts/v.**rast.stats/v.rast.stats<
> http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/scripts/v.rast.stats/v.rast.stats
> >
> > .
> >
> > See "Download in other formats" at the bottom for downloading it.
> >
> > A quick and dirty guess would be that modifying
> >
> > line 247: BASECOLS="n min max range mean stddev variance cf_var sum"
> >
> > and
> >
> > line 368    sed -e '1d' "$STATSTMP" | awk -F "|" '{printf "\nUPDATE
> > '${TABLE}' SET '${col1}' = %i , '${col2}' = %.2f , '${col3}' = %.2f ,
> > '${col4}' = %.2f , '${col5}' = %.2f , '${col6}' = %.2f , '${col7}' =
> %.2f ,
> > '${col8}' = %.2f , '${col9}' = %.2f WHERE '${KEYCOL}' = %i;",
> > $2,$3,$4,$5,$6,$7,$8,$9,$10,$**1}' > "$SQLTMP"
> >
> > could actually be enough.
> >
> > Moritz
> >
>
>
>
> --
> Ismael G.
> Ingeniero de Caminos (UPM). Ingénieur des Ponts et Chaussées (ENPC).
> PhD researcher @ Urban & Land Planning Department @ ETSICCP UPM
> www.caminos.upm.es +34 91 336 67 83
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.osgeo.org/pipermail/grass-user/attachments/20120418/9ddc3f11/attachment-0001.html
>
> ------------------------------
>
> Message: 5
> Date: Wed, 18 Apr 2012 15:48:34 -0700 (PDT)
> From: Rich Shepard <rshepard at appl-ecosys.com>
> Subject: [GRASS-user] r.watershed: output basin map
> To: grass-users at lists.osgeo.org
> Message-ID:
>        <alpine.LNX.2.00.1204181543020.24382 at salmo.appl-ecosys.com>
> Content-Type: text/plain; charset="us-ascii"
>
>   The attached pdf shows the basin map output by r.watershed based on a 10m
> DEM and a threshold of 150000. The NHD level 6 subbasins are outlined in
> black and the 1:24K NHD streams are in blue.
>
>   The small white areas at the bottom left and center right appear to be
> external to defined sub-basins. But I don't know how to interpret the
> larger
> white areas with streams in them (center and top). The top margin is an
> international boundary so I can understand not being able to completely
> define sub-basins across that boundary since the DEM doesn't reach that far
> north, but it's not consistently white.
>
>   Please help me interpret the white areas with vector streams.
>
> TIA,
>
> Rich
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: ebeco-basins.pdf
> Type: application/pdf
> Size: 32471 bytes
> Desc:
> Url :
> http://lists.osgeo.org/pipermail/grass-user/attachments/20120418/beb8bc6c/ebeco-basins.pdf
>
> ------------------------------
>
> _______________________________________________
> grass-user mailing list
> grass-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
>
> End of grass-user Digest, Vol 72, Issue 37
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-user/attachments/20120419/722d15e9/attachment-0001.html