FWIW, r.stats respects any changes in computational region but I don't think that r.out.bin does. r.stats also will calculate values from multiple rasters, along with xy coordinates in one pass. These are a couple of the reasons I used r.stat to collect data on rasters.
Michael ____________________ C. Michael Barton Director, Center for Social Dynamics & Complexity Professor of Anthropology, School of Human Evolution & Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Jul 6, 2013, at 9:29 AM, Markus Metz <[email protected]> wrote: > On Sat, Jul 6, 2013 at 4:19 PM, Štěpán Turek <[email protected]> wrote: >> Hi Hamish and Michael, >> >> your questions are connected I will try to explain both. >> >> The scatter plot tool backend is run in same process as wxGUI. If you select >> some area in scatter plot, then data from numpy arrays are passed to the >> backend (through ctypes), which describes selected areas in scatters plots. > > You probably don't need ctypes for that, have a look at > lib/python/script/array.py. > > If you want to use ctypes, keep in mind that GRASS is designed for > modular use. Tools using library functions must run as a separate > process, i.e. the wxGUI should run just fine also in the absence of > ctypes. > >> And the backend computes corresponding areas which will be highlighted in >> all opened scatter plots. To avoid frozing of the wxGUI, the computation is >> done in separate python thread. >> >> Currently r.out.bin is used to bypass inability to set region in raster >> library for different rasters. When user choose raster group for analysis in >> the tool, it is exported into binary files in current region and the backend >> works directly with the binary files. This is not very nice. >> >> If the backend would be written as module, then I would need to create >> temporary files to pass the selected areas, which does not seem very elegant >> to me. > > When processing raster data, temporary files are created pretty much > all the time (by the raster lib). Regarding the scatterplot tool which > works with raster data which can be very large, an advantage of > temporary files is that out-of-memory errors are more easily avoided. >> >> In simplified way the idea is that the library should give you option >> whether you want to open and then work with raster file according to the >> statically set variables (in structure R__) or open it with dynamically >> defined variables. > > With regard to the current region, it seems to me that this would > violate the concept of the current region. Rather run the scatterplot > tool as a separate process, then you can modify the region without > changing the regular current region. When using raster lib functions > directly, maybe Rast_set_input_window() can help you? >> >> It could be also useful for Pietro's pyGRASS API. And it would be first >> small step to achieve compilation of raster modules as library instead of >> different programs. I am working on more concrete proposal of the changes in >> raster library during this weekend. > > Raster modules, as all GRASS modules, should (IMHO must definitively) > stay modules because GRASS is designed for modular use. Modules can > easily call other modules, effectively using them instead of some, > just like some library function. Again, the advantage is that modules > are run as a separate process. > > my 2c > > Markus M >> >> I am new to this problematic, so all these suggestions can be totally >> wrong.. >> >> Best >> Stepan >> >> ---------- Původní zpráva ---------- >> Od: Michael Barton <[email protected]> >> Datum: 6. 7. 2013 >> Předmět: Re: [SoC] Weekly report #3 - GRASS Interactive Scatter Plot Tool >> >> >> So I take it you are not using r.stats to generate the data to plot, but are >> getting data directly accessing rasters via GRASS libraries? >> >> Michael >> ______________________________ >> >> >> >> Hi, >> >> I am interested to hear more about the library limitations.. you >> mean the WIND region, right? I'd be surprised if WIND_OVERRIDE or >> GRASS_REGION enviro variables (and the python wrappers for them) >> didn't provide full control for whatever someone might like to do. >> >> I would guess if the scatter tool was spawned as an independent >> process, it could maintain its own environment & so it's own region >> override enviro variables. or simply unset the wxGUI display overrides >> and just use the mapset's real computational region read directly from >> the WIND file? >> >> >> regards, >> Hamish >> >> >> >> _______________________________________________ >> grass-dev mailing list >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/grass-dev _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
