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, <[email protected]> wrote: > Send grass-user mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > Subject: [GRASS-user] v.rast.stats for just a single statistic, in a > python loop > To: grass mailing list <[email protected]> > Message-ID: > <can4+wujd-9tms_ad1z6w5zi3trvusvpyfp60vusygebnxlq...@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 <[email protected]> > Subject: Re: [GRASS-user] v.rast.stats for just a single statistic, in > a python loop > To: Ismael G?mez <[email protected]> > Cc: grass mailing list <[email protected]> > Message-ID: <[email protected]> > 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 <[email protected]> > Subject: Re: [GRASS-user] Simultaneous r.horizon processes > To: Collin Bode <[email protected]>, Daniel Lee > <[email protected]> > Cc: GRASS user list <[email protected]> > Message-ID: > <[email protected]> > 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 <[email protected]> > Subject: Re: [GRASS-user] v.rast.stats for just a single statistic, in > a python loop > To: Moritz Lennert <[email protected]> > Cc: grass mailing list <[email protected]> > Message-ID: > <can4+wujvuulzoqspp0_vtju79aci2dmfwmifo4z2y2dh-xf...@mail.gmail.com > > > Content-Type: text/plain; charset="iso-8859-1" > > Thanks a million, Moritz. > Yours, > Ismael > > 2012/4/18 Moritz Lennert <[email protected]> > > > 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 <[email protected]> > Subject: [GRASS-user] r.watershed: output basin map > To: [email protected] > Message-ID: > <[email protected]> > 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-user > > > End of grass-user Digest, Vol 72, Issue 37 > ****************************************** >
_______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
