Re: [GRASS-dev] Object-based image classification in GRASS

Salut GRASSers, Moritz Lennert wrote: [..] > With all the elements in place, especially with Pietro's recent work, it > should be quite easy to create a unifying module 'i.segment.classify' > which would take as input > > - the segments coming out of i.segment > - training zones > - a choice of

[GRASS-dev] Greetings to the sprinters

Hi Devs (GRASSers and Others as well)! I hope you enjoy and have great fun in Wien. I am so sad that I could not join (various reasons) and assist in whatsoever. Thanks for the beta release of G7. On the discussion of having (some kind of) access to GRASS via QGIS: it's so Important! My most

Re: [GRASS-dev] i.spectral limited to 400 files

Yann Chemin wrote: > >> is there a way to modify i.spectral to remove the limit of 400 files: Glynn: > > The limit is from r.what. It probably wouldn't be that hard to fix. Markus N: > ... "nice to have" for sure. > > BTW: > The next limit would be the operating system. Default Linux allows >

[GRASS-dev] grass7/0_trunk/release fail to start

A fresh, (make dist)clean(ed) and error-free configured & compiled grass7_trunk under Funtoo (3.12.18-KS.01) won't launch: # /osgeo/grass70_release/bin.x86_64-unknown-linux-gnu $ ./grass70 /usr/bin/python2.7: can't open file '/osgeo/src/grass7_trunk/dist.x86_64-unknown-linux-gnu/gui/wxpython/

Re: [GRASS-dev] grass7/0_trunk/release fail to start

Nikos Alexandris: A fresh, (make dist)clean(ed) and error-free configured & compiled grass7_trunk under Funtoo (3.12.18-KS.01) won't launch: # /osgeo/grass70_release/bin.x86_64-unknown-linux-gnu $ ./grass70 Markus Neteler: Do you use trunk or release branch? /usr/bin/python2

[GRASS-dev] Does m.cogo belong in the File menu?

Can't we move m.cogo to somewhere else, instead let it being under "File"? As per "m.proj is under ", m.cogo could fit somewhere between the Generate...> (points?) related tools? -- Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://li

Re: [GRASS-dev] grass7/0_trunk/release fail to start

On 08.05.2014 11:56, Nikos Alexandris wrote: .. # in grass70_release directory make distclean ./configure --with-freetype-includes="/usr/include/freetype2/" .. # compile make -j5 .. Errors in: No errors detected. .. # launch grass /osgeo/grass70_release/bin.x86_64-unknown

Re: [GRASS-dev] grass7/0_trunk/release fail to start

On 09.05.2014 00:31, Markus Neteler wrote: On Thu, May 8, 2014 at 11:26 PM, Nikos Alexandris wrote: ... Could it be due to a difference in wxPython installations? In the working machine I have version 2.9.4.1-r2 and in the faulty one 3.0.0.0? But this shouldn't be a problem, right?

Re: [GRASS-dev] grass7/0_trunk/release fail to start

On 08.05.2014 11:11, Nikos Alexandris wrote: A fresh, (make dist)clean(ed) and error-free configured & compiled grass7_trunk under Funtoo (3.12.18-KS.01) won't launch: # /osgeo/grass70_release/bin.x86_64-unknown-linux-gnu $ ./grass70 /usr/bin/python2.7: can't open fil

Re: [GRASS-dev] r.stats output

Paulo van Breugel: I am trying to use r.stats to print out a text file with x and y coordinates as well as the area (or cell count). However, it seems any choice is mutually exclusive. If I choose to print the grid coordinates and to print the area, what I get is the coordinates with the categ

Re: [GRASS-dev] selection of subgroup in i.* modules

Moritz Lennert wrote: Before posting a bug report I just wanted to make sure, as I have a vague memory that this has been discussed before: Is it normal that I do not get a dropdown list of subgroups in i.* modules (i.gensig, i.maxlik, i.gensigset, ...) after having selected a group ? In g.g

[GRASS-dev] g.parser: Note on setting bash' IFS to parse separate identities

In , "Notes": --%<--- ...individual comma separated identities for an option named "input" can be parsed with the following Bash shell code: IFS=, for opt in $GIS_OPT_INPUT ; do ... "$opt" done --->%-- Doesn't this require to set the I

Re: [GRASS-dev] g.parser: Note on setting bash' IFS to parse separate identities

Nikos Alexandris wrote: --%<--- ...individual comma separated identities for an option named "input" can be parsed with the following Bash shell code: IFS=, for opt in $GIS_OPT_INPUT ; do ... "$opt" done --->%-- Doesn't this require to set the IFS back

Re: [GRASS-dev] [GRASS-user] Confused when using i.fusion.brovey

Michael, you can check out the python script (for GRASS 7) implementing HPFA at . While it's fairly easy to use it, there are various options to tweak results. We can start thinking for integration, given the scrip

[GRASS-dev] wxpython/iclass fails to compile, missing numpy.oldnumeric

For both G70 and trunk, /osgeo/grass7_trunk/gui/wxpython/iclass fails to compile: ImportError: NumPy not found. This module requires the NumPy module, which could not be imported. It probably is not installed (it's not part of the standard Python distribution). See the Nume

Re: [GRASS-dev] wxpython/iclass fails to compile, missing numpy.oldnumeric

Nikos Alexandris For both G70 and trunk, /osgeo/grass7_trunk/gui/wxpython/iclass fails to compile: --%<--- ImportError: NumPy not found. This module requires the NumPy module, which could not be imported. It probably is not installed (it's not part of the

[GRASS-dev] Makefile related problem? Re: [GRASS-user] Confused when using i.fusion.brovey

I have this script . My local Makefile, with which I am trying to compile currently, is: MODULE_TOPDIR = ../.. PGM = i.fusion.hpf ETCFILES = high_pass_filter constants include $(MODULE_TOPDIR)/include/Make/Script.make include $(MO

Re: [GRASS-dev] Makefile related problem? Re: [GRASS-user] Confused when using i.fusion.brovey

Nikos Alexandris wrote: I have this script <https://github.com/NikosAlexandris/i.fusion.hpf.py>. My local Makefile, with which I am trying to compile currently, is: MODULE_TOPDIR = ../.. PGM = i.fusion.hpf ETCFILES = high_pass_filter constants include $(MODULE_TOPDIR)/includ

Re: [GRASS-dev] wxpython/iclass fails to compile, missing numpy.oldnumeric

On 10.11.2014 00:26, Pietro wrote: Hi Nikos, On Sun, Nov 9, 2014 at 8:23 PM, Nikos Alexandris wrote: Yes, the above. Ehh.. maybe not related to G7 directrly? Complete msg: I don't think is related to GRASS, please have a look at previous thread on the topic: http://lists.osge

Re: [GRASS-dev] wxpython/iclass fails to compile, missing numpy.oldnumeric

On 10.11.2014 09:05, Glynn Clements wrote: Markus Neteler wrote: What is the relationship of numpy's oldnumeric and GRASS 7? It's an issue with the wx.lib.plot module in wxPython. It wants a "numeric" module, for which it tries: try: import numpy.oldnumeric as _Numeric except: try:

Re: [GRASS-dev] Makefile related problem? Re: [GRASS-user] Confused when using i.fusion.brovey

Nikos Alexandris wrote: > > I have this script > > <https://github.com/NikosAlexandris/i.fusion.hpf.py>. My local > > Makefile, with which I am trying to compile currently, is: > > MODULE_TOPDIR = ../.. > > > > PGM = i.fusion.hpf >

Re: [GRASS-dev] Makefile related problem? Re: [GRASS-user] Confused when using i.fusion.brovey

Nikos: .. > Thanks to "r.in.wms", fixed by using this line: > > +sys.path.insert(1, os.path.join(os.path.dirname(sys.path[0]), 'etc', > 'r.in.wms')) This approach broke for my script i.fusion.hpf again. The sys.path[0] is an empty string (now). I have no idea why it did work before. It w

[GRASS-dev] G_OPT_R_MAP vs G_OPT_R_INPUT

What is the difference between G_OPT_R_MAP and G_OPT_R_INPUT? Which and why should I prefer for my script(s)? Is there a step-by-step run-through of all options for composing header definitions? -- Nikos ___ grass-dev mailing list grass-dev@lists.os

Re: [GRASS-dev] G_OPT_R_MAP vs G_OPT_R_INPUT

Nikos Alexandris wrote: What is the difference between G_OPT_R_MAP and G_OPT_R_INPUT? Which and why should I prefer for my script(s)? Is there a step-by-step run-through of all options for composing header definitions? Helmut Kudrnovsky wrote: see http://grass.osgeo.org/programming7

Re: [GRASS-dev] G_OPT_R_MAP vs G_OPT_R_INPUT

Nikos Alexandris wrote: What is the difference between G_OPT_R_MAP and G_OPT_R_INPUT? Which and why should I prefer for my script(s)? Is there a step-by-step run-through of all options for composing header definitions? Helmut Kudrnovsky wrote: see http://grass.osgeo.org/programming7

Re: [GRASS-dev] G_OPT_R_MAP vs G_OPT_R_INPUT

On 14.11.2014 16:22, Moritz Lennert wrote: On 14/11/14 14:58, Nikos Alexandris wrote: Nikos Alexandris wrote: What is the difference between G_OPT_R_MAP and G_OPT_R_INPUT? Which and why should I prefer for my script(s)? Is there a step-by-step run-through of all options for composing header

[GRASS-dev] Adding a suffix for output raster map names

Using the following in a python script's header #%option #% key: outputsuffix #% key_desc: suffix string #% type: string #% description: Suffix for the Pan-Sharpened image(s) #% required: yes #% answer: hpf #%end and somewhere in the script the following run("g.rename", rast=(tmp_msx_hpf,"%s.%s

Re: [GRASS-dev] Adding a suffix for output raster map names

Nikos Alexandris wrote: Using the following in a python script's header: #%option #% key: outputsuffix #% key_desc: suffix string #% type: string #% description: Suffix for the Pan-Sharpened image(s) #% required: yes #% answer: hpf #%end and somewhere in the script the following

Re: [GRASS-dev] Adding a suffix for output raster map names

Nikos Alexandris wrote: Is there a pygrass function to isolate the a raster map's basename from the Mapset part? Looking for it... Helmut Kudrnovsky wrote: this should work: def main(): vectorforcalculations = options['vector'].split('@')[0] Danke Helmu

[GRASS-dev] g.parser and "#% type: double"

Given the following --%<--- #%option #% key: sea #% key_desc: degrees #% type: double #% description: Aquisition's Sun Elevation Angle #% options: 0.0 - 90.0 #% guisection: Metadata #% required: yes #%end .. import grass.script as grass .. def main() .. sea = options['sea'] .. if __n

Re: [GRASS-dev] g.parser and "#% type: double"

Nikos Alexandris Given the following.. #%option #% key: sea .. #% type: double .. Markus Neteler wrote: ... this defines what type is *accepted* as input. #% description: Aquisition's Sun Elevation Angle #% options: 0.0 - 90.0 #% guisection: Metadata #% required: yes #%end .. i

[GRASS-dev] g.message and unicode in python

How can I print an informational message, using g.message, that contains unicode stuff via python (2.x)? For example, how do I correctly translate this command g.message message="ρ(p) = π x L(λ) x d^2 / ESUN(λ) x cos(θ(S))" (it contains the greek r (ρ, pronounced rho) and pi (π, pronounced pe)

[GRASS-dev] Possible to use "conditionals" for script options, flags?

Scripting in Python and defining options and flags in the header, as usual using the '#%' markers in the beginning of the line and following g.parser's manual. What if there is need to override an option if another one is given? For example, an option considered as required may be the "mean ta

Re: [GRASS-dev] Possible to use "conditionals" for script options, flags?

Anna Petrášová wrote: Hi Nikos, there is a new parser functionality which allows to specify the dependencies.There is no documentation, here are the C functions: http://grass.osgeo.org/programming7/parser__dependencies_8c.html recently Glynn added this for python scripts to, i am not sure abou

Re: [GRASS-dev] g.message and unicode in python

On 21.11.2014 20:17, Glynn Clements wrote: Nikos Alexandris wrote: How can I print an informational message, using g.message, that contains unicode stuff via python (2.x)? For example, how do I correctly translate this command g.message message="ρ(p) = π x L(λ) x d^2 / ESUN(λ) x co

[GRASS-dev] i.atcorr: geometric conditions for MSS missing

Missing index for Landsat's Multi-Spectral Scanner (mss) geometric condition? Refs:

[GRASS-dev] Change i.atcorr's description of sunaz

I think the following change in i.atcorr('s descriptive message of the sunaz string,) is required: grass70/imagery/i.landsat.toar $ svn diff Index: main.c === --- main.c (revision 62829) +++ main.c (working copy) @@ -209,7

Re: [GRASS-dev] i.atcorr: geometric conditions for MSS missing

Nikos Alexandris: Missing index for Landsat's Multi-Spectral Scanner (mss) geometric condition? Markus Neteler wrote: Are the MSS geometric conditions really missing or the same as TM? I don't know it (yet). Maybe. We will need to update the documentation accordingly. Tha

Re: [GRASS-dev] Error in GRASS GIS 7.0 database

Erick Opiyo wrote: Hi List, I was running two commands, listed below, simultaneously in a Linux environment. 1. r.mapcalc was running as a python mulitprocess command the background and 2. r.what was running in the foreground to extract some pixel values for several rast images. I'm not su

Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

On 24.11.2014 20:42, GRASS GIS wrote: #2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: block

[GRASS-dev] On i.atcorr support for WorldView2, QB2

Is there anyone willing to check ticket #2059 out? [0] I am attaching an `R` session through which I obtained the numbers fed to `create_iwave.py` for the template creation. Is there, perhaps, important to keep the band-width order (instead of the band numbering in delivered products)? Maybe

[GRASS-dev] i.landsat.toar on MSS5 scene

I dowloaded the scene the Landsat5 MSS scene LM50160351987287AAA03. After importing in a utm_z17n based Location, the bands are listed as B1, B2, B3 and B4. Running i.landsat.toar fails: i.landsat.toar -r input_prefix=B output_prefix=Rad. metfile=LM50160351987287AAA03_MTL.txt Writing radia

Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

* Martin Landa [2014-11-25 00:34:59 +0100]: > Ciao Niko, > > 2014-11-24 20:09 GMT+01:00 Nikos Alexandris : > > can I ask for the script, or the way, you extracted the flags and options > > per module? > > sure, > http://svn.osgeo.org/grass/sandbox/martinl/

Re: [GRASS-dev] GRASS 7 - Ubuntu package build problem on Launchpad

On 13.12.2014 13:39, Markus Neteler wrote: Hi Nikos, since you are also listed, could you please press the button? thanks Markus Done. Well, at least I think I did it correctly! Nikos .. ___ grass-dev mailing list grass-dev@lists.osgeo.org http:/

Re: [GRASS-dev] GRASS 7 - Ubuntu package build problem on Launchpad

On 15.12.2014 01:13, Ivan Mincik wrote: .. Thanks Nikos, now packages are finally built. Nice. If you think my registration here might be an obstacle in getting things done, please, feel free to remove my name (or I'll dot it, if necessary) from the group. :-) Nikos __

Re: [GRASS-dev] Custom GRASS command line prompt

On 15.12.2014 12:33, Michel Wortmann wrote: Hi Nikos, Hamish and list, you guys played around with your commandline prompts last year (see below), I was just implementing the same thing into my ~/.grass.bashrc (GRASS 7.0.0b3) but found that the location and mapset arent actually changed when c

[GRASS-dev] Option snap for v.in.ogr via g.gui (GRASS 7)

Hi devs, we are missing the "snap" option (v.in.ogr) in GRASS 7 (wxGUI). Actually, we miss the "Command dialog" button. Is this a bug? Thanks, Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-

Re: [GRASS-dev] Option snap for v.in.ogr via g.gui (GRASS 7)

On 15.12.2014 20:09, Nikos Alexandris wrote: Hi devs, we are missing the "snap" option (v.in.ogr) in GRASS 7 (wxGUI). Actually, we miss the "Command dialog" button. Is this a bug? Sorry, forgot to note: this is under a Windo

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 m

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 : 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

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 : 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 ru

[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.osg

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 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

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)

[GRASS-dev] On integrating i.fusion.hpf into i.pansharpen

Dear all, I want to integrate the "AHPF" fusion algorithm, [0], into [1]. And I need some assistance. 1. has the following, simple, interface: i.pansharpen [-sl] red=name green=name blue=name pan=name output=basename method=value [--overwrite] [--help] [--verbose] [--quiet] [--ui]

Re: [GRASS-dev] On integrating i.fusion.hpf into i.pansharpen

On 20.12.2014 20:43, Yann Chemin wrote: Would it make sense to let it be separate? For me that is the easiest. But it would be nice to gather algorithms of a kin to one place, make grass more attractive, compact and integrated. Thank you Yann. Please, other voices? Thank you all, Nikos

Re: [GRASS-dev] On integrating i.fusion.hpf into i.pansharpen

Helmut Kudrnovsky wrote: .. guisections for each algorithm? "A "guisection" field may be added to each option and flag to specify that the options should appear in multiple tabs in the auto-generated GUI."[1] [1] http://grass.osgeo.org/grass70/manuals/g.parser.html This will help for the GU

Re: [GRASS-dev] module header definitions add: text/multiline and latex support?

Pietro, this thread is of interest, I guess, as well. +1 for LaTeX. That would be awesome. Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/m

Re: [GRASS-dev] module header definitions add: text/multiline and latex support?

On 14/01/15 09:42, Pietro wrote: Dear devs, sometimes I would like to add some multiline text on the module GUI to help to understand the meaning of the parameter, and/or understand the logic of the module. Do you think that would be possible to have a description option that it does not tak

Re: [GRASS-dev] module header definitions add: text/multiline and latex support?

On 14.01.2015 16:13, Huidae Cho wrote: [..] Requiring raster OR vector is possible already. #%rules #% requires: raster, vector #%end Can't the above be reflected, when used, in the GUI in a way such as Pietro thinks? Nikos ___ grass-dev mailing

Re: [GRASS-dev] module header definitions add: text/multiline and latex support?

Moritz: I personally am not in favour of such additional text in the module. I think it would clutter the interface. There is a reason there are man pages and we should not encourage users to skip them... Pietro: Why? I don't see the reason why we should educate the users... I provide a to

Re: [GRASS-dev] module header definitions add: text/multiline and latex support?

On 14.01.2015 19:13, Paulo van Breugel wrote: These text elements could help to unclutter the interface if used properly. Like the example provided by Pietro, they could for example help to group the inputs from which the user need to select one (grouping of options using tabs is another opti

Re: [GRASS-dev] module header definitions add: text/multiline and latex support?

Just a very quick mockup, all-in-one page: . Note, the "Help" button and the "Manual" are duplicates, if I am not wrong. This adds up in overloading the interface. Nikos ___ grass-dev mailing list gr

Re: [GRASS-dev] module header definitions add: text/multiline and latex support?

On 15/01/15 13:34, Nikos Alexandris wrote: Just a very quick mockup, all-in-one page: <http://imgbin.org/index.php?page=image&id=21809>. Note, the "Help" button and the "Manual" are duplicates, if I am not wrong. This adds up in overloading the interface.

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

On 20.01.2015 11:38, Martin Landa wrote: Hi, 2015-01-20 6:18 GMT+01:00 Helena Mitasova : I like this one - I think it well represents what GRASS is. (perhaps GRASS GIS?) GRASS. Bringing advanced geospatial technologies to the world. +1 Much more better than the current: The world's lead

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

On 21.01.2015 12:37, Vincent Bain wrote: Just for fun, I made a couple of tests there: http://www.lesfavrets.fr/telec/grass_splash.tar.gz Awesome work, as usual! Splash #1 is "ageless". Splash #3 is modern. +100 Nikos ___ grass-dev mailing list gr

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

.. We should start GRASS right away in latlong like most GIS in the world. Then let the user open the dialog to change projection if desired from inside. This would avoid a lot of questions right away. Please don't do this ! I find the fact that GRASS does not provide a default projection s

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

[..] Apologies for erasing the above text. Moritz Lennert wrote: Please don't do this ! I find the fact that GRASS does not provide a default projection system, but forces the user to think about projection from the start, one of its strengths, both for work and for teaching. Helena Mita

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

On 21.01.2015 21:31, Michael Barton wrote: The splash and start up screens are very nice. I still like a map background for a splash and am into historical stuff. But the simple and classy look is good. If there is going to be "historical" map, why not select something "historical" that was

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

If I am not wrong, no-one mentioned the QGIS interface to GRASS (when creating a new Location & Mapset(s)). It's not bad at all. In fact, it's good. Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/g

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

Dear Michael, while the maps linked below are very nice, why and how do they showcase GRASS' capabilities? Or is it about, only, to represent in which areas GRASS can do stuff? Why not have a splash that is GRASS' very unique identity? What it is, what it can do. Nikos On 22.01.2015 0

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

On 22.01.2015 09:51, Yann Chemin wrote: http://docs.qgis.org/2.2/ko/docs/training_manual/grass/grass_setup.html http://docs.qgis.org/2.2/ko/_images/grass_folder.png Spanish text https://ecoslackware.wordpress.com/tag/grass-qgis-plugin/ Italian text http://qgis4dummies.wikidot.com/grass-plugin

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

On 22.01.2015 10:32, Helmut Kudrnovsky wrote: > > I find the fact that GRASS does not provide a default > > projection system, but forces the user to think about projection from the > > start, one of its strengths, both for work and for teaching. >> On of it strenghts, yes. But I have bee

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

Markus Metz wrote: A suggestion for a compromise: Have a minimal welcome screen that says something like "Starting GRASS GIS in location X, mapset Y" nothing else, no list of all the available locations and mapsets Only two buttons: OK, Change Make OK the default, Change will bring up the curr

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

On 22.01.2015 10:41, Rainer M Krug wrote: Nikos Alexandris writes: On 22.01.2015 09:51, Yann Chemin wrote: http://docs.qgis.org/2.2/ko/docs/training_manual/grass/grass_setup.html http://docs.qgis.org/2.2/ko/_images/grass_folder.png Spanish text https://ecoslackware.wordpress.com/tag/grass

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

On 23.01.2015 15:18, Vincent Bain wrote: Thanks for theses feedbacks, Le vendredi 23 janvier 2015 à 14:41 +0100, Markus Neteler a écrit : Do you see a chance to morph the true grass into a map (from left to right or so)? IMHO we need to somehow communicate that spatial data are involved. ce

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

Yann Chemin wrote: > hmm that would be cool ! > running r(v).in.* without GISDBASE or Location or mapset could trigger a > wizard to set them up... Markus Metz: This is the current location wizard. The original topic was import and on-the-fly reprojection without the need to create a ne

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

On 28.01.2015 16:36, Vincent Bain wrote: Hi, I packed most of the graphical tests I did last week on a wiki page. I tried to initiate a place (very rough yet) where we can further set up things concerning graphical identity. Hope this helps. http://grasswiki.osgeo.org/wiki/Identity The one

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

Vaclav Petras wrote: To satisfy everybody, I suggest to provide a buttons with something like "Take me to LL", "Take me to default location" and "Take me to XY". What do you think about that? But the real improvement should be the messages which would g

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

On 29.01.2015 15:58, Vincent Bain wrote: Le mercredi 28 janvier 2015 à 17:42 +0200, Nikos Alexandris a écrit : The ones @ <http://grasswiki.osgeo.org/wiki/User:NikosA#Ideas_for_an_alternative_GRASS-Wiki_logogram> are for the Wiki... !? If anyone is interested. Sorry Nikos, I misse

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

On 29.01.2015 18:49, Moritz Lennert wrote: ### Mapset "A Mapset contains GIS data. Every Location automatically has one Mapset named PERMANENT that also contains projection information for the Location." Maybe add a little about use of mapsets: "A Mapset is a subdirectory of a location and

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

Maybe a crazy idea, but... if access to internet isn't an option, maybe the "button" can create a Location and Mapset(s), and let a script create some artificial vector and raster maps? So a user can still play along with unreal data. Nikos ___ gra

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

On 30.01.2015 14:35, Yann Chemin wrote: Continuing the crazy thoughts, You could have FFT/wavelet parameters per column of a raster image hard-coded to create an image on request (that I could do I think). About a vector, well a set of polygon arcs pairs can easily be stored in code and (i su

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

On 30.01.2015 14:24, Yann Chemin wrote: still +1 for http://grasswiki.osgeo.org/wiki/File:GRASSGIS_splash5.jpg me too, +1 (for lower case letters as well). This splash is "so very" well crafted. Nikos ___ grass-dev mailing list grass-dev@lists.os

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

Vincent, is this beautiful 3D-scene available for others to experiment with? Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

Yann Chemin: Continuing the crazy thoughts, You could have FFT/wavelet parameters per column of a raster image hard-coded to create an image on request (that I could do I think). Markus Neteler wrote: ... r.surf.fractal does this... but: About a vector, well a set of polygon arcs pairs ca

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

On 03.02.2015 09:53, Blumentrath, Stefan wrote: [..] 1) I was just wondering, every module has a manual, the startup-screen does not. What about having a e.g. the “Location and Mapsets” wiki page as a manual behind e.g. a (not too flashy) question-mark-button on the on the welome screen.

Re: [GRASS-dev] [GRASS-SVN] r64407 - grass/trunk/gui/wxpython

On 06.02.2015 15:07, Martin Landa wrote: Hi, 2015-02-03 3:08 GMT+01:00 : Author: wenzeslaus Date: 2015-02-02 18:08:29 -0800 (Mon, 02 Feb 2015) New Revision: 64407 Modified: grass/trunk/gui/wxpython/gis_set.py Log: wxGUI/startup: make warnings, hints and infos show the same; number boxes

[GRASS-dev] Using UbuntuGIS packages in debian?

Hi devs. Is it possible to use the UbuntuGIS repositories in debian (i.e. under wheezy)? Thank you, Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Using UbuntuGIS packages in debian?

Thanks for the confirmation Ivan. Nikos On 11.02.2015 09:11, Ivan Minčík wrote: No, it is not possible. Ivan Mincik. This message has been sent from my cell phone. Sorry for being too short. On Feb 9, 2015 12:29 PM, "Nikos Alexandris" wrote: Hi devs. Is it possible

Re: [GRASS-dev] r.modis in GRASS 7 trunk

On Tuesday 30 of October 2012 11:31:49 Yann Chemin wrote: > Hi list, > > as a regular user of MODIS, I would like to call other MODIS users to > express interest to include r.modis into GRASS 7 SVN. Herewith I express my HUGE interest in the integration of r.modis into GRASS 7 SVN. Thank you f

Re: [GRASS-dev] [GRASS-user] Is "i.cluster" an implementation of the ISODATA algorithm?

Angelos Tzotsos : > This is an ISODATA implementation in C, written under GPL by Christos > Iossifidis, a colleague of mine at NTUA. > Would anyone be interested porting it to GRASS? > http://users.ntua.gr/chiossif/Free_As_Freedom_Software/isodata.c Curious: how much effort would this be for an

Re: [GRASS-dev] IPython Notebook & GRASS

Massimo Di Stefano: > in the last month i'm working a lot using IPython Notebook and some GFOSS > tools (mostly GRASS) and example of what a notebook can do is showed here : > http://nbviewer.ipython.org/url/epi.whoi.edu/esr/GIS_GRASS-R_Example.ipynb .. > thanks for any comment. Cool!! _

[GRASS-dev] "Parameter , require: string" in v.db.dropcolumn

Hi all! Using "v.db.dropcolumn" within from latest "grass_trunk", I wonder why the "layer" parameter in "v.db.dropcolumn" is required to be a string as stated in an error message while trying to run a py-grass script: --%<--- File "/geo/osgeo/src/grass_trunk/dist.x86_64-unknown-linux- gnu/etc/

Re: [GRASS-dev] [GRASS-user] i.landsat.toar unable to read metadata file

Nikos: > > It seems there are several modifications to the MET content structure. > > Fortunately (?) two MET files are provided *currently* (at least I have > > seen this in several L[MTE][457] scenes. .. I tried to compare variable definitions in the landsat_met.c file with the diff "TLold.tx

Re: [GRASS-dev] [GRASS-user] i.landsat.toar unable to read metadata file

(re-structured the last post, cc-ed András B, E. Jorge T -- someone is not on the list?) Nikos: > >> > It seems there are several modifications to the MET content structure. > >> > Fortunately (?) two MET files are provided *currently* (at least I have > >> > seen this in several L[MTE][457] sce

Re: [GRASS-dev] [GRASS-user] i.landsat.toar unable to read metadata file

.. Markus: The original changes I got from Jorge I attach again. Should they be submitted to SVN? Jorge did some more changes, I tested and verified that it works with both L5's and L7's along with a new(er) MLT.txt metadata file. Jorge, could you please resend it? Nikos ps- due to an

Re: [GRASS-dev] GRASS GIS nightly builds

On Friday 28 of December 2012 03:54:17 Rashad M wrote: > All, > > Is there any nightly build of grass70 for ubuntu/debian? Anyone maintaining > PPA packages? I think we need to activate ourselves here too. I regularly re-compile stuff (from the scratch) on my (Kubuntu-)box. So, I keep thinking

Re: [GRASS-dev] GRASS GIS nightly builds

On Friday 28 of December 2012 04:40:51 Rashad M wrote: > I can take up the job if nobody is doing it, :) What about doin' it together? Nikos ps- Yes, I think currently there is manpower required in this corner. .. signature.asc Description: This is a digitally signed message part.

[GRASS-dev] To --enable-64bit or not to?

GD Day Devs! Configuring with --enable-64bit results in (working on Kubutnu 12.10, 64 bit currently): --%<--- GRASS is now configured for: x86_64-unknown-linux-gnu ... 64bit support: yes --->%-- while leaving this option out results in --%<--- GRASS is now configured for: x86

  1   2   3   4   5   6   7   8   >