[GRASS-dev] g.proj not found
Hi devs,
just update grass7 and the gui doesn't start, the problem seems
related to missing module g.proj, but I think probably is related to
find_program.
find_program('r.proj','help') and also find_program('r.proj') return
false instead find_program('ls') return true
the error is
GRASS module 'g.proj' not found. Unable to start map display window.
I have the same error compiling after a distclean in g.gui.vdigit command.
--
ciao
Luca
http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2008: grass.script's find_program() can't find modules
#2008: grass.script's find_program() can't find modules
---+
Reporter: hamish| Owner: grass-dev@…
Type: defect| Status: reopened
Priority: critical | Milestone: 6.4.4
Component: Python| Version: svn-releasebranch64
Resolution:|Keywords: find_program()
Platform: All | Cpu: x86-64
---+
Comment(by zarch):
Replying to [comment:21 glynn]:
What is self._runCommand? Or what is self for that matter?
find_program() is a function, not a method. And it isn't part of the
wxGUI, so it can't use any functions from it.
In my example I'm not using any method...
I only replace the function find_program with try, in the example that
you can find:
http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/core/render.py?rev=56800#L454
{{{
Index: gui/wxpython/core/render.py
===
--- gui/wxpython/core/render.py (revision 56810)
+++ gui/wxpython/core/render.py (working copy)
@@ -451,12 +451,13 @@
!Return region projection and map units information
projinfo = dict()
-if not grass.find_program('g.proj'):
-sys.exit(_(GRASS module '%s' not found. Unable to start map
- display window.) % 'g.proj')
+try:
ret = self._runCommand(RunCommand, prog = 'g.proj',
read = True, flags = 'p')
+except OSError:
+sys.exit(_(GRASS module '%s' not found. Unable to start map
+ display window.) % 'g.proj')
if not ret:
return projinfo
}}}
As you see probably we don't need to define a new function...
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2008#comment:22
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] module input (multiple type) in pyGRASS
Hi Yann,
On Friday 21 Jun 2013 10:48:14 Yann Chemin wrote:
Hi,
I am having trouble with multiple input in pyGRASS:
Example:
-
b_in=[b1,b2,b3,b4,b5,b7]
i.albedo(input=b_in, output=b_albedo, flags=lc, overwrite=OVR)
input has a multiple raster band names requirement (6 here),
using a list to define b_in does not work.
What kind of container should I use?
you should use a list as you do...
I don't have your map so I'm not able to reproduce the problem on my
machine...
I've try with:
{{{
from grass.pygrass.modules.shortcuts import imagery as i
alb = i.albedo
alb(input=['b1', 'b2', 'b3', 'b4', 'b5', 'b7'],
output='b_albedo', flags=lc, overwrite=True, run_=False)
alb.get_bash()
}}}
and return 'i.albedo input=b1,b2,b3,b4,b5,b7 output=b_albedo -l -c --o'
that it seems correct to me...
Can you provide some more details about b_in does not work? :-)
What kind of error do you have?
Best regards
Pietro
ps: thank you for testing!
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.proj not found
On Fri, Jun 21, 2013 at 9:58 AM, Luca Delucchi lucadel...@gmail.com wrote:
Hi devs,
just update grass7 and the gui doesn't start, the problem seems
related to missing module g.proj, but I think probably is related to
find_program.
find_program('r.proj','help') and also find_program('r.proj') return
false instead find_program('ls') return true
the error is
GRASS module 'g.proj' not found. Unable to start map display window.
Fixed in r56865.
Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] module input (multiple type) in pyGRASS
Hi Pietro,
here is the summary of what I want to do...
OVR=True
pref='LE71340442011084PFS00_B'
b1=pref[:-2]+.surf.1
b2=pref[:-2]+.surf.2
b3=pref[:-2]+.surf.3
b4=pref[:-2]+.surf.4
b5=pref[:-2]+.surf.5
b7=pref[:-2]+.surf.7
b_in=[b1,b2,b3,b4,b5,b7]
b_albedo=pref[:-2]+.surf.albedo
print Albedo:\t,b_albedo
i.albedo(input=b_in, output=b_albedo, flags=lc, overwrite=OVR)
r.colors(map=b_albedo,color='grey')
Ciao,
Yann
On 21 June 2013 15:40, Pietro Zambelli peter.z...@gmail.com wrote:
Hi Yann,
On Friday 21 Jun 2013 10:48:14 Yann Chemin wrote:
Hi,
I am having trouble with multiple input in pyGRASS:
Example:
-
b_in=[b1,b2,b3,b4,b5,b7]
i.albedo(input=b_in, output=b_albedo, flags=lc, overwrite=OVR)
input has a multiple raster band names requirement (6 here),
using a list to define b_in does not work.
What kind of container should I use?
you should use a list as you do...
I don't have your map so I'm not able to reproduce the problem on my
machine...
I've try with:
{{{
from grass.pygrass.modules.shortcuts import imagery as i
alb = i.albedo
alb(input=['b1', 'b2', 'b3', 'b4', 'b5', 'b7'],
output='b_albedo', flags=lc, overwrite=True, run_=False)
alb.get_bash()
}}}
and return 'i.albedo input=b1,b2,b3,b4,b5,b7 output=b_albedo -l -c --o'
that it seems correct to me...
Can you provide some more details about b_in does not work? :-)
What kind of error do you have?
Best regards
Pietro
ps: thank you for testing!
--
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] pyGRASS send job to background
Hi, I have several jobs that can be run together, in BASH we can add at the end of the module command, is there a pyGRASS option we can throw to the same effect? Cheers, Yann -- ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] pyGRASS send job to background
On Friday 21 Jun 2013 16:20:00 Yann Chemin wrote: I have several jobs that can be run together, in BASH we can add at the end of the module command, is there a pyGRASS option we can throw to the same effect? yes, the parameter is: finish_=False, in this way python will not wait the end of the module command... Sorry I have to add this in the documentation... Pietro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] module input (multiple type) in pyGRASS
i.albedo flag -c is generating a segfault on this, not anything to
do with pyGRASS
On 21 June 2013 16:13, Yann Chemin yche...@gmail.com wrote:
Hi Pietro,
here is the summary of what I want to do...
OVR=True
pref='LE71340442011084PFS00_B'
b1=pref[:-2]+.surf.1
b2=pref[:-2]+.surf.2
b3=pref[:-2]+.surf.3
b4=pref[:-2]+.surf.4
b5=pref[:-2]+.surf.5
b7=pref[:-2]+.surf.7
b_in=[b1,b2,b3,b4,b5,b7]
b_albedo=pref[:-2]+.surf.albedo
print Albedo:\t,b_albedo
i.albedo(input=b_in, output=b_albedo, flags=lc, overwrite=OVR)
r.colors(map=b_albedo,color='grey')
Ciao,
Yann
On 21 June 2013 15:40, Pietro Zambelli peter.z...@gmail.com wrote:
Hi Yann,
On Friday 21 Jun 2013 10:48:14 Yann Chemin wrote:
Hi,
I am having trouble with multiple input in pyGRASS:
Example:
-
b_in=[b1,b2,b3,b4,b5,b7]
i.albedo(input=b_in, output=b_albedo, flags=lc, overwrite=OVR)
input has a multiple raster band names requirement (6 here),
using a list to define b_in does not work.
What kind of container should I use?
you should use a list as you do...
I don't have your map so I'm not able to reproduce the problem on my
machine...
I've try with:
{{{
from grass.pygrass.modules.shortcuts import imagery as i
alb = i.albedo
alb(input=['b1', 'b2', 'b3', 'b4', 'b5', 'b7'],
output='b_albedo', flags=lc, overwrite=True, run_=False)
alb.get_bash()
}}}
and return 'i.albedo input=b1,b2,b3,b4,b5,b7 output=b_albedo -l -c --o'
that it seems correct to me...
Can you provide some more details about b_in does not work? :-)
What kind of error do you have?
Best regards
Pietro
ps: thank you for testing!
--
--
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] pyGRASS send job to background
On Friday 21 Jun 2013 13:08:48 Pietro Zambelli wrote:
Sorry I have to add this in the documentation...
False, it was already in the code... I forgot to activate the foot with the
special parameters... :-)
Now if you ask for the doc in an interactive shell with:
{{{
i.albedo?
}}}
You get:
{{{
Parameters
--
input: required, multistring
Name of input raster map
output: required, string
Name for output raster map
Flags
--
m: None
Modis (7 input bands:1,2,3,4,5,6,7)
n: None
NOAA AVHRR (2 input bands:1,2)
l: None
Landsat (6 input bands:1,2,3,4,5,7)
a: None
Aster (6 input bands:1,3,5,6,8,9)
c: None
Albedo dry run to calculate some water to beach/sand/desert
stretching, a kind of simple atmospheric correction
d: None
Albedo dry run to calculate some water to beach/sand/desert
stretching, a kind of simple atmospheric correction
overwrite: None
Allow output files to overwrite existing files
verbose: None
Verbose module output
quiet: None
Quiet module output
Special Parameters
--
The Module class have some optional parameters which are distinct using a
final underscore.
run_: True, optional
If True execute the module.
finish_: True, optional
If True wait untill the end of the module execution, and store the module
outputs into stdout, stderr attributes of the class.
stdin_: PIPE,
Set the standard input
env_: dictionary, optional
Set the evironment variables.
}}}
Thank you for the help.
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] pyGRASS send job to background
Yann wrote: I have several jobs that can be run together, in BASH we can add at the end of the module command, is there a pyGRASS option we can throw to the same effect? fwiw the import grass.script way to do it is demonstrated in scripts/r3.in.xyz.py and i.landsat.rgb.py scripts. see also grass.start_command() and raster.mapcalc_start() Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.proj not found
Luca wrote:
just update grass7 and the gui doesn't start, the problem seems
related to missing module g.proj, but I think probably is related to
find_program.
find_program('r.proj','help') and also
find_program('r.proj') return
false instead find_program('ls') return true
the error is
GRASS module 'g.proj' not found. Unable to start map display window.
I have the same error compiling after a distclean in g.gui.vdigit command.
Hi Luca,
I saw the same earlier today, under the current version of find_program() it
needs to be like:
find_program('r.proj', ['help'])
but that way of calling it may or may not change again in the coming days so
I was just rolling with it for now, it's a dev branch after all.
Index: gui_core/mapdisp.py
===
--- gui_core/mapdisp.py (revision 56845)
+++ gui_core/mapdisp.py (working copy)
@@ -105,7 +105,7 @@
def _initMap(self, Map):
!Initialize map display, set dimensions and map region
- if not grass.find_program('g.region'):
+ if not grass.find_program('g.region', ['--help']):
sys.exit(_(GRASS module '%s' not found. Unable to start map
display window.) % 'g.region')
Index: core/render.py
===
--- core/render.py (revision 56845)
+++ core/render.py (working copy)
@@ -451,7 +451,7 @@
!Return region projection and map units information
projinfo = dict()
- if not grass.find_program('g.proj'):
+ if not grass.find_program('g.proj', ['--help']):
sys.exit(_(GRASS module '%s' not found. Unable to start map
display window.) % 'g.proj')
Index: gui_core/gselect.py
===
--- gui_core/gselect.py (revision 56845)
+++ gui_core/gselect.py (working copy)
@@ -1803,7 +1803,7 @@
driver = 'pg').splitlines()
if db is not None:
win.SetItems(sorted(db))
- elif grass.find_program('psql'):
+ elif grass.find_program('psql', ['--help']):
if not win.GetItems():
p = grass.Popen(['psql', '-ltA'], stdout = grass.PIPE)
ret = p.communicate()[0]
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2014: r.sun using EPSG:3031 projection gives strange results
#2014: r.sun using EPSG:3031 projection gives strange results ---+ Reporter: pierreroudier | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Keywords: |Platform: Linux Cpu: x86-64 | ---+ I am working on Antarctica data, projected in Antarctic Polar Stereographic (EPSG:3031 [0][1]). This projection puts the South Pole in the center of the map. I have strange results in the Ross Sea Region using r.sun from GRASS 7 compiled from trunk: According to the r.sun results, the south facing slope receive more radiation than the north facing one, which doesn't add up. [0] http://spatialreference.org/ref/epsg/3031/ [1] http://nsidc.org/data/atlas/epsg_3031.html -- Ticket URL: http://trac.osgeo.org/grass/ticket/2014 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] #2008: grass.script's find_program() can't find modules
#2008: grass.script's find_program() can't find modules
---+
Reporter: hamish| Owner: grass-dev@…
Type: defect| Status: reopened
Priority: critical | Milestone: 6.4.4
Component: Python| Version: svn-releasebranch64
Resolution:|Keywords: find_program()
Platform: All | Cpu: x86-64
---+
Comment(by glynn):
Replying to [comment:2 glynn]:
It would be trivial to change the function, i.e.
{{{
-def find_program(pgm, args = []):
+def find_program(pgm, *args):
}}}
Done in r56867.
Also, it now ignores the exit code, so it shouldn't be necessary to pass
additional arguments unless they're necessary to prevent the program from
e.g. firing up a GUI.
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2008#comment:23
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] GSoC - T-Algebra - Weekly report
Hi all, the wiki page for my GSoC project now feature an overview, the project plan and the weekly reports. It can be found here: http://grasswiki.osgeo.org/wiki/GRASS_GSoC_2013_Temporal_GIS_Algebra_for_raster_and_vector_data_in_GRASS This week topics: - Extended the v.mapcalc module with a command list class (Important for later use in preprocessing steps of the temporal algebra). - Create a developer wiki page for the temporal algebra concepthttp://trac.osgeo.org/grass/wiki/Grass7/TemporalGISAlgebra. - Working on the concept. - Writing first example programs, experience with the TGIS framework. Next week: Start implementing the temporal algebra. Any Problems?: No major problem this week My repository can be found here: https://code.google.com/p/grass-gis-temporal-algebra/ Any comments or suggestions are welcome. Best regards Thomas ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2008: grass.script's find_program() can't find modules
#2008: grass.script's find_program() can't find modules ---+ Reporter: hamish| Owner: grass-dev@… Type: defect| Status: reopened Priority: critical | Milestone: 6.4.4 Component: Python| Version: svn-releasebranch64 Resolution:|Keywords: find_program() Platform: All | Cpu: x86-64 ---+ Comment(by wenzeslaus): I've committed the small fix for r56867 in r56869 (Python says ''can only concatenate list (not tuple) to list''). There is except without OSError, mentioned before, is there any reason for this? I was about to commit the special case for the `explorer` cmd on MS Win. However, there is also a special case for `xdg-open`, I'm not sure why. Moreover, I tested also other command and e.g. `firefox` blocks the g.manual (it also blocks the cmd line when launched without ). On the other hand, in case of g.manual it opens the requested page, so it means that it goes behind the `call` function in `find_program`. This confuses me, I'would expect that the `wait()` call in `call` function implementation should block the interpreter sooner (i.e. in `find_program`). We probably cannot find safe (help or version) arguments for all possible web browsers. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2008#comment:24 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] #2008: grass.script's find_program() can't find modules
#2008: grass.script's find_program() can't find modules ---+ Reporter: hamish| Owner: grass-dev@… Type: defect| Status: reopened Priority: critical | Milestone: 6.4.4 Component: Python| Version: svn-releasebranch64 Resolution:|Keywords: find_program() Platform: All | Cpu: x86-64 ---+ Comment(by annakrat): Replying to [comment:24 wenzeslaus]: We probably cannot find safe (help or version) arguments for all possible web browsers. Why not to have two functions: find_program - behaves like which command, test_program - or something similar which tests the program by calling it. For web browsers we could use the which implementation. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2008#comment:25 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] #2008: grass.script's find_program() can't find modules
#2008: grass.script's find_program() can't find modules
---+
Reporter: hamish| Owner: grass-dev@…
Type: defect| Status: reopened
Priority: critical | Milestone: 6.4.4
Component: Python| Version: svn-releasebranch64
Resolution:|Keywords: find_program()
Platform: All | Cpu: x86-64
---+
Comment(by wenzeslaus):
Replying to [comment:24 wenzeslaus]:
I was about to commit the special case for the `explorer` cmd on MS Win.
However, there is also a special case for `xdg-open`, I'm not sure why.
Moreover, I tested also other command and e.g. `firefox` blocks the
g.manual (it also blocks the cmd line when launched without ). On the
other hand, in case of g.manual it opens the requested page, so it means
that it goes behind the `call` function in `find_program`. This confuses
me, I'would expect that the `wait()` call in `call` function
implementation should block the interpreter sooner (i.e. in
`find_program`).
I tested it again and I probably did some mistake before. `firefox` and
`chromium-browser` blocks `g.manual` in `find_program` (browser starts
empty). `xdg-open`, `gnome-open` and `kde-open` works well.
I still don't know why there was special case for `xdg-open`.
Alternatively, we don't need to do `find_program`/`test_program` for
browser, we can just run and report only after `os.execlp` (now there is
an error message anyway).
Replying to [comment:25 annakrat]:
Why not to have two functions: find_program - behaves like which
command, test_program - or something similar which tests the program by
calling it. For web browsers we could use the which implementation.
Maybe, also the third one for `test_(grass_)module` for GRASS modules?
(Than, we would use `test_module('r.sun')` instead of
`test_program('r.sun', '--help')`) The point is that we need special cases
anyway, so why not to make it explicit.
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2008#comment:26
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] #1978: module GUIs: or enter values interactively should be opt-in
#1978: module GUIs: or enter values interactively should be opt-in +--- Reporter: hamish | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.4 Component: wxGUI | Version: svn-trunk Keywords: parser |Platform: All Cpu: All | +--- Comment(by annakrat): Replying to [comment:2 hamish]: If term 2 (element) is file, trunk's libgis checks to see if the file already exists insists on --overwrite. So for file input= and output= term 2 should probably stay as file. This also means that the GUI should use term 2 (element) to decide if there should be a file [Browse] button present, instead of term 3 (prompt/description) as it does now. so that leaves the switch for deciding on a text input box to be based on the third term (prompt/description). (as far as gui/wxpython/gui_core/forms.py is concerned) so e.g. for r.in.mat we have this info from --interface-description gisprompt age=old element=mat prompt=file / `element` would go back to file, and term 3, `prompt` (aka description), would change from file to text (or bin or generic file). And the or enter text interactively box would be made to only show up if `prompt` was text. I agree. file as element and text or bin as prompt (this is what you mean, is it?). Currently it's the opposite way. Apart from bin, grep shows also camera or font - is there any reason to keep them? -- Ticket URL: https://trac.osgeo.org/grass/ticket/1978#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] #2008: grass.script's find_program() can't find modules
#2008: grass.script's find_program() can't find modules ---+ Reporter: hamish| Owner: grass-dev@… Type: defect| Status: reopened Priority: critical | Milestone: 6.4.4 Component: Python| Version: svn-releasebranch64 Resolution:|Keywords: find_program() Platform: All | Cpu: x86-64 ---+ Comment(by wenzeslaus): After playing with g.manual longer, I think that the safest way is to not test browser at all and just run it as I suggested before. In r56871 (which is otherwise neutral to this ticked) I've fixed use of `os.execlp` by using try-except, so g.manual is ready for deletion of the find_program test if there are no objections. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2008#comment:27 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] #1978: module GUIs: or enter values interactively should be opt-in
#1978: module GUIs: or enter values interactively should be opt-in +--- Reporter: hamish | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.4 Component: wxGUI | Version: svn-trunk Keywords: parser |Platform: All Cpu: All | +--- Comment(by mmetz): Replying to [comment:3 annakrat]: Apart from bin, grep shows also camera or font - is there any reason to keep them? Regarding camera, please keep it as an element (as in g.findfile element=camera), it is used by the orthorectification modules. -- Ticket URL: https://trac.osgeo.org/grass/ticket/1978#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] Unexpected EVI range from i.vi
Markus Metz wrote: I think I figured it out: The EVI formula in i.vi is for MODIS. Nikos A: That's precise, EVI is MODIS specific. We should clearly describe this in the manual (I will try to alter the respective text). MM: From the literature, I gor the impression that EVI can be calculated from other sensors as well, as long as you get the coefficients right. Yes, but this is not an easy job, is it? This is (also) why, I think, they (MODIS science team) developed the EVI2, which is cross-sensor. The generic formula is G * ( nir - red) / (nir + C1 * red - C2 * blue + L) where G is a gain factor, C1, C2 are coefficients to correct for aerosol influences in the red band using the blue band and L is the canopy background adjustment that addresses non-linear, differential NIR and red radiant transfer through a canopy. Assuming that the input to i.vi should be properly preprocessed bands with a theoretically maximum range of [0, 1], you could set L to 0.0001 and would get reasonable EVI values, sensor-independent. This reminds, if I am not wrong (didn't check) the scale factor for MOD09 surface reflectance products. Makes sense. Thank you Markus for the time you invested for this. Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Unexpected EVI range from i.vi
Markus, and whom this is of interest, do you care for a small diff for the manual? Like, - replace the reference (as you suggested) - mention that EVI is not consistent across different sensors due to its requirement for a blue-band input [0] Nikos --- [0] Zhangyan Jiang ; Alfredo R. Huete ; Youngwook Kim and Kamel Didan 2-band enhanced vegetation index without a blue band and its application to AVHRR data, Proc. SPIE 6679, Remote Sensing and Modeling of Ecosystems for Sustainability IV, 667905 (October 09, 2007); doi:10.1117/12.734933; http://dx.doi.org/10.1117/12.734933 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Weekly report #1 - GRASS Interactive Scatter Plot Tool
Hello all, 1) What do I have completed this week? I have been working on integration of the scatter plot tool with mapwindow. This week I was able to fully focus on my GSoC project for just first 2 days, than I had to deal with the last subject, which I have to finish this semester. 2) What am I going to achieve for next week? During the week I would like to publish existing code in GRASS AddOns repository and continue to work on integration of the scatter plot tool with mapwindow. 3) Is there any blocking issue? No. Regards, Stepan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2014: r.sun using EPSG:3031 projection gives strange results
#2014: r.sun using EPSG:3031 projection gives strange results ---+ Reporter: pierreroudier | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Keywords: r.sun |Platform: Linux Cpu: x86-64 | ---+ Changes (by hamish): * keywords: = r.sun Comment: Hi, I saw the post on the mailing list and will have a look at it -- it might take me a little while to get to it though. You might try to compare with the version of r.sun in GRASS 6.4.3svn, as in GRASS 7 some map projection calculations have been moved out of the main loop to allow the GPU/multiprocessor acceleration to work. It won't necessarily fix it, but it may be useful to test. A couple other things to look at: is the sun over or under the horizon when it happens (there may be no direct sun but still some diffuse radiation?), and if PROJ.4 is handling the projection properly (projections not north up (which way is north in a polar stereographic?), non-Greenwich prime meridians etc.) in general, polar stereographic is known to work, at least with v.proj: http://grassold.osgeo.org/screenshots/images/day_on_earth_S.png Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/2014#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] #1978: module GUIs: or enter values interactively should be opt-in
#1978: module GUIs: or enter values interactively should be opt-in +--- Reporter: hamish | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.4 Component: wxGUI | Version: svn-trunk Keywords: parser |Platform: All Cpu: All | +--- Comment(by hamish): (just to clarify for anyone reading along at home, element here typically refers to a subdirectory of the MAPSET dir) -- Ticket URL: https://trac.osgeo.org/grass/ticket/1978#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
