[GRASS-dev] [SoC] Weekly report #3 - GRASS Interactive Scatter Plot Tool

[Michael Barton]

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 <markus.metz.giswork at gmail.com>
 wrote:

> On Sat, Jul 6, 2013 at 4:19 PM, Štěpán Turek <stepan.turek at seznam.cz> 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 <Michael.Barton at asu.edu>
>> 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
>> grass-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev