Re: [GRASS-dev] could r.stream.* become part of GRASS core?
On Thu, Apr 4, 2013 at 9:00 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Thu, Apr 4, 2013 at 10:21 AM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2013/4/4 Markus Neteler nete...@osgeo.org: On Thu, Nov 15, 2012 at 5:23 PM, Markus Neteler nete...@osgeo.org wrote: since the r.stream.* modules are continuously requested and IMHO sufficiently tested (according to user reports), I would move them to core if there are no objections. ... I can take care of r.stream.extract and the r.regression.* modules. (r.regression.multi is now in GRASS 7 trunk, thanks) After that I will look at the other r.stream.* modules, but of course I am happy for any help! cd grass-addons/grass7/raster/ LIST=r.stream.basins/ r.stream.distance/ r.stream.order/ r.stream.slope/ r.stream.stats/ r.stream.channel/ r.stream.extract/ r.stream.segment/ r.stream.snap/ for i in $LIST ; do cd $i ; make MODULE_TOPDIR=$HOME/grass70 ; cd .. ; done I see just a few (minor?) compiler warnings left. May be move them into trunk? markusN ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] could r.stream.* become part of GRASS core?
Hi, 2013/4/4 Markus Neteler nete...@osgeo.org: On Thu, Nov 15, 2012 at 5:23 PM, Markus Neteler nete...@osgeo.org wrote: since the r.stream.* modules are continuously requested and IMHO sufficiently tested (according to user reports), I would move them to core if there are no objections. only after major clean-up. If nobody else will do it, I could take a look on the modules later in July. 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] could r.stream.* become part of GRASS core?
Markus N wrote: since the r.stream.* modules are continuously requested and IMHO sufficiently tested (according to user reports), I would move them to core if there are no objections. Coming back to this topic (delayed due to my outage in winter): no objections, it seems. I would be happy to see r.stream.* become part of the core. At the risk of hijacking the thread, for those concerned that the menus look like a 747 cockpit of options and so are not user friendly, I'd again suggest a solution of GUI views settable from the preferences menu, to hide or show different menu items. From work packaging for debian, and from work trying to get g.extension working for everyone everywhere, the idea of breaking the core up into lots of addon toolboxes really makes me shudder. Not having to fight with out-of-sync toolboxes is one of the reasons I switched to GRASS in the first place :), and I've gotten at least two papers out of easy access to modules which performed processes that were typically not used in my field of study, which I otherwise may never have looked at. I didn't get much feedback about the GUI views idea before, but I'd still like to hear thoughts about the approach. ? Very much straying offtopic now, I'd also advocate a series of wrapper scripts to run from GUI buttons for simple-mode d.vect. (see also my d.* helper/wrapper scripts in g6 addons like d.varea, d.stations, and d.mark) I feel the current d.vect GUI window is a bit overwhelming, but that's no reason to break up the base module, since wrapper scripts can handle the simple views, and the full d.vect module gui could be there for advanced mode. r.regression.* might be another trunk candidate set. Overview: http://grasswiki.osgeo.org/wiki/AddOns/GRASS_7 I've no experience with r.regression.* as I don't do that much multi-spectral stuff, but if MarkusM was the author that's good enough for me wrt the code quality side of things. wrt the how esoteric is it? side of things, in general I'd say low-level tools/building blocks suitable for multiple purposes and useful as intermediary steps in scripts are a good match for 'core'. re. other modules to consider- One day I'd like to put the finishing touches on d.barb in g6 addons and then port it to g7 with an eye to getting it into g7 core for its d.rast.arrow-for-vectors capabilities. time, time, time.. best, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] could r.stream.* become part of GRASS core?
On Thu, Apr 4, 2013 at 10:21 AM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2013/4/4 Markus Neteler nete...@osgeo.org: On Thu, Nov 15, 2012 at 5:23 PM, Markus Neteler nete...@osgeo.org wrote: since the r.stream.* modules are continuously requested and IMHO sufficiently tested (according to user reports), I would move them to core if there are no objections. only after major clean-up. If nobody else will do it, I could take a look on the modules later in July. I can take care of r.stream.extract and the r.regression.* modules. After that I will look at the other r.stream.* modules, but of course I am happy for any help! Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] could r.stream.* become part of GRASS core?
On Thu, Nov 15, 2012 at 5:23 PM, Markus Neteler nete...@osgeo.org wrote: Hi, since the r.stream.* modules are continuously requested and IMHO sufficiently tested (according to user reports), I would move them to core if there are no objections. Coming back to this topic (delayed due to my outage in winter): no objections, it seems. r.regression.* might be another trunk candidate set. Overview: http://grasswiki.osgeo.org/wiki/AddOns/GRASS_7 Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] could r.stream.* become part of GRASS core?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 15/11/12 23:41, Helmut Kudrnovsky wrote: I agree that the quality of the r.stream.* modules is out of question. these are very nice and useful modules with high quality. For what concerns including it into the core, I would like to point you out the discussion [1] about the concept of toolboxes. The general orientation is not to include field specific groups of modules into the core and make them available in an easy way when required. but how can we guide normal users that such interesting tools are in the addons? That is an interesting and important question. One way would be to have one sub menu named Available Add-Ons which is updated automatically from the official Add-On repository. When one entry is selected, the extension manager could be opened to make installation easy. And in the menu, it could be reflected which ones are already installed. Just an idea, Cheers Rainer - best regards Helmut -- View this message in context: http://osgeo-org.1560.n6.nabble.com/could-r-stream-become-part-of-GRASS-core-tp5000607p5016768.html Sent from the Grass - Dev mailing list archive at Nabble.com. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCl9OMACgkQoYgNqgF2egr+ZQCfRo+coiU2QhmR8ty3bVyVMqjx vx4An2PDm84nsCM5wZegeH27kaxo9uGu =66J1 -END PGP SIGNATURE- ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] could r.stream.* become part of GRASS core?
On 16/11/12 09:10, Rainer M Krug wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 15/11/12 23:41, Helmut Kudrnovsky wrote: I agree that the quality of the r.stream.* modules is out of question. these are very nice and useful modules with high quality. For what concerns including it into the core, I would like to point you out the discussion [1] about the concept of toolboxes. The general orientation is not to include field specific groups of modules into the core and make them available in an easy way when required. Please also note the discussion in this thread [1], where most developpers rather seem to plead for integrating more modules directly into trunk. Toolboxes would then rather be menu blocks that you can activate or not, organising your GUI access to the relevant modules. Moritz [1] http://lists.osgeo.org/pipermail/grass-dev/2012-October/060565.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] could r.stream.* become part of GRASS core?
Hi, since the r.stream.* modules are continuously requested and IMHO sufficiently tested (according to user reports), I would move them to core if there are no objections. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] could r.stream.* become part of GRASS core?
+1 On Thu, Nov 15, 2012 at 11:23 AM, Markus Neteler nete...@osgeo.org wrote: Hi, since the r.stream.* modules are continuously requested and IMHO sufficiently tested (according to user reports), I would move them to core if there are no objections. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] could r.stream.* become part of GRASS core?
since the r.stream.* modules are continuously requested and IMHO sufficiently tested (according to user reports), I would move them to core if there are no objections. +1 - best regards Helmut -- View this message in context: http://osgeo-org.1560.n6.nabble.com/could-r-stream-become-part-of-GRASS-core-tp5000607p5016760.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] could r.stream.* become part of GRASS core?
I agree that the quality of the r.stream.* modules is out of question. these are very nice and useful modules with high quality. For what concerns including it into the core, I would like to point you out the discussion [1] about the concept of toolboxes. The general orientation is not to include field specific groups of modules into the core and make them available in an easy way when required. but how can we guide normal users that such interesting tools are in the addons? - best regards Helmut -- View this message in context: http://osgeo-org.1560.n6.nabble.com/could-r-stream-become-part-of-GRASS-core-tp5000607p5016768.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] could r.stream.* become part of GRASS core?
Ciao Enrico, I agree that the quality of the r.stream.* modules is out of question. For what concerns including it into the core, I would like to point you out the discussion [1] about the concept of toolboxes. The general orientation is not to include field specific groups of modules into the core and make them available in an easy way when required. In case you meet any issue concerning the installation of the add-ons, please do not hesitate to report to the list or file a ticket. Ciao [1] http://grass.osgeo.org/wiki/Toolboxes On Sat, Sep 8, 2012 at 11:10 PM, Enrico Gallo enrico.ga...@gmail.comwrote: Dear list, as user involved in hydrological analysis, I think r.stream.* modules are essential tools in GRASS GIS. Their availability filled in the empty space left by the Horton Machine / Fruid Turtles library (by prof. Rigon and his fantastic team) no more supported for GRASS GIS. Quality, scientific value and great performances of r.stream.* algorithms it’s out of the question, IMHO Looking in the user mailing list and searching on the web can confirm that many users really appreciate those modules even if some people have trouble with the AddOns installation process. So, could those modules be part of Grass core in the next releases? As part of GRASS GIS core, I think they could be fruitfully become available also in the QGIS GRASS toolbox. Regards, Enrico ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Margherita DI LEO Postdoctoral Researcher European Commission - DG JRC Forest Resources and Climate I-21020 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] could r.stream.* become part of GRASS core?
Dear list, as user involved in hydrological analysis, I think r.stream.* modules are essential tools in GRASS GIS. Their availability filled in the empty space left by the Horton Machine / Fruid Turtles library (by prof. Rigon and his fantastic team) no more supported for GRASS GIS. Quality, scientific value and great performances of r.stream.* algorithms it’s out of the question, IMHO Looking in the user mailing list and searching on the web can confirm that many users really appreciate those modules even if some people have trouble with the AddOns installation process. So, could those modules be part of Grass core in the next releases? As part of GRASS GIS core, I think they could be fruitfully become available also in the QGIS GRASS toolbox. Regards, Enrico ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
