Re: [GRASS-dev] Custom GRASS command line prompt
Huidae Cho wrote:
Mine looks like this (bash shell):
grass_ps(){
echo G `g.gisenv LOCATION_NAME`/`g.gisenv MAPSET`
}
export PS1=\[\033]0;\$(grass_ps) \w\007\]\$(grass_ps) \w
The prompt gets updated dynamically since grass_ps() is called every
time
you hit enter.
Oh, this makes life easier :-)
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Custom GRASS command line prompt
On 16.12.2014 00:14, Martin Landa wrote: Hi, 2014-12-15 11:33 GMT+01:00 Michel Wortmann wortm...@pik-potsdam.de: I was just implementing the same thing into my ~/.grass.bashrc (GRASS btw, preferable is .grass7/bashrc rather than .grass.bashrc. Martin But then, I guess, we need to duplicate this for making it work with G64x, right? Thanks, Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Option snap for v.in.ogr via g.gui (GRASS 7)
On 16.12.2014 10:15, Moritz Lennert wrote: On 15/12/14 19:22, Martin Landa wrote: Hi, 2014-12-15 19:13 GMT+01:00 Nikos Alexandris n...@nikosalexandris.net: we are missing the snap option (v.in.ogr) in GRASS 7 (wxGUI). Actually, we miss the Command dialog button. Is this a bug? try to run v.in.ogr with --ui flag. Martin I still would prefer to have the Command dialog button back in this GUI. It just makes life easier... Absolutely +1. For someone who doesn't use CLI, I don't think he'll come up with the idea to use --ui. He probably will only star the display wondering for the missing snap option. Me and Fotis (cc-ed) were looking for it for a while. Then dropped back to the cli to get the job done. Thanks, Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by mlennert): +1 for raster_3d. Moritz -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:127 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] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by lucadelu): Replying to [comment:127 mlennert]: +1 for raster_3d. +1 also for me Moritz -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:128 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] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by martinl): Replying to [comment:127 mlennert]: +1 for raster_3d. +1 I think that it would be useful to modify parser to understand also `rast` (`rast3d is OK because '_' is treated as word separator). -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:129 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] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by martinl): Replying to [comment:129 martinl]: I think that it would be useful to modify parser to understand also `rast` (`rast3d is OK because '_' is treated as word separator). attachment:raster_3d.diff -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:130 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] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by hcho): Replying to [comment:130 martinl]: Replying to [comment:129 martinl]: I think that it would be useful to modify parser to understand also `rast` (`rast3d is OK because '_' is treated as word separator). attachment:raster_3d.diff I'm generally against adding special cases in the code. IMHO, if the user types `rast`, s/he means `raster` not `raster_3d` and it shouldn't be ambiguous. Currently, the parser would stop with a parameter ambiguous error. I think it would be more useful to modify the parser such that it takes the shortest unambiguous parameter with no further underscores. For example, * modules with parameters `raster_map=` and `raster_3d=`: `rast` and `raster_` would be ambiguous. * modules with parameters `raster=` and `raster_3d=`: `r` and `rast` would match with `raster=` and `r3` and `rast3` with `raster_3d=` * modules with parameters `raster_map=` and `raster_map_2=`: `rast` ambiguous, `rmap` for `raster_map=` and `rmap2` for `raster_map_2=` * modules with parameters `raster_map=` and `raster_map2=`: `rast` ambiguous, `rmap` for `raster_map=` and `rmap2` for `raster_map2=` I'm not sure if I was clear enough here. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:131 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] i.pansharpen fails to compile
After the latest change in i.pansharpen, the opening triple double quote is missing and the comments (MODULE's description, AUTHOR, etc) are not a docstring as expected. Please update. Thanks, Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by cmbarton): Replying to [comment:127 mlennert]: +1 for raster_3d. Moritz +1 for me Michael -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:132 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] i.pansharpen fails to compile
On Wed, Dec 17, 2014 at 4:33 PM, Nikos Alexandris n...@nikosalexandris.net wrote: After the latest change in i.pansharpen, the opening triple double quote is missing and the comments (MODULE's description, AUTHOR, etc) are not a docstring as expected. Please update. Not sure what you mean? this is how it looks like: http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_7_0/scripts/i.pansharpen/i.pansharpen.py Perhaps you have local changes and a svn update conflict? Find out with: svn status Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] i.pansharpen fails to compile
On 17.12.2014 18:21, Markus Neteler wrote: On Wed, Dec 17, 2014 at 4:33 PM, Nikos Alexandris n...@nikosalexandris.net wrote: After the latest change in i.pansharpen, the opening triple double quote is missing and the comments (MODULE's description, AUTHOR, etc) are not a docstring as expected. Please update. Not sure what you mean? this is how it looks like: http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_7_0/scripts/i.pansharpen/i.pansharpen.py Perhaps you have local changes and a svn update conflict? Find out with: svn status Probably! But, I did select for tc -- theirs conflict while updating. Anyway. Thanks (again). Should(n't) we go for ... in python scripts instead of # whereever possible? Some newer python scripts, I remember, have the AUTHOR and stuff info inside a docstring. Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] i.pansharpen fails to compile
On Wed, Dec 17, 2014 at 5:27 PM, Nikos Alexandris n...@nikosalexandris.net wrote: Probably! But, I did select for tc -- theirs conflict while updating. This means that you keep your changes (somehow). Anyway. Thanks (again). Should(n't) we go for ... in python scripts instead of # whereever possible? No idea - so far not discussed AFAIK. But I see it here: https://trac.osgeo.org/grass/wiki/Submitting/Python Some newer python scripts, I remember, have the AUTHOR and stuff info inside a docstring. Then we should update all scripts accordingly if that's the way to go. The included scripts should ideally reflect best practice. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] i.pansharpen fails to compile
Thanks Markus. Nikos Alexandris: Probably! But, I did select for tc -- theirs conflict while updating. Markus Neteler wrote: This means that you keep your changes (somehow). Reading in http://svnbook.red-bean.com/en/1.7/svn-book.html: --%--- (tc) theirs-conflict Discard any local changes which conflict with incoming changes from the server for the file under review. However, preserve all non-conflicting local changes to that file. ---%-- and - http://stackoverflow.com/questions/4015864/tortoise-svn-resolve-conflict-using-theirs-what-does-it-mean - http://tortoisesvn.net/docs/release/TortoiseMerge_en/tmerge-basics-conflicts.html I think its a bit confusing, happened to me in the past again. Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r63549 - grass-addons/grass7/raster/r.basin
On Mon, Dec 15, 2014 at 3:40 AM, svn_gr...@osgeo.org wrote:
grass.read_command('g.region', flags = 'p', region = 'original')
+grass.run_command('g.remove', flags = 'f', type = 'region', name =
'original')
I think it would be better to use use_temp_region() and del_temp_region()
functions from grass.script. grep source code for usage; please extend
their doc if you have something.
Vaclav
http://grass.osgeo.org/grass71/manuals/libpython/script.html#script.core.use_temp_region
http://grass.osgeo.org/grass71/manuals/libpython/script.html#script.core.del_temp_region
http://trac.osgeo.org/grass/changeset/63549
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Invitation to submit an abstract to EGU 2015 session on FOSS for GeoInformatics and Geosciences
Hi all, Anybody interested to submit some new development, please submit an abstract there: http://www.egu2015.eu/abstract_management/how_to_submit_an_abstract.html The Session is: -- ESSI2.13/SSS1.8 Free and Open Source Software (FOSS) for Geoinformatics and Geosciences (co-organized) Hope we can meet around some excellent fresh beer... Cheers, Yann -- ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
