Re: [GRASS-dev] [GRASS GIS] #2238: minor change in r.stream.segment syntax
#2238: minor change in r.stream.segment syntax
--+-
Reporter: madi | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: minor | Milestone: 7.0.0
Component: Raster| Version: svn-trunk
Keywords: r.stream.segment |Platform: Unspecified
Cpu: Unspecified |
--+-
Comment(by madi):
Replying to [comment:1 neteler]:
Done in r59509 (trunk) and r59510 (releasebranch_7_0).
Thanks
BTW: the param description wording is a bit odd.
{{{
in_stm_opt = G_define_standard_option(G_OPT_R_INPUT);
in_stm_opt-key = stream_rast;
in_stm_opt-description = _(Name of input streams mask raster
map);
in_dir_opt = G_define_standard_option(G_OPT_R_INPUT);
in_dir_opt-key = direction;
in_dir_opt-description = _(Name for input raster map with flow
direction);
}}}
and should perhaps be sync'ed to that of direction (in all modules).
Agreed. Something like: Name for input raster map with stream network
should do.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2238#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] #2238: minor change in r.stream.segment syntax
#2238: minor change in r.stream.segment syntax --+- Reporter: madi | Owner: grass-dev@… Type: enhancement | Status: closed Priority: minor| Milestone: 7.0.0 Component: Raster | Version: svn-trunk Resolution: fixed|Keywords: r.stream.segment Platform: Unspecified | Cpu: Unspecified --+- Changes (by neteler): * status: new = closed * resolution: = fixed Comment: Replying to [comment:3 madi]: Agreed. Something like: Name for input raster map with stream network should do. Done in r59519 and r59520. Closing. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2238#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-user] mapcalc gui load/save
Hi Anna, that is great, I was just about to request for a copy button for r.mapcalc similar to all other modules. Thanks, just what I needed. I'll try it out in near future. best regards, Johannes On Sun, Mar 30, 2014 at 12:04 AM, Anna Petrášová kratocha...@gmail.comwrote: Hi, I was wondering if anyone is using Load/Save expressions in r.mapcalc GUI. I just added there the copy button which is standard for all modules. When I need, I store multiple r.mapcalc commands in a text file and then I just copy and paste. Loading and saving expressions using the buttons seems inconvenient to me. Anyone has different opinion? Thanks, Anna ___ grass-user mailing list grass-u...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] changes in winGRASS daily builds
Hi all, in the next days I am going to do some changes in winGRASS packages (standalone [1] and OSGeo4W [2]). Dropped (daily snapshots): * `grass65-dev` will be dropped (devbr65) New (daily snaphosts): * `grass71-dev` will be introduced (trunk) * `grass70-dev` will be build from relb70 (not from trunk as until now) New package for 7.0.0betaX: * grass70 for betas (tag-based) Enjoy, Martin [1] http://wingrass.fsv.cvut.cz/ [2] http://trac.osgeo.org/osgeo4w/wiki/PackageListing#GRASSGIS -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1839: Install.make should honor $DESTDIR
#1839: Install.make should honor $DESTDIR --+- Reporter: vince | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.0 Component: Installation | Version: svn-trunk Keywords: DESTDIR |Platform: MacOSX Cpu: OSX/Intel | --+- Comment(by neteler): Issue was reported offlist also for Fedora. Patch here to be tested. Similar bug also in trac #764 -- Ticket URL: http://trac.osgeo.org/grass/ticket/1839#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
Re: [GRASS-dev] [GRASS GIS] #764: Can the install process accept a DESTDIR additional variable?
#764: Can the install process accept a DESTDIR additional variable? -+-- Reporter: vince| Owner: grass-dev@… Type: enhancement | Status: new Priority: minor| Milestone: 6.4.4 Component: Installation | Version: unspecified Keywords: install DESTDIR |Platform: All Cpu: All | -+-- Changes (by neteler): * milestone: 6.4.0 = 6.4.4 Comment: Potential patch in trac #1839 -- Ticket URL: http://trac.osgeo.org/grass/ticket/764#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
[GRASS-dev] Addons to Ohloh
Hi, do you think that GRASS GIS Addons [1] should go to Ohloh [2]? I do, because they are part of the project and should be tracked. GRASS GIS Addons can be added as additional repository for GRASS GIS project or they can be a separated project at Ohloh. Some projects went this way of having plugins/extension/addons separated. The reasons for this might be that the developers group, used languages or contribution frequency can be really different. What do you think? Or do you know some other ways on Ohloh? (I don't know much about Ohloh.) The question also is if grass-addons/ or grass-addons/grass7 or something else should be used. I vote for grass-addons, although there is some duplication. But there are some distinct things and it follows the idea of having there 64 and trunk. But I don't have a strong opinion on this either. Vaclav [1] http://svn.osgeo.org/grass/grass-addons/ [2] https://www.ohloh.net PS: I was considering for a second if to add also 70 branch besides trunk and the answer is clearly no. This would be definitively a huge duplication (and thus nonsense for Ohloh). ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
