Re: [GRASS-dev] seemingly random errors in r.mapcalc
On Fri, Aug 2, 2013 at 4:32 AM, Glynn Clements gl...@gclements.plus.com wrote: Paulo van Breugel wrote: I am really puzzled as to what is going on here. Any idea what I am doing wrong here or what could be the cause? My first suspicion would be hardware issues, e.g. a failing disk drive. Please post your compiler flags as well (if you compiled yourself). Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] seemingly random errors in r.mapcalc
On 08/02/2013 09:16 AM, Markus Neteler wrote: On Fri, Aug 2, 2013 at 4:32 AM, Glynn Clements gl...@gclements.plus.com wrote: Paulo van Breugel wrote: I am really puzzled as to what is going on here. Any idea what I am doing wrong here or what could be the cause? My first suspicion would be hardware issues, e.g. a failing disk drive. OK, that would be inconvenient, to use an understatement. I hadn't though about it because I do not seem to have trouble with other programs / data on that disk, but I'll check if the same problems occur when running the calculations with data on another HD. Please post your compiler flags as well (if you compiled yourself). Markus These are the configure / make / make install steps I follow: ./configure --prefix=/usr/local/grass7 --enable-64bit --with-libs=/lib64 --with-sqlite --with-odbc --with-cairo --with-geos --with-cxx=yes --with-gdal=/usr/local/gdal1.9/bin/gdal-config --with-python=yes --with-wxwidgets=/usr/bin/wx-config --with-tcltk-includes=/usr/include/tcl8.5 --with-readline --with-freetype --with-freetype-includes=/usr/include/freetype2 --enable-largefile --with-motif --with-motif-includes=/usr/include --with-proj-share=/usr/share/proj --with-pthread --with-postgres --with-postgres-libs=/usr/include/postgresql/libpq --with-postgres-includes=/usr/include/postgresql --with-lapack --with-blas --with-opencl make -j4 sudo make install sudo ln -s /usr/local/grass7/bin/grass70 /usr/bin/ ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] standalone installer cleanup
Hi, re. r57342, the PROJ_LIB variable is needed by e.g. cs2cs used by some scripts, and I'm not sure if the removal of tcl/tk from the PATH was intentional or just an over-merge, but fwiw a functioning gis.m should remain as an alternative in case there are multiple-python install problems (as ongoing) or just because someone likes to use it for whatever reason. thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] standalone installer cleanup
Hi, 2013/8/2 Hamish hamis...@yahoo.com: re. r57342, the PROJ_LIB variable is needed by e.g. cs2cs used by some scripts, are you sure about that?, proj lib in the path (`extralib`) or it refers to share stuff? and I'm not sure if the removal of tcl/tk from the PATH was intentional or just an over-merge, but fwiw a functioning gis.m should remain as an alternative in case there are multiple-python install problems (as ongoing) or just because someone likes to use it for whatever reason. it's intentional. BTW, tcl/tk is currently only GUI which is working in standalone installer. wxGUI is broken thanks to MAXREPEAT problem. Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] standalone installer cleanup
2013/8/2 Martin Landa landa.mar...@gmail.com: 2013/8/2 Hamish hamis...@yahoo.com: re. r57342, the PROJ_LIB variable is needed by e.g. cs2cs used by some scripts, are you sure about that?, proj lib in the path (`extralib`) or it refers to share stuff? quickly checking proj manual. IAIW, PROJ_LIB should point to the `share` directory. If so I will restore this environmental variable. Martin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2042: wxgui: no more menu access to r.in.gdal / v.in.ogr
#2042: wxgui: no more menu access to r.in.gdal / v.in.ogr --+- Reporter: mlennert | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: r.in.gdal, v.in.ogr, gui |Platform: Unspecified Cpu: Unspecified | --+- Comment(by martinl): Replying to [comment:1 annakrat]: The button was removed in r54618. I don't have any strong opinion on this. Perhaps the button might be confusing for users? I would say that this button can be confusing to the normal user. Advanced users can launch r.in.gdal's autogenerated dialog from wxGUI command prompt by running `r.in.gdal --ui`. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2042#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
Re: [GRASS-dev] [GRASS GIS] #2042: wxgui: no more menu access to r.in.gdal / v.in.ogr
#2042: wxgui: no more menu access to r.in.gdal / v.in.ogr --+- Reporter: mlennert | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: r.in.gdal, v.in.ogr, gui |Platform: Unspecified Cpu: Unspecified | --+- Comment(by martinl): Replying to [comment:3 martinl]: Replying to [comment:1 annakrat]: The button was removed in r54618. I don't have any strong opinion on this. Perhaps the button might be confusing for users? I would say that this button can be confusing to the normal user. Advanced users can launch r.in.gdal's autogenerated dialog from wxGUI command prompt by running `r.in.gdal --ui`. Moreover running `r.in.gdal` from wxGUI command line should also launch GUI front-end. The autogenerated dialog should appear only when `--ui` switch is used. Similarly for the other modules which have special frontend, e.g. `i.group`. From my personal experience, the user in the class were very confused when they got different GUI dialog when running `i.group` from the menu and command prompt. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2042#comment:4 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] standalone installer cleanup
hi, Martin Landa wrote 2013/8/2 Martin Landa lt; landa.martin@ gt;: 2013/8/2 Hamish lt; hamish_b@ gt;: re. r57342, the PROJ_LIB variable is needed by e.g. cs2cs used by some scripts, are you sure about that?, proj lib in the path (`extralib`) or it refers to share stuff? quickly checking proj manual. IAIW, PROJ_LIB should point to the `share` directory. If so I will restore this environmental variable. Martin ___ grass-dev mailing list grass-dev@.osgeo http://lists.osgeo.org/mailman/listinfo/grass-dev thanks for restoring. have a quick look in wingrass, gdal, proj4 http://trac.osgeo.org/grass/ticket/1201 and http://lists.osgeo.org/pipermail/osgeo4w-dev/2010-October/001102.html They should all be include with wingrass. GDAL_DATA=C:\OSGeo4W\share\gdal PROJ_LIB=C:\OSGeo4W\share\proj GEOTIFF_CSV=C:\OSGeo4W\share\epsg_csv - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/standalone-installer-cleanup-tp5070418p5070434.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] seemingly random errors in r.mapcalc
One reason I did not think about problem to be related to hard drive issues is that I would expect other GRASS functions to fail, at least occasionally, as well as other programs. On Fri, Aug 2, 2013 at 4:32 AM, Glynn Clements gl...@gclements.plus.comwrote: Paulo van Breugel wrote: I am really puzzled as to what is going on here. Any idea what I am doing wrong here or what could be the cause? My first suspicion would be hardware issues, e.g. a failing disk drive. While there are certain types of programming error which can cause non-deterministic behaviour (e.g. reading uninitialised memory), neither r.mapcalc nor lib/raster have had any significant changes recently. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] seemingly random errors in r.mapcalc
Sorry, pushed the short cut sending the email off too early.. What I wanted to ask is, is there any way I can find out what kind of error I am getting? Now, the only message is Error. On Fri, Aug 2, 2013 at 12:38 PM, Paulo van Breugel p.vanbreu...@gmail.comwrote: One reason I did not think about problem to be related to hard drive issues is that I would expect other GRASS functions to fail, at least occasionally, as well as other programs. On Fri, Aug 2, 2013 at 4:32 AM, Glynn Clements gl...@gclements.plus.comwrote: Paulo van Breugel wrote: I am really puzzled as to what is going on here. Any idea what I am doing wrong here or what could be the cause? My first suspicion would be hardware issues, e.g. a failing disk drive. While there are certain types of programming error which can cause non-deterministic behaviour (e.g. reading uninitialised memory), neither r.mapcalc nor lib/raster have had any significant changes recently. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] seemingly random errors in r.mapcalc
Hi,
you can set the environment variable GRASS_SIGSEGV_ON_ERROR to raise a
segmentation fault signal that can be catched by gdb. Then you can
make backtrace and send it to the list.
I hope we will be able to help you then ... but i am not sure.
I assume you use bash or equivalent:
{{{
export GRASS_SIGSEGV_ON_ERROR=1
gdb r.mapcalc
(gdb) r expr=test = 1 + 1
...
(gdb) bt
... stack
}}}
Best regards
Soeren
2013/8/2 Paulo van Breugel p.vanbreu...@gmail.com:
Sorry, pushed the short cut sending the email off too early.. What I wanted
to ask is, is there any way I can find out what kind of error I am getting?
Now, the only message is Error.
On Fri, Aug 2, 2013 at 12:38 PM, Paulo van Breugel p.vanbreu...@gmail.com
wrote:
One reason I did not think about problem to be related to hard drive
issues is that I would expect other GRASS functions to fail, at least
occasionally, as well as other programs.
On Fri, Aug 2, 2013 at 4:32 AM, Glynn Clements gl...@gclements.plus.com
wrote:
Paulo van Breugel wrote:
I am really puzzled as to what is going on here. Any idea what I am
doing
wrong here or what could be the cause?
My first suspicion would be hardware issues, e.g. a failing disk
drive.
While there are certain types of programming error which can cause
non-deterministic behaviour (e.g. reading uninitialised memory),
neither r.mapcalc nor lib/raster have had any significant changes
recently.
--
Glynn Clements gl...@gclements.plus.com
___
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] standalone installer cleanup
2013/8/2 Martin Landa landa.mar...@gmail.com: 2013/8/2 Martin Landa landa.mar...@gmail.com: 2013/8/2 Hamish hamis...@yahoo.com: re. r57342, the PROJ_LIB variable is needed by e.g. cs2cs used by some scripts, are you sure about that?, proj lib in the path (`extralib`) or it refers to share stuff? quickly checking proj manual. IAIW, PROJ_LIB should point to the `share` directory. If so I will restore this environmental variable. done in all active branches. Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Fw: [Ubuntu] GeoGit
Hi Hamish, On Fri, Aug 2, 2013 at 3:09 AM, Hamish hamis...@yahoo.com wrote: taking the liberty of fwd'd Tim's email here, as the basic idea can be quite an important one for maintainers of cadastral data. Thanks for sharing, indeed it is interesting approach and I think we'll be testing it. Paper-trails of changes and formal metadata hooks (eg for INSPIRE) remain major missing features in GRASS. What's your idea? Perhaps could be worth to start a wiki page for discussing about it. Just a thought. -- Best regards, Dr. Margherita DI LEO Scientific / technical project officer European Commission - DG JRC Institute for Environment and Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r.info in grass 7 misses the -m flag
Hi, why was the r.info -m flag (in grass 6x) removed in grass 7? Difficult to implement, not useful? Thanks, Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #675: r.proj's use different location error while working in different dbases
#675: r.proj's use different location error while working in different dbases --+- Reporter: nikos| Owner: grass-dev@… Type: defect | Status: closed Priority: major| Milestone: 6.4.4 Component: Raster | Version: unspecified Resolution: fixed|Keywords: r.proj, dbase, location, indbase-answer, inlocation-answer Platform: Unspecified | Cpu: Unspecified --+- Changes (by nikos): * status: new = closed * resolution: = fixed * milestone: 6.4.0 = 6.4.4 Comment: This seems to work in both grass 64 and 7. Marking as fixed. ps- I regained access to my old account nikos. Will only act, with this username, upon past tickets created by this username! All present and future actions in trac with my nikosa account. Sorry for this. -- Ticket URL: http://trac.osgeo.org/grass/ticket/675#comment:5 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] #1109: g.mlist functionality extension: return e.g. $prefix.001 to $prefix.031 out of $prefix.365 maps
#1109: g.mlist functionality extension: return e.g. $prefix.001 to $prefix.031 out of $prefix.365 maps --+- Reporter: nikos| Owner: grass-dev@… Type: enhancement | Status: closed Priority: minor| Milestone: Component: Default | Version: unspecified Resolution: fixed|Keywords: g.mlist, pattern, Platform: Unspecified | Cpu: Unspecified --+- Comment(by nikos): Cool! Very nice :-) -- Ticket URL: http://trac.osgeo.org/grass/ticket/1109#comment:13 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] #332: Uniform order for at= screen coordinates in d.* modules
#332: Uniform order for at= screen coordinates in d.* modules -+-- Reporter: nikos| Owner: grass-dev@… Type: enhancement | Status: new Priority: minor| Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: |Platform: Unspecified Cpu: Unspecified | -+-- Comment(by nikos): Is this still valid in grass 7? The --helps of the two reported modules (above) describing at= still differ? -- Ticket URL: http://trac.osgeo.org/grass/ticket/332#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
Re: [GRASS-dev] [GRASS GIS] #701: make the compilation process print-out/ look nicer :-)
#701: make the compilation process print-out/ look nicer :-) --+- Reporter: nikos| Owner: grass-dev@… Type: enhancement | Status: closed Priority: trivial | Milestone: 7.0.0 Component: Compiling| Version: unspecified Resolution: fixed|Keywords: Platform: Unspecified | Cpu: Unspecified --+- Changes (by nikos): * status: new = closed * resolution: = fixed Comment: May I close this as invalid or wontfix? -- Ticket URL: http://trac.osgeo.org/grass/ticket/701#comment:4 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] #701: make the compilation process print-out/ look nicer :-)
#701: make the compilation process print-out/ look nicer :-) --+- Reporter: nikos| Owner: grass-dev@… Type: enhancement | Status: reopened Priority: trivial | Milestone: 7.0.0 Component: Compiling| Version: unspecified Resolution: |Keywords: Platform: Unspecified | Cpu: Unspecified --+- Changes (by nikos): * status: closed = reopened * resolution: fixed = Comment: Sorry for fixed marking. I'll mark it as invalid -- if there is interest it can always be reopened. -- Ticket URL: http://trac.osgeo.org/grass/ticket/701#comment:5 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] #701: make the compilation process print-out/ look nicer :-)
#701: make the compilation process print-out/ look nicer :-) --+- Reporter: nikos| Owner: grass-dev@… Type: enhancement | Status: closed Priority: trivial | Milestone: 7.0.0 Component: Compiling| Version: unspecified Resolution: invalid |Keywords: Platform: Unspecified | Cpu: Unspecified --+- Changes (by nikos): * status: reopened = closed * resolution: = invalid -- Ticket URL: http://trac.osgeo.org/grass/ticket/701#comment:6 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] #332: Uniform order for at= screen coordinates in d.* modules
#332: Uniform order for at= screen coordinates in d.* modules --+- Reporter: nikos| Owner: grass-dev@… Type: enhancement | Status: closed Priority: minor| Milestone: 7.0.0 Component: Display | Version: svn-trunk Resolution: fixed|Keywords: d.barscale, d.legend, d.text, d.graph Platform: All | Cpu: All --+- Changes (by hamish): * status: new = closed * component: Default = Display * platform: Unspecified = All * version: unspecified = svn-trunk * keywords: = d.barscale, d.legend, d.text, d.graph * resolution: = fixed * cpu: Unspecified = All Comment: all d.* modules seem updated now to use the convention (0%,0%) of the display frame as meaning the lower-left. Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/332#comment:4 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] r.info in grass 7 misses the -m flag
Nikos: why was the r.info -m flag (in grass 6x) removed in grass 7? Difficult to implement, not useful? it was moved into 'r.info -e'. I think the idea was to have a less complicated view for the module GUI, but to me it makes it less useful from the command line. (2c) probably the none values for 'r.info -e' should just be empty, to make them easier to parse work with `eval` directly. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #332: Uniform order for at= screen coordinates in d.* modules
#332: Uniform order for at= screen coordinates in d.* modules
--+-
Reporter: nikos| Owner: grass-dev@…
Type: enhancement | Status: closed
Priority: minor| Milestone: 7.0.0
Component: Display | Version: svn-trunk
Resolution: fixed|Keywords: d.barscale, d.legend, d.text, d.graph
Platform: All | Cpu: All
--+-
Comment(by nikos):
Replying to [comment:3 nikos]:
Is this still valid in grass 7? The --helps of the two reported
modules (above) describing at= still differ?
Sorry, I wanted to... ! not ? in the end. They still differ here:
{{{
d.barscale --help
..
at The screen coordinates for top-left corner of label
(0,0) is lower-left of frame
}}}
and
{{{
d.legend --help
..
at Size and placement as percentage of screen coordinates (0,0 is lower
left)
bottom,top,left,right
options: 0-100
}}}
The d.barscale description referring to top-left is (still) confusing.
--
Ticket URL: https://trac.osgeo.org/grass/ticket/332#comment:5
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] r.info in grass 7 misses the -m flag
Nikos: why was the r.info -m flag (in grass 6x) removed in grass 7? Difficult to implement, not useful? Hamish: it was moved into 'r.info -e'. I think the idea was to have a less complicated view for the module GUI, but to me it makes it less useful from the command line. (2c) ...here, still, mechanically typing `r.info -rm` very often :D probably the none values for 'r.info -e' should just be empty, to make them easier to parse work with `eval` directly. I guess so, Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] seemingly random errors in r.mapcalc
Paulo van Breugel wrote: Sorry, pushed the short cut sending the email off too early.. What I wanted to ask is, is there any way I can find out what kind of error I am getting? Now, the only message is Error. There are only a few possible causes of Error reading raster data, namely an error from lseek(), read(), G_zlib_read() or GDALRasterIO(), or a short count returned from read(). Any of these can be caused by corrupted data, but that would normally be repeatable. G_zlib_read() is only applicable to floating-point maps, while GDALRasterIO() is only applicable to GDAL-linked maps (r.external). If it's a hardware error, it will be logged by the kernel. The log files are usually in /var/log, but which errors go in which files depends upon the distribution. If you're compiling from source, be sure to run make clean between svn update and make. Incremental compilation isn't reliable in the general case. If svn update updates the configure script, be sure to re-run configure before doing anything else. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2042: wxgui: no more menu access to r.in.gdal / v.in.ogr
#2042: wxgui: no more menu access to r.in.gdal / v.in.ogr --+- Reporter: mlennert | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: r.in.gdal, v.in.ogr, gui |Platform: Unspecified Cpu: Unspecified | --+- Comment(by hamish): As long at the button is worded correctly and put in an appropriate place, it doesn't have to be confusing. Putting it along side as a menu item might be confusing for sure. Typing 'r.in.gdal --ui' (//are you saying that just 'r.in.gdal' will not cause the module GUI to open?) from a command prompt requires prior knowledge of the module's name and knowing how to do that. Neither is inherently discoverable or self-documenting. The --ui trick is hardly widely known outside of the development team. see also the cartographic composer's way of launching the ps.map dialog from the File menu. It's there if you want/need it, but not likely to confuse new users. Similarly for the other modules which have special frontend, e.g. i.group. From my personal experience, the user in the class were very confused when they got different GUI dialog when running i.group from the menu and command prompt. I would suggest the solution there is different wording titlebar etc text in the wizard version. i.e. give them better hints along the way to guide their expectations. (easier said than done of course) regards, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/2042#comment:5 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] Weekly report #7 - GRASS Interactive Scatter Plot Tool
Hi all, 1) What do I have completed this week? I have consulted schedule with my mentor and we decided that I am going to focus on new gui part of the scatter plot. We also concluded that refactoring of digitizer is out of scope of the project and it would take too much time. I have worked on optimization of the scatter plot for data higher than 8 bit. 2) What am I going to achieve for next week? I am going to work on gui part of the project. 3) Is there any blocking issue? When I tested memory consumption of the scatter plot it showed that currently matplotlib can consume quite a lot of memory (when analyzed rasters are 12 bit). I will continue to work on that in order to reduce the memory consumption. Best Stepan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
