Re: [GRASS-dev] [pygrass] should I use ctypes or cython?
Hi Pietro, dear developers, i think we should stay with ctypes as this is already supported by GRASS. Also the benchmark results are looking very promising regarding efficiency to me. Best regards Soeren 2012/6/19 Pietro peter.z...@gmail.com: Dear all, I'm going on with the GSoC, and I'm using ctypes to call the Grass's function, but I found this comment: http://stackoverflow.com/a/5686873 (from a cython developer) that it has instilled in me a doubt that using Cython (http://cython.org/) could make pygrass more flexible/extensible. From my point of view I prefer ctypes, because it is already inside grass and because I need to get something running quickly, but maybe could be more useful for Grass to implement less code but with a tool that give more flexibility in the future... What do you think? Can I go on with my GSoC project using ctypes? should i switch to Cython? I did some benchmarks to test the speed of pygrass, and it is not too bad. Below I reported the execution time of add a number to a Raster map, using r.mapcal module, the RasterRow class (using Rast_get_row, and Rast_put_row functions), and using the Segmentation library (segment_get_row and segment_put_row): r.mapcalc +2; 21.487251 sec/pass RasterRow +2; 11.181928 sec/pass RasterSeg +2; 14.730741 sec/pass Test an if condition: r.mapcalc if; 14.240596 sec/pass RasterRow if; 14.753899 sec/pass RasterSeg if; 19.982334 sec/pass Test a function: r.mapcalc sqrt; 16.495872 sec/pass RasterRow sqrt; 18.591585 sec/pass RasterSeg sqrt; 22.305732 sec/pass You may find the code here: git clone https://code.google.com/p/pygrass/ and you can run the benchmark code with: python test/benchmark.py more info on the RasterRow and RasterSegment classes are available here: http://pygrass.readthedocs.org/en/latest/raster.html Comments are welcome! Best regards, Pietro ___ 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
Re: [GRASS-dev] [GRASS GIS] #1677: Bad string in wxpython gui goutput.py
#1677: Bad string in wxpython gui goutput.py --+- Reporter: lucadelu | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 6.4.3 Component: Translations | Version: svn-releasebranch64 Keywords: wxGUI, i18n |Platform: All Cpu: All | --+- Comment(by annakrat): Fixed in grass7 in r52149 and grass65, grass64 too. See related [http://lists.osgeo.org/pipermail/grass-dev/2012-January/057628.html discussion]. In grass7 there are still many warnings in lib/python/temporal. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1677#comment:1 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1677: Bad string in wxpython gui goutput.py
#1677: Bad string in wxpython gui goutput.py --+- Reporter: lucadelu | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 6.4.3 Component: Translations | Version: svn-releasebranch64 Keywords: wxGUI, i18n |Platform: All Cpu: All | --+- Comment(by annakrat): Replying to [comment:1 annakrat]: Fixed in grass7 in r52149 and grass65, grass64 too. See related [http://lists.osgeo.org/pipermail/grass-dev/2012-January/057628.html discussion]. In grass7 there are still many warnings in lib/python/temporal. Sorry, I forgot quotes, fixed again in r52154. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1677#comment:2 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] gettext warnings
Hi,
I would like just to remind you of the warnings which you get after
'make pot' in ./locale. The warnings came from ./lib/python/temporal.
Here is the related ticket [1] and mail discussion [2].
This problem can be solved using:
message = _(Selected map %(map)s is not in current mapset %(mapset)s. %
{ 'map' : self.mapName, 'mapset' :
grass.gisenv()['MAPSET'] }
Perhaps we could add a note to the SUBMITTING_PYTHON document?
Anna
[1] http://trac.osgeo.org/grass/ticket/1677
[2] http://lists.osgeo.org/pipermail/grass-dev/2012-January/057674.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] gettext warnings
Hi Anna,
thanks for the reminder. It is on my todo list but with low priority,
since the temporal GIS framework is still in early development phase
and i focus on usability, functionality and module documentation right
now.
I will respect the guideline when writing/updating messages in the
temporal framework. When i begin with code polishing, the messages get
fixed.
Best regards
Soeren
2012/6/20 Anna Kratochvílová kratocha...@gmail.com:
Hi,
I would like just to remind you of the warnings which you get after
'make pot' in ./locale. The warnings came from ./lib/python/temporal.
Here is the related ticket [1] and mail discussion [2].
This problem can be solved using:
message = _(Selected map %(map)s is not in current mapset %(mapset)s.
%
{ 'map' : self.mapName, 'mapset' :
grass.gisenv()['MAPSET'] }
Perhaps we could add a note to the SUBMITTING_PYTHON document?
Anna
[1] http://trac.osgeo.org/grass/ticket/1677
[2] http://lists.osgeo.org/pipermail/grass-dev/2012-January/057674.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] adding a flag to discard NULL values in mapalgebra aggregation functions
Following a thread I've opened on the grass-users list, I would like to suggest a proposal to add a flag, to the r.mapcalc command, to discrd NULL values when evaluating aggregation functions like max(), min(), mode(), etc. Looking into the code of, for example., the max() function [1], it seems that if a NULL value is in the set of the arguments, the result is set to NULL (if I understand it correctly). With the proposed flag, I would like to ask r.mapcalc to do not consider the NULLs, and to the calculations only on the not-NULL subset of values. This would let us do filtering (with row/columns offsets) as it is done in r.neighbors, where the NULL values are directly discarded. giovanni [1] http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.mapcalc/xmax.c ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] adding a flag to discard NULL values in mapalgebra aggregation functions
Hi Giovanni, all, On Wed, Jun 20, 2012 at 12:17 PM, G. Allegri gioha...@gmail.com wrote: Following a thread I've opened on the grass-users list, I would like to suggest a proposal to add a flag, to the r.mapcalc command, to discrd NULL values when evaluating aggregation functions like max(), min(), mode(), etc. Looking into the code of, for example., the max() function [1], it seems that if a NULL value is in the set of the arguments, the result is set to NULL (if I understand it correctly). With the proposed flag, I would like to ask r.mapcalc to do not consider the NULLs, and to the calculations only on the not-NULL subset of values. Shouldn't it be the default behavior? ciao madi This would let us do filtering (with row/columns offsets) as it is done in r.neighbors, where the NULL values are directly discarded. giovanni [1] http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.mapcalc/xmax.c ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Dr. Margherita Di Leo ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] adding a flag to discard NULL values in mapalgebra aggregation functions
Shouldn't it be the default behavior? I supposed it too, but it isn't ;) giovanni ciao madi This would let us do filtering (with row/columns offsets) as it is done in r.neighbors, where the NULL values are directly discarded. giovanni [1] http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.mapcalc/xmax.c ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Dr. Margherita Di Leo ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1505: rfe: r3.support
#1505: rfe: r3.support --+- Reporter: hamish | Owner: huhabla Type: enhancement | Status: closed Priority: major| Milestone: 7.0.0 Component: Raster3D | Version: svn-trunk Resolution: fixed|Keywords: r3.support Platform: All | Cpu: All --+- Changes (by huhabla): * status: assigned = closed * resolution: = fixed Comment: r3.support has been Implemented.Closing this ticket. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1505#comment:3 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
