[GRASS-dev] Fwd: Google Summer of Code 2014
FYI -- Forwarded message -- From: Carol Smith car...@google.com Date: Tue, Oct 8, 2013 at 9:02 PM Subject: Google Summer of Code 2014 To: Google Summer of Code Announce google-summer-of-code-annou...@googlegroups.com Hi all, We're pleased to announce that Google Summer of Code will be happening for its tenth year this year. Please check out the blog post [1] about the program and read the FAQs [2] and Timeline [3] on Melange for more information. We're doing a bunch of things to celebrate the 10th anniversary of the program. Check out our blog post to learn more! [1] - http://googleblog.blogspot.com/2013/10/50-million-lines-of-code-and-counting.html [2] - http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2014/help_page [3] - http://www.google-melange.com/gsoc/events/google/gsoc2014 Cheers, Carol -- You received this message because you are subscribed to the Google Groups Google Summer of Code Announce group. To unsubscribe from this group and stop receiving emails from it, send an email to google-summer-of-code-announce+unsubscr...@googlegroups.com. To post to this group, send email to google-summer-of-code-annou...@googlegroups.com. Visit this group at http://groups.google.com/group/google-summer-of-code-announce. For more options, visit https://groups.google.com/groups/opt_out. -- Best regards, Dr. Margherita DI LEO Scientific / technical project officer European Commission - DG JRC Institute for Environment and Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Problem installing r.modis on trunk
Hi, On Fedora 19 no problem: GRASS 7.0.svn (nc_basic_spm_grass7):~ g.extension r.modis Fetching r.modis from GRASS-Addons SVN (be patient)... Compiling... Installing... Updating metadata file... Installation of r.modis successfully finished Forgot to mention that I'm running Ubuntu 12.04.2. /usr/local/grass-7.0.svn/locale/scriptstrings/r.modis.download_to_translate.c: Directory nonexistent Does at least /usr/local/grass-7.0.svn/locale/ exist? It does not - the correct path would be /usr/local/src/grass7_trunk/locale/scriptstrings. I am opening a bug in the trac, Pierre -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2097: r.modis install using g.extension fails
#2097: r.modis install using g.extension fails
---+
Reporter: pierreroudier | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Addons | Version: svn-trunk
Keywords: MODIS |Platform: Linux
Cpu: x86-64 |
---+
I'm having problems trying to compile r.modis on the trunk version of
GRASS from the g.extension command. It does not seem to compile the
pymodis library if I'm getting that right.
I am running Ubuntu 12.04.2.
{{{
GRASS 7.0.svn (eda-rsr):~ g.extension ext=r.modis
Fetching r.modis from GRASS-Addons SVN (be patient)...
WARNING: gnome-keyring:: couldn't connect to:
/tmp/keyring-CTEtVP/pkcs11: No such file or directory
Compiling...
/bin/sh: 1: cannot create
/usr/local/grass-7.0.svn/locale/scriptstrings/r.modis.download_to_translate.c:
Directory nonexistent
sed: couldn't flush stdout: Broken pipe
make[1]:
[/usr/local/grass-7.0.svn/locale/scriptstrings/r.modis.download_to_translate.c]
Error 2 (ignored)
/bin/sh: 1: cannot create
/usr/local/grass-7.0.svn/locale/scriptstrings/r.modis.import_to_translate.c:
Directory nonexistent
sed: couldn't flush stdout: Broken pipe
make[1]:
[/usr/local/grass-7.0.svn/locale/scriptstrings/r.modis.import_to_translate.c]
Error 2 (ignored)
Installing...
Updating metadata file...
Installation of r.modis successfully finished
GRASS 7.0.svn (eda-rsr):~ r.modis.import
ERROR: modis library not found
}}}
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2097
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] Handling of Python scripts on MS Windows
Helmut Kudrnovsky wrote: C:\tmp\testpythonecho %PATHEXT% .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC Note that lib/init/grass.py sets PATHEXT. I was referring to cmd.exe *within* a GRASS session. Then, I would need to see the result of running a python script from the shell (that's cmd.exe in a console window, not bash, or anything running in MSys' rxvt, or the GUI's command line). test.py: print Hello, Python!; C:\tmp\testpython\test.py a error box pops up that test.py can't by executed because of no associated program can be found (see echo %PATHEXT%) This isn't related to PATHEXT. It suggests that the registry keys are inconsistent. There are two sets of registry keys used for file associations. The keys under HKEY_LOCAL_MACHINE\SOFTWARE\Classes contain the system-wide settings, while those under HKEY_USERS\*\Software\Classes contain the per-user settings. Additionally, HKEY_CURRENT_USER is an alias for HKEY_USERS\$user (where $user is the logged-in user) while HKEY_CLASSES_ROOT is obtained by merging the two sets of *\Classes keys (with the per-user settings taking precedence). ftype and assoc show the system-wide settings, but these are ignored if there are per-user keys. If the per-user keys exist but the values are invalid, executing a script will result in a dialog asking you to select the program to open that type of file. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G7: parameter standardization: n/count, min/minimum etc
Markus Neteler wrote: we have the confusing situation of naming the same statistic in different ways: r.series | r.statistics2 | t.rast.aggregate.* | t.vect.what.strds ... method Aggregate operation options: average,count,median,mode,minimum,min_raster,maximum, max_raster,stddev,range,sum,variance,diversity,slope, offset,detcoeff,tvalue,quart1,quart3,perc90,quantile, skewness,kurtosis r.in.lidar | r.in.xyz | r3.in.xyz | r.statistics method Statistic to use for raster values options: n,min,max,range,sum,mean,stddev,variance,coeff_var, median,percentile,skewness,trimmean default: mean I would suggest to streamline this (and personally opt for the r.series way of naming the methods; e.g., the n is easily overlooked, the count less so). Also the order might be revisited and standardized...? I suggest standardising on unabbreviated names. I'll look into using the option-matching code for option values as well as names. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2097: r.modis install using g.extension fails
#2097: r.modis install using g.extension fails ---+ Reporter: pierreroudier | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Addons | Version: svn-trunk Keywords: MODIS |Platform: Linux Cpu: x86-64 | ---+ Comment(by neteler): It works on Fedora 19. Any other distros where it fails than Ubuntu? Note from grass-dev: The issue is that the scriptstrings/2 subdir is missing in /usr/local/grass-7.0.svn/locale/scriptstrings/ -- Ticket URL: https://trac.osgeo.org/grass/ticket/2097#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] [GRASS GIS] #2097: r.modis install using g.extension fails
#2097: r.modis install using g.extension fails ---+ Reporter: pierreroudier | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Addons | Version: svn-trunk Keywords: MODIS |Platform: Linux Cpu: x86-64 | ---+ Comment(by madi): Replying to [comment:1 neteler]: It works on Fedora 19. Any other distros where it fails than Ubuntu? Fails on Red Hat See http://lists.osgeo.org/pipermail/grass-dev/2013-October/065957.html -- Ticket URL: https://trac.osgeo.org/grass/ticket/2097#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] #2097: r.modis install using g.extension fails
#2097: r.modis install using g.extension fails ---+ Reporter: pierreroudier | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Addons | Version: svn-trunk Keywords: MODIS |Platform: Linux Cpu: x86-64 | ---+ Comment(by neteler): Did you try to manually add the missing subdir? Would the installation work then? -- Ticket URL: https://trac.osgeo.org/grass/ticket/2097#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] G7: parameter standardization: n/count, min/minimum etc
We should also decide between `mean` and `average`. I vote for `mean`. Here are some resources: http://en.wikipedia.org/wiki/Mean http://en.wikipedia.org/wiki/Average http://stats.stackexchange.com/questions/14089/what-is-the-difference-between-mean-value-and-average On Wed, Oct 9, 2013 at 8:10 AM, Glynn Clements gl...@gclements.plus.comwrote: Markus Neteler wrote: we have the confusing situation of naming the same statistic in different ways: r.series | r.statistics2 | t.rast.aggregate.* | t.vect.what.strds ... method Aggregate operation options: average,count,median,mode,minimum,min_raster,maximum, max_raster,stddev,range,sum,variance,diversity,slope, offset,detcoeff,tvalue,quart1,quart3,perc90,quantile, skewness,kurtosis r.in.lidar | r.in.xyz | r3.in.xyz | r.statistics method Statistic to use for raster values options: n,min,max,range,sum,mean,stddev,variance,coeff_var, median,percentile,skewness,trimmean default: mean I would suggest to streamline this (and personally opt for the r.series way of naming the methods; e.g., the n is easily overlooked, the count less so). Also the order might be revisited and standardized...? I suggest standardising on unabbreviated names. I'll look into using the option-matching code for option values as well as names. -- Glynn Clements gl...@gclements.plus.com ___ 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] GRASS70 for Ubuntu in ppa
Hi, On Wed, Sep 4, 2013 at 3:41 PM, Rashad M rasha...@gmail.com wrote: gis_set.py was included in grass-gui package. I had seen this issue earlier with someone and still didnt fixed it yet. Sorry its a fault on my side if its not fixed by adding grass-gui package. If so I will find some tim this sunday to fix the problem Has this issue already been solved? Today, after some time I uninstalled and reinstalled grass70 (and grass-gui) from the ubuntugis-ppa to check if it working now. But still I can't launch the GUI with a slightly different error now. I seems that it is now pointing a least to GRASS70: Hit RETURN to continue Starting GRASS GIS... python: can't open file '/usr/lib/grass70/etc/gui/wxpython/gis_set.py': [Errno 2] No such file or directory Received EXIT message from GUI. I checked an I also couldn't find the folder gui under /usr/lib/grass70/etc/ /Johannes On Wed, Sep 4, 2013 at 3:25 PM, Johannes Radinger johannesradin...@gmail.com wrote: No problem...as I said I just rolled back to precise. So no worry about raring for the moment. On precise I am able to install grass70 from grass-devel ppa and grass643 from ubuntugis-unstable... However when I try to launch both from the console (freshly installed precise) via grass64 or grass70 I get an error: python: can't open file '/usr/lib/grass64/etc/wxpython/gis_set.py': [Errno 2] No such file or directory resp. python: can't open file '/usr/lib/grass70/etc/wxpython/gis_set.py': [Errno 2] No such file or directory Any idea about that? /Johannes On Wed, Sep 4, 2013 at 2:28 PM, Rashad M rasha...@gmail.com wrote: there was some problem on raring and I couldn't get time to work on it. Anyway I will add it to my calender again and let see if I can figure it out. The main problem is I dont have a raring currently I need to login to a remote system at my university and do it. I will try this weekend and let you know On Wed, Sep 4, 2013 at 2:25 PM, Johannes Radinger johannesradin...@gmail.com wrote: At the moment I also saw that the last build failed for raring... so for the moment I'll reinstall precise to test grass70 On Wed, Sep 4, 2013 at 2:18 PM, Rashad M rasha...@gmail.com wrote: Hi, the recipe was not building for raring but I enabled it and you can check back in a while On Wed, Sep 4, 2013 at 1:42 PM, Johannes Radinger johannesradin...@gmail.com wrote: that one is installed...thats why I am wondering. I am running Xubuntu (latest actually todays version). The repo is also listed (e.g. in Synaptic and I see the grass-add ons but not the grass70) Maybe because of my new Xubuntu version (Raring ringtail)? On Wed, Sep 4, 2013 at 1:29 PM, Rashad M rasha...@gmail.com wrote: sudo add-apt-repository ppa:grass/grass-devel * * you may need to install add-apt-repository using apt-get install On Wed, Sep 4, 2013 at 12:15 PM, Johannes Radinger johannesradin...@gmail.com wrote: Hi Rashad, I just need your little help: I added the grass-devel PPA to my repository and ran sudo apt-get update however there is no grass70 listed which I can install via apt-get install gra* There is a grass and grass-devel listed which seems to be related to the grass 6.4.2 (is in the official ubuntu repo?) On Wed, Sep 4, 2013 at 11:51 AM, Rashad M rasha...@gmail.comwrote: Yes you are right. grass64 is uploaded in UbuntuGIS-unstable PPA when there is new release including RC's. GRASS PPA has daily builds for grass64, grass70 and grass-addons. I am sorry its not updated in grass webpage. I will ask Markus Netler who has can update this page [1] [1] http://grass.osgeo.org/download/software/linux/ On Wed, Sep 4, 2013 at 11:48 AM, Johannes Radinger johannesradin...@gmail.com wrote: Thank you for the quick reply... so just to be sure: the grass70 is now located at GRASS GIS PPA. the actual stable grass64 (643) is still located in UbuntuGIS-unstable PPA or also maintained for GRASS GIS PPA? /Johannes On Wed, Sep 4, 2013 at 11:28 AM, Rashad M rasha...@gmail.comwrote: you can check grass PPA in ubuntu. I am not adding grass70 to ubuntugis-testing PPA because its getting deleted a lot of time. GRASS GIS PPA has daily builds for grass70 for raring and quantal. You can see details here - https://launchpad.net/~grass/+archive/grass-devel On Wed, Sep 4, 2013 at 11:15 AM, Johannes Radinger johannesradin...@gmail.com wrote: Hi all, Hi Rashad, I just checked the link that is provided here: http://grass.osgeo.org/download/software/linux/ which points to the ubuntugis-testing repository for downloading a precompiled GRASS70 package. However, this repo does not include GRASS70. Is there any way resp. any repo that contains already an actual version of GRASS70 for Ubuntu or do I have to compile it myself? Usually I compile it myself but now I just set up a very slim Xubuntu on a virtual machine for a collegue and wanted just to simply install
Re: [GRASS-dev] [GRASS GIS] #2097: r.modis install using g.extension fails
#2097: r.modis install using g.extension fails ---+ Reporter: pierreroudier | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Addons | Version: svn-trunk Keywords: MODIS |Platform: Linux Cpu: x86-64 | ---+ Comment(by madi): Replying to [comment:3 neteler]: Did you try to manually add the missing subdir? Would the installation work then? The installation is successfully finished then, BUT the command is not found, because it is apparently installed in the wrong directory. The /r.modis folder is placed under /grass-7.0.svn/ -- Ticket URL: https://trac.osgeo.org/grass/ticket/2097#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] Handling of Python scripts on MS Windows
I was referring to cmd.exe *within* a GRASS session. ok, 2 tests with another windows VISTA box because of travelling (win7-box from earlier test not available atm), now within a GRASS session: --- winGRASS-session (1) winGRASS 7 standalone installer and no python installation winGRASS 7 standalone installer bundled with Python 2.7.4 (default, Apr 6 2013, 19:54:46) [MSC v.1500 32 bit (Intel)] on win32 System Info GRASS version: 7.0.svn GRASS SVN Revision: 57955 Build Date: 2013-10-08 GIS Library Revision: 56211 (2013-05-12) GDAL/OGR: 1.9.2 PROJ.4: 4.8.0 GEOS: 3.3.6dev SQLite: 3.7.17 Python: 2.7.4 wxPython: 2.8.12.1 Platform: Windows-Vista-6.0.6002-SP2 C:\Users\assoc .py Dateizuordnung für die Erweiterung .py nicht gefunden. File association for the extension. py not found. C:\Users\ftype python.file Dateityp python.file nicht gefunden, oder diesem Dateityp wurde kein Öffnen-Befehl zugeordnet. File type python.file not found or no associated open command. C:\Users\echo %PATHEXT% .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY --- winGRASS-session (2) winGRASS 7 standalone installer and a www.python.org 2.7.5 installation (system wide installed in C:\Python27) winGRASS 7 standalone installer bundled with Python 2.7.4 (default, Apr 6 2013, 19:54:46) [MSC v.1500 32 bit (Intel)] on win32 System Info GRASS version: 7.0.svn GRASS SVN Revision: 57955 Build Date: 2013-10-08 GIS Library Revision: 56211 (2013-05-12) GDAL/OGR: 1.9.2 PROJ.4: 4.8.0 GEOS: 3.3.6dev SQLite: 3.7.17 Python: 2.7.4 wxPython: 2.8.12.1 Platform: Windows-Vista-6.0.6002-SP2 C:\Users\assoc .py .py=Python.File C:\Users\ftype python.file python.file=C:\Python27\python.exe %1 %* C:\Users\normalecho %PATHEXT% .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY testscript.py: import sys print Hello, World! print sys.version C:\wd\pytestpython testscript.py Hello, World! 2.7.4 (default, Apr 6 2013, 19:54:46) [MSC v.1500 32 bit (Intel)] --- the earlier test was in a win7-box with following python installation python is installed by ArcGIS on this testing box here. ArcGIS 10.0 installed C:\Python26\ArcGIS10.0 after upgrade ArcGIS 10.1 installed C:\Python27\ArcGIS10.1 It suggests that the registry keys are inconsistent. [...] ftype and assoc show the system-wide settings, but these are ignored if there are per-user keys. If the per-user keys exist but the values are invalid, executing a script will result in a dialog asking you to select the program to open that type of file. could it be that ArcGIS installs a inconsistent python? if yes how to deal with this? AFAIK most of the winGRASS-users has also ArcGIS installed. - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Handling-of-Python-scripts-on-MS-Windows-tp5081335p5082670.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
[GRASS-dev] Ampersand and required behavior of module option's guisection
Hi, I've noticed that the ampersand character is interpreted strangely when it is in the `guisection` property of module option, e.g.: #% guisection: Files format is added for the following options in the m.proj module G_OPT_F_INPUT G_OPT_F_OUTPUT G_OPT_F_SEP However, the resulting section in the wxGUI generated module form/dialog is `Files format`. Is interpreted in some special way, e.g. for translation? I was not exploring this more since the number of involved parts is high and I hope that someone might have better overview. Moreover, if you look at the generated form you can see that `input` is still in required, although G_OPT_F_INPUT has guisection specified. This seems that unless you explicitly specify `required: no` guisection is ignored. I must say that I was not even trying to find some documentation for this since these things are usually under-documented. Thus I don't know if this behavior is bug or a feature. Vaclav ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2098: i.vi gari wrong formula?
#2098: i.vi gari wrong formula? ---+ Reporter: kristinah | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.4 Component: Default| Version: unspecified Keywords: |Platform: Unspecified Cpu: All| ---+ The formula for GARI in the manual (http://grass.osgeo.org/grass70/manuals/i.vi.html) seems to be wrong. As it is now, the result would always be 1. It is GARI = ( nirchan - (greenchan-(bluechan - redchan))) / ( nirchan- (greenchan-(bluechan - redchan))) It should be (e.g. according to http://www.indexdatabase.de/db/i-single.php?id=363) GARI = ( nirchan - (greenchan-(bluechan - redchan))) / ( nirchan- (greenchan+(bluechan - redchan))) As the formula in the manual seems to be taken from code, the code might be wrong as well. I did not test the function, only read the manual online. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2098 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] #2098: i.vi gari wrong formula?
From the code: result = (nirchan - (greenchan - (bluechan - redchan)))/(nirchan - (greenchan - (bluechan + redchan))); On 10 October 2013 00:07, GRASS GIS t...@osgeo.org wrote: #2098: i.vi gari wrong formula? ---+ Reporter: kristinah | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.4 Component: Default| Version: unspecified Keywords: |Platform: Unspecified Cpu: All| ---+ The formula for GARI in the manual (http://grass.osgeo.org/grass70/manuals/i.vi.html) seems to be wrong. As it is now, the result would always be 1. It is GARI = ( nirchan - (greenchan-(bluechan - redchan))) / ( nirchan- (greenchan-(bluechan - redchan))) It should be (e.g. according to http://www.indexdatabase.de/db/i-single.php?id=363) GARI = ( nirchan - (greenchan-(bluechan - redchan))) / ( nirchan- (greenchan+(bluechan - redchan))) As the formula in the manual seems to be taken from code, the code might be wrong as well. I did not test the function, only read the manual online. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2098 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 mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2098: i.vi gari wrong formula?
#2098: i.vi gari wrong formula? --+- Reporter: kristinah| Owner: grass-dev@… Type: defect | Status: closed Priority: normal | Milestone: 6.4.4 Component: Default | Version: unspecified Resolution: fixed|Keywords: Platform: Unspecified | Cpu: All --+- Changes (by ychemin): * status: new = closed * resolution: = fixed Comment: Changed the formula according to the indexdatabase website -- Ticket URL: http://trac.osgeo.org/grass/ticket/2098#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
[GRASS-dev] [GRASS GIS] #2099: G_OPT_M_COLR not recognized in Python script
#2099: G_OPT_M_COLR not recognized in Python script
-+--
Reporter: annakrat | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: LibGIS | Version: svn-trunk
Keywords: color table, parser |Platform: Linux
Cpu: Unspecified |
-+--
When I try to use standardized option G_OPT_M_COLR (color tables) in a
Python script, I get only:
{{{
myscript --help
Description:
...
Usage:
...
ERROR: Option key not defined
}}}
and
{{{
myscript --interface-description
...
parameter name=(null) type=string required=no multiple=no
/parameter
...
}}}
This affects t.rast.colors. G_OPT_M_COLR is defined here:
[1]
http://trac.osgeo.org/grass/browser/grass/trunk/lib/gis/parser_standard_options.c#L619
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2099
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] #2097: r.modis install using g.extension fails
#2097: r.modis install using g.extension fails
---+
Reporter: pierreroudier | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Addons | Version: svn-trunk
Keywords: MODIS |Platform: Linux
Cpu: x86-64 |
---+
Comment(by pierreroudier):
Replying to [comment:3 neteler]:
Did you try to manually add the missing subdir? Would the installation
work then?
Same as madi here on Ubuntu:
{{{
GRASS 7.0.svn (eda-rsr):~ mkdir -p
/usr/local/grass-7.0.svn/locale/scriptstrings/
GRASS 7.0.svn (eda-rsr):~ g.extension ext=r.modisWARNING: Extension
r.modis already installed. Re-installing...
Fetching r.modis from GRASS-Addons SVN (be patient)...
WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-VFvFlG/pkcs11:
No such file or directory
Compiling...
Installing...
Updating metadata file...
Installation of r.modis successfully finished
GRASS 7.0.svn (eda-rsr):~ r.modis.import
ERROR: modis library not found
}}}
It installs but of course the directory is not correct so the library is
not found.
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2097#comment:5
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] #2098: i.vi gari wrong formula?
#2098: i.vi gari wrong formula? --+- Reporter: kristinah| Owner: grass-dev@… Type: defect | Status: closed Priority: normal | Milestone: 7.0.0 Component: Imagery | Version: svn-trunk Resolution: fixed|Keywords: i.vi Platform: Unspecified | Cpu: All --+- Changes (by neteler): * keywords: = i.vi * version: unspecified = svn-trunk * component: Default = Imagery * milestone: 6.4.4 = 7.0.0 Comment: For the record: r57967 and r57968 -- Ticket URL: http://trac.osgeo.org/grass/ticket/2098#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
[GRASS-dev] r.unpack: unhelpful error message when projection info does not match
Hi,
the error (example UTM map import into LAEA location):
r.unpack landcover_1m.pack
ERROR: Projection information does not match. Aborting.
is rather unhelpful. The code is:
# check projection compatibility in a rather crappy way
if not grass.compare_key_value_text_files('PROJ_INFO',
os.path.join(mset_dir, '..', 'PERMANENT', 'PROJ_INFO')) or \
not grass.compare_key_value_text_files('PROJ_UNITS',
os.path.join(mset_dir, '..', 'PERMANENT', 'PROJ_UNITS')):
if flags['o']:
grass.warning(_(Projection information does not match.
Proceeding...))
else:
grass.fatal(_(Projection information does not match. Aborting.))
I would suggest to print a diff -u file1 file2 rather than nothing
as now (perhaps Python offers a nice way to show the wrong keys to the
user).
Or are there other options?
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1594: 180 meridian and r.proj
#1594: 180 meridian and r.proj --+- Reporter: awickert | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: Component: Raster| Version: svn-trunk Keywords: r.proj, meridian |Platform: Linux Cpu: x86-64| --+- Changes (by awickert): * version: 6.4.1 = svn-trunk Comment: Hi Hamish, Sorry that I completely overlooked this bug report and let it fall by the wayside! Here is exactly what I am doing: 1. Importing a global gridded data set into a GRASS GIS location (we'll call it L1; this is unprojected: WGS84 = EPSG 4326) 2. Creating a new GRASS GIS location (L2), in the same unprojected coordinate system (WGS84) 3. Inside L2, setting the region to extend across the 180 meridian. In my case, here is the computational region, which is at the same resolution as the global gridded data: g.region -p projection: 3 (Latitude-Longitude) zone: 0 datum: wgs84 ellipsoid: wgs84 north: 80N south: 50N west: 155E east: 125W nsres: 0:00:30 ewres: 0:00:30 rows: 3600 cols: 9600 cells: 3456 4. I run the following command to import the data set, in this case, the GEBCO_08 30-arcsecond global digital elevation model: r.proj loc=GlobalDatabase30as in=toponow 5. I look at the output data extent - only the part of the region to the west of the 180 meridian is imported. I could upload the raster, but it is huge... and this is reproducible by just creating a map of zeros with r.mapcalc in the global location (L1) and trying to bring it into L2 using r.proj. Hope this helps - sorry about the *long* delay - and happy to help with some coding if that is required to take care of this! Andy PS - I just uploaded to today's svn-trunk, so the problem is current. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1594#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] #1594: 180 meridian and r.proj
#1594: 180 meridian and r.proj
--+-
Reporter: awickert | Owner: grass-dev@…
Type: defect| Status: new
Priority: normal| Milestone:
Component: Raster| Version: svn-trunk
Keywords: r.proj, meridian |Platform: Linux
Cpu: x86-64|
--+-
Comment(by awickert):
Here is my current workaround, using r.proj and r.patch:
{{{
#!python
from grass import script as grass
import re
inloc = 'GlobalDatabase30as'
non_decimal = re.compile(r'[^\d.]+') # for my hack-ish solution below
# toponow NEEDS to be added (some other good too):
basicfiles = ['precip_2000_2004', 'et_2000_2004', 'cellsize_km2',
'cellsize_meters2', 'zeros', 'toponow']
for infile in basicfiles:
print infile
# Here we make sure we are using the same resolution as the input map.
# Getting the resolution - there has got to be a much better way to do
this,
# but this is the first thing that came to mind
shreg = grass.parse_command('r.proj', location=inloc,
input='precip_2000_2004', output='tmp0', overwrite=True,
flags='g')['n'].split(' ')[-2:]
for i in range(len(shreg)):
shreg[i] = int(non_decimal.sub('', (shreg[i])))
grass.run_command('g.region', nsres=shreg[0]/180., ewres=shreg[1]/360.,
e='180E')
grass.run_command('r.proj', location=inloc, input=infile, output='tmp0',
overwrite=True)
grass.run_command('g.region', region='default')
grass.run_command('g.region', sres=shreg[0]/180., ewres=shreg[1]/360.,
w='180W')
grass.run_command('r.proj', location=inloc, input=infile, output='tmp1',
overwrite=True)
grass.run_command('g.region', region='default')
grass.run_command('r.patch', input='tmp0,tmp1', output=infile,
overwrite=True)
}}}
Cheers,
Andy Wickert
--
Ticket URL: http://trac.osgeo.org/grass/ticket/1594#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 GIS] #1594: 180 meridian and r.proj
#1594: 180 meridian and r.proj
--+-
Reporter: awickert | Owner: grass-dev@…
Type: defect| Status: new
Priority: normal| Milestone:
Component: Raster| Version: svn-trunk
Keywords: r.proj, meridian |Platform: Linux
Cpu: x86-64|
--+-
Comment(by awickert):
A few mistakes in my previously-posted code; use this instead:
Cheers,
Andy
{{{
#!python
from grass import script as grass
import re
grass.run_command('g.region', save='default')
inloc = 'GlobalDatabase30as'
non_decimal = re.compile(r'[^\d.]+') # for my hack-ish solution below
# toponow NEEDS to be added (some other good too):
basicfiles = ['precip_2000_2004', 'et_2000_2004', 'cellsize_km2',
'cellsize_meters2', 'zeros', 'toponow']
for infile in basicfiles:
print infile
# Here we make sure we are using the same resolution as the input map.
# Getting the resolution - there has got to be a much better way to do
this,
# but this is the first thing that came to mind
shreg = grass.parse_command('r.proj', location=inloc, input=infile,
output='tmp0', overwrite=True, flags='g')['n'].split(' ')[-2:]
for i in range(len(shreg)):
shreg[i] = int(non_decimal.sub('', (shreg[i])))
grass.run_command('g.region', nsres=180./shreg[0], ewres=360./shreg[1],
e='180E')
grass.run_command('r.proj', location=inloc, input=infile, output='tmp0',
overwrite=True)
grass.run_command('g.region', region='default')
grass.run_command('g.region', nsres=180./shreg[0], ewres=360./shreg[1],
w='180W')
grass.run_command('r.proj', location=inloc, input=infile, output='tmp1',
overwrite=True)
grass.run_command('g.region', region='default')
grass.run_command('r.patch', input='tmp0,tmp1', output=infile,
overwrite=True)
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/1594#comment:5
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] r.unpack: unhelpful error message when projection info does not match
Hi,
please test r57969. You should see a diff if the proj_info files don't
match.
Anna
On Wed, Oct 9, 2013 at 6:08 PM, Markus Neteler nete...@osgeo.org wrote:
Hi,
the error (example UTM map import into LAEA location):
r.unpack landcover_1m.pack
ERROR: Projection information does not match. Aborting.
is rather unhelpful. The code is:
# check projection compatibility in a rather crappy way
if not grass.compare_key_value_text_files('PROJ_INFO',
os.path.join(mset_dir, '..', 'PERMANENT', 'PROJ_INFO')) or \
not grass.compare_key_value_text_files('PROJ_UNITS',
os.path.join(mset_dir, '..', 'PERMANENT', 'PROJ_UNITS')):
if flags['o']:
grass.warning(_(Projection information does not match.
Proceeding...))
else:
grass.fatal(_(Projection information does not match.
Aborting.))
I would suggest to print a diff -u file1 file2 rather than nothing
as now (perhaps Python offers a nice way to show the wrong keys to the
user).
Or are there other options?
Markus
___
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
