On Sat, Jul 6, 2013 at 4:19 PM, Štěpán Turek <stepan.tu...@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.bar...@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@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
