Re: [GRASS-dev] natural neighbor in G7?
On 15/04/14 21:44, Martin Landa wrote: Hi, 2014-04-14 18:03 GMT+02:00 Moritz Lennert mlenn...@club.worldonline.be: [...] thanks for your useful comments! One additional reflection, though: I don't think that CGAL provides a C-API which, IIUC, would mean that the module would have to be programmed in C++. Somewhat of a showstopper... Right, such modules would be written in C++. We have already several modules written in C++, so I wouldn't call it as a showstopper... Well these modules are generally not core functionality, and for some (e.g. r.terraflow) C-equivalents exist. And IIRC general consenus on this list has been to try to avoid C++ code. But you wrote: On 08/04/14 14:03, Martin Landa wrote: This would require a new dependency for GRASS. CGAL is very powerful library and could be probably used by other modules in the future. This would imply a more extensive use of the library and thus more C++ modules which would be a move away from current practice (at least in the way I have perceived it). Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #718: r.li forgets mask/illegal filename
#718: r.li forgets mask/illegal filename
+---
Reporter: kyngchaos | Owner: grass-dev@…
Type: defect | Status: closed
Priority: major | Milestone: 6.4.4
Component: Raster | Version: svn-releasebranch64
Resolution: fixed |Keywords: r.li, smp
Platform: All| Cpu: All
+---
Changes (by neteler):
* status: new = closed
* resolution: = fixed
Comment:
Replying to [comment:30 mmetz]:
Replying to [comment:29 neteler]:
I retested it with current 6.4.svn:
{{{
g.region rast=lsat7_2002_40 -p
mkdir -p $HOME/.r.li/history/
echo SAMPLINGFRAME 0|0|1|1
SAMPLEAREA 0.0|0.0|1.0|1.0 $HOME/.r.li/history/landsat_test
r.li.shannon map=lsat7_2002_40 conf=landsat_test out=landsat_shannon
r.univar landsat_shannon
ERROR: Raster map landsat_shannon not found
}}}
... no output is produced by r.li.shannon.
With this configuration, the output is a text file. The
r.li daemon should have printed a corresponding message with
the path to the output file.
It now does in the backported, corrected version:
{{{
r.li.shannon map=lsat7_2002_40 conf=landsat_test out=landsat_shannon
Result written to ASCII file /home/neteler/.r.li/output/landsat_shannon
}}}
The original issue reported here should also be fixed in the new version.
Closing, feel free top reopen if needed.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/718#comment:31
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] Who wants GUI and who does not and why
Maybe some of the earlier involved developers can share their thoughts on the Tcl/Tk GUI and its integration, its rise and fall, why and where this experience can lead the wxPython GUI now... On 16 April 2014 08:00, Vaclav Petras wenzesl...@gmail.com wrote: Hi all, I believe, I was calling for this discussion recently, and I'm calling for it again. It seems that there are quite different opinions on GRASS GIS GUI ranging from GUI is the only thing which brings us new users to no GUI needed. There is no better time to discuss this: we are discussing issues with MS Windows support, planing to release 7, working towards compatibility of 7 with QGIS and gvSIG, and we also discussed WebGRASS topic recently. Here are recent quotations from Handling of Python scripts on MS Windows discussion ( http://lists.osgeo.org/pipermail/grass-dev/2014-April/068269.html) with few notes and questions but feel free to start wherever you want. On Sun, Apr 13, 2014 at 12:52 PM, Benjamin Ducke bendu...@fastmail.fmwrote: On Sun, Apr 13, 2014 at 11:03 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: [Side note: The same discussion should also constantly be held about functionality which is specific to the GUI, because specifically developed for it), i.e. not just a GUI layer above command line functionality, something I'm afraid to see creep in more and more...] Does this mean that you want remove everything from `gui/*` besides `gui/wxpython/forms/*`? Agreed. Once more, I plead for a clean separation between GUI and CLI developments, and a disconnection of their release cycles. I see some advantages, for example just using same bug tracker makes difficult to say what is critical issue; but there are some GUI errors are tightly coupled to core module issues. On the other hand, I don't see how these disconnected release cycles would work. Also it seems that it is impossible or very hard to create good GUI without the support of the processing and management tools. The wxPython GUI can be considered a monolithic application, and FWIW it can pull every trick in the book to integrate a Python interpreter, and to make it all easier for Windows users. ... I would say: Consider the wxGUI, the QGIS and gvSIG plug-ins etc. monolithic applications and let their maintainers figure out how to deal with this. In the gvSIG CE project, we do a lot of hair- raising stuff to hide the complexity of GRASS and its dependencies from the end user, and I suspect so does QGIS. But I would not advocate the same approach to the core GRASS architecture. Than perhaps, no wxGUI is needed because we have QGIS and gvSIG plugins. Managing one GUI less in OSGeo could save some work. For example, QGIS GRASS plugin is developed separately, so there is no need to have another graphical user interface for GRASS with disconnect development. I also think that some of the debate comes from the question of whether the wxGUI should have a special status or whether it should just be treated as one of the hundreds of modules that GRASS offers. This is more or less the current state, there is g.gui, you can start without it, there are g.gui.* modules. On the other hand, there is always something spatial with GUI, e.g. if you want GUI to start when module is started without parameters/with --ui. Or, are you satisfied with the situation as it is now? Thanks for sharing your thoughts, Vaclav ___ 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] #1214: r.li.edgedensity: segmentation fault
#1214: r.li.edgedensity: segmentation fault
--+-
Reporter: neteler | Owner: grass-dev@…
Type: defect| Status: new
Priority: normal| Milestone: 6.4.4
Component: Raster| Version: svn-releasebranch64
Keywords: r.li.edgedensity |Platform: All
Cpu: x86-64|
--+-
Comment(by neteler):
Replying to [comment:12 mmetz]:
I have cleaned up the backport to 6.4 a bit in r59598
I needed to add r59743 in order to avoid odd error messages if the input
map is not there. Still I get
{{{
GRASS 6.4.4svn (spearfish60):~ g.gisenv set=DEBUG=1
GRASS 6.4.4svn (spearfish60):~ r.li.edgedensity map=geology
conf=movwindow7 output=edens_out
D1/1: r.li.daemon pathSetup: [/home/neteler/.r.li/history/movwindow7]
Illegal filename. Character not allowed.
Illegal filename. Character not allowed.
Illegal filename. Character not allowed.
...
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/1214#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
[GRASS-dev] G7 d.mon wx0 initialization issue for large raster maps
Hi, when trying to render a large raster map with d.rast in the command line version (d.mon wx0), then it tries to use the current region which leads to a cairo memory error. It seems that the wxGUI is initializing the display in a more reasonable way to downsample the map to be rendered on the fly since it makes no sense to render it at original resolution. This magic is yet missing in d.mon. Where is that calculated in wxGUI to get an idea about the calculation of map display window size versus raster map size/resolution? thanks Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] i.spectral limited to 400 files
Hi, is there a way to modify i.spectral to remove the limit of 400 files: i.spectral -c group=ta_group@PERMANENTcoordinates=104.118832166,14.7585647484,103.525338069,13.0911289527,103.304897404,12.9328638602 output=/home/yann/dev/grass-promo/grassposter/2014_EGU_WD_Landscape/images/ta_spectral ERROR: Can only do up to 400 raster maps (400 given) ERROR: No data returned from query I have about 1500 files in the group. -- ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2223: v.buffer flags -s and -c not working(?)
#2223: v.buffer flags -s and -c not working(?) -+-- Reporter: jbrauner | Owner: grass-dev@… Type: defect | Status: new Priority: minor| Milestone: 7.0.0 Component: Vector | Version: svn-trunk Keywords: v.buffer |Platform: All Cpu: Unspecified | -+-- Comment(by neteler): To my knowledge v.buffer only works properly when compiled with GEOS support. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2223#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] natural neighbor in G7?
2014-04-16 10:33 GMT+02:00 Moritz Lennert mlenn...@club.worldonline.be: Right, such modules would be written in C++. We have already several modules written in C++, so I wouldn't call it as a showstopper... Well these modules are generally not core functionality, and for some (e.g. are you considering narural neighbor as a core functionality? ;-) r.terraflow) C-equivalents exist. And IIRC general consenus on this list has been to try to avoid C++ code. I would say that there is consensus about libraries, not modules. Martin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2138: winGRASS6.4.svn - addon python script status?
#2138: winGRASS6.4.svn - addon python script status? -+-- Reporter: hellik | Owner: grass-dev@… Type: defect | Status: new Priority: blocker | Milestone: 6.4.4 Component: Addons | Version: svn-releasebranch64 Keywords: wingrass, addon, python |Platform: MSWindows 7 Cpu: x86-64 | -+-- Comment(by martinl): Replying to [comment:1 hellik]: I'm a little bit lost in g.extension.py to change the path to addons correctly also for addon python script ... it was just a typo, should be fixed in r59750 -- Ticket URL: http://trac.osgeo.org/grass/ticket/2138#comment:11 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] #2138: winGRASS6.4.svn - addon python script status?
#2138: winGRASS6.4.svn - addon python script status? -+-- Reporter: hellik | Owner: martinl Type: defect | Status: assigned Priority: blocker | Milestone: 6.4.4 Component: Addons | Version: svn-releasebranch64 Keywords: wingrass, addon, python |Platform: MSWindows 7 Cpu: x86-64 | -+-- Changes (by martinl): * cc: grass-dev@… (added) * owner: grass-dev@… = martinl * status: new = assigned -- Ticket URL: http://trac.osgeo.org/grass/ticket/2138#comment:12 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] Show manual in Install extension from addons in trunk does not work
Hi, when I use context menu and click Show manual in Install extension from addons in trunk does not work the link does not exists. I really don't have any idea whether the page is not there or a link is wrong. Example of link: http://grass.osgeo.org/grass71/manuals/addons/g.proj.all.html By the way, I'm also thinking if we want similar context menu in Search modules tab. Should it go online too? Vaclav ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
