Re: [GRASS-user] i.landsat.toar comments have only 0 value

[Nikos Alexandris]

Daniel Victoria wrote:

> Updating my last email. I also see the same problem in WinGrass 6.4.3
> 
> And on a similar topic, i.landsat.toar in Grass6 has one extra
> correction method when compared with Grass7.
> In grass6 there is a Corrected at-sensor values options which I don't
> see in Grass7. Why is that?

Daniel, I only see the same for both versions:

"Options: uncorrected,dos1,dos2,dos2b,dos3,dos4"

Can you post more details?

Nikos

[rest deleted]


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] i.landsat.toar comments have only 0 value

[Nikos Alexandris]

@Beatrice

(after reading Daniel's e-mail, it reminded me that) I completely forgot to 
keep-up as promissed to test some Landsat scenes related with the issue 
reported in this thread.  I am really sorry, I got work and other issues to 
think about the past few weeks so I simply forgot it... :-(

Hope you found a solution anyway.

Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] scripting efficiency

[Moritz Lennert]

On 16/10/13 07:59, Wiley Bogren wrote:

hi GRASS community!

I'm amazed how well this software handles vector operations - especially
the overlay operation seems unparalleled in open source software.  Thank
you very much to everyone who has been involved in the development process!

I would like to script a workflow where I apply the same set of
operations on a few hundred sets of shapefiles, consisting of v.in.ogr,
several sets of v.overlay, some database operations and v.out.ogr.  The
shapefiles are 20-30MB apiece, containing many polygons, each with many
vertices.

Is there a difference in speed or processor efficiency between the
different scripting approaches?  By which I mean python vs bash shell,
and within the GRASS environment vs calling the functions from outside
the environment (like via python grass.script).

Thank you for any opinions or advice!


I see that no one ever answered this. AFAIK, speed will depend on how 
much you do in the script and how much you have GRASS modules do. The 
latter don't change their speed depending on the scripting language 
calling them, so if you only use the script to link different GRASS 
modules, I would think that time difference will be negligible between 
languages.


Moritz
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Compilation error with g.extension v.krige

[Alessandro Sarretta]

Hi Markus,

On 10/17/2013 09:03 PM, Markus Neteler wrote:
I have fixed the Makefile of v.krige for this. Should be fine as of 
r58031.


Please try again
g.extension v.krige

(and let us know)


thank you, very much now g.extension v.krige works fine!
But when I try
v.krige
I have this error:

/Loading packages, please wait...//
//
//Attaching package: ‘XML’//
//
//The following object(s) are masked from ‘package:tools’://
//
//toHTML//
//
//GRASS GIS interface loaded with GRASS version: GRASS 6.4.3 (2013) //
//and location: wgs84//
//Checking rgeos availability: TRUE//
//Traceback (most recent call last)://
//  File "/home/ale/.grass6/addons/v.krige", line 422, in //
//main()//
//  File "/home/ale/.grass6/addons/v.krige", line 309, in main//
//import globalvar//
//ImportError: No module named globalvar//
/
I'm still using GRASS 6.4.3. Should I try to use GRASS 7 in trunk?
Thanks again
Ale

--
Alessandro Sarretta

e-mail: alessandro.sarre...@gmail.com
skype: alesarrett
Web: http://ilsarrett.wordpress.com
Twitter: https://twitter.com/alesarrett
Google scholar: http://scholar.google.it/citations?hl=it&user=IsyXargJ
ORCID: http://orcid.org/-0002-1475-8686
ResearchGate: https://www.researchgate.net/profile/Alessandro_Sarretta/

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] scripting efficiency

[Wiley Bogren]

Hi Moritz,

Thank you.  Just to check, there's nothing like a startup cost each time
you call grass from an external (bash or python) script?

-Wiley


On Fri, Oct 18, 2013 at 3:00 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> On 16/10/13 07:59, Wiley Bogren wrote:
>
>> hi GRASS community!
>>
>> I'm amazed how well this software handles vector operations - especially
>> the overlay operation seems unparalleled in open source software.  Thank
>> you very much to everyone who has been involved in the development
>> process!
>>
>> I would like to script a workflow where I apply the same set of
>> operations on a few hundred sets of shapefiles, consisting of v.in.ogr,
>> several sets of v.overlay, some database operations and v.out.ogr.  The
>> shapefiles are 20-30MB apiece, containing many polygons, each with many
>> vertices.
>>
>> Is there a difference in speed or processor efficiency between the
>> different scripting approaches?  By which I mean python vs bash shell,
>> and within the GRASS environment vs calling the functions from outside
>> the environment (like via python grass.script).
>>
>> Thank you for any opinions or advice!
>>
>
> I see that no one ever answered this. AFAIK, speed will depend on how much
> you do in the script and how much you have GRASS modules do. The latter
> don't change their speed depending on the scripting language calling them,
> so if you only use the script to link different GRASS modules, I would
> think that time difference will be negligible between languages.
>
> Moritz
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] scripting efficiency

[Moritz Lennert]

[Please leave discussions on the list]

On 18/10/13 15:40, Wiley Bogren wrote:

Thank you.  Just to check, there's nothing like a startup cost each time
you call grass from an external (bash or python) script?



I think this "startup" cost is minimal, as all that "starting up" GRASS 
actiually means is setting a few environment variables.


Moritz




-Wiley


On Fri, Oct 18, 2013 at 3:00 AM, Moritz Lennert
mailto:mlenn...@club.worldonline.be>> wrote:

On 16/10/13 07:59, Wiley Bogren wrote:

hi GRASS community!

I'm amazed how well this software handles vector operations -
especially
the overlay operation seems unparalleled in open source
software.  Thank
you very much to everyone who has been involved in the
development process!

I would like to script a workflow where I apply the same set of
operations on a few hundred sets of shapefiles, consisting of
v.in.ogr,
several sets of v.overlay, some database operations and
v.out.ogr.  The
shapefiles are 20-30MB apiece, containing many polygons, each
with many
vertices.

Is there a difference in speed or processor efficiency between the
different scripting approaches?  By which I mean python vs bash
shell,
and within the GRASS environment vs calling the functions from
outside
the environment (like via python grass.script).

Thank you for any opinions or advice!


I see that no one ever answered this. AFAIK, speed will depend on
how much you do in the script and how much you have GRASS modules
do. The latter don't change their speed depending on the scripting
language calling them, so if you only use the script to link
different GRASS modules, I would think that time difference will be
negligible between languages.

Moritz





___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] scripting efficiency

[Pietro]

Hi Wiley,

On Wed, Oct 16, 2013 at 6:59 AM, Wiley Bogren  wrote:
> hi GRASS community!
>
> I'm amazed how well this software handles vector operations - especially the
> overlay operation seems unparalleled in open source software.  Thank you
> very much to everyone who has been involved in the development process!
>
> I would like to script a workflow where I apply the same set of operations
> on a few hundred sets of shapefiles, consisting of v.in.ogr, several sets of
> v.overlay, some database operations and v.out.ogr.  The shapefiles are
> 20-30MB apiece, containing many polygons, each with many vertices.
>
> Is there a difference in speed or processor efficiency between the different
> scripting approaches?  By which I mean python vs bash shell, and within the
> GRASS environment vs calling the functions from outside the environment
> (like via python grass.script).

Sorry for the late response...
I've imported several files, using a multiprocessing approach in python, with:

{{{
from multiprocessing import Queue, Process, cpu_count
from os.path import split
from subprocess import Popen

from grass.pygrass.functions import findfiles


def spawn(func):
def fun(q_in, q_out):
while True:
path, cmdstr = q_in.get()
if path is None:
break
q_out.put(func(path, cmdstr))
return fun


def mltp_importer(dirpath, match, cmdstr, func, nprocs=cpu_count()):
q_in = Queue(1)
q_out = Queue()
procs = [Process(target=spawn(func), args=(q_in, q_out))
 for _ in range(nprocs)]
for proc in procs:
proc.daemon = True
proc.start()

# set the parameters
sent = [q_in.put((path, cmdstr)) for path in findfiles(dirpath, match)]
# set the end of the cycle
[q_in.put((None, None)) for proc in procs]
[proc.join() for proc in procs]
return [q_out.get() for _ in range(len(sent))]


def importer(path, cmdstr):
name = split(path)[-1][:-4]
popen = Popen(cmdstr.format(path=path, name=name), shell=True)
popen.wait()
return path, name, False if popen.returncode else True

DIR = '/data/gis/data/Aviemore/shp'
CMD = 'v.in.ogr dsn={path} layer={name} output={name} -o --o'

processed = mltp_importer(DIR, '*.shp', CMD, importer)
# check for errors
errors = [p for p in processed if not p[2]]
if errors:
# do something
pass
}}}

I hope that this could help you...
the code is freely inspired by: http://stackoverflow.com/a/16071616
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] i.landsat.toar comments have only 0 value

[Nikos Alexandris]

Daniel Victoria wrote:

> Niko,

(thanks for paying attention to details, correct, in Greek you have to omit 
the final "s" when you call someone by its name, the vocative case!)

 
> Attached goes a screenshot showing my Grass version (6.4.3) and the
> correction methods available in i.landsat.toar
> Noticed the "corrected" method option.


I think I recall (now) seeing it also in the past (in the 6.4.x series). 
Hemm... ?  Not present now in

g.version -rg
version=6.4.4svn
revision=57976
date=2013
libgis_revision=50937 
libgis_date="2012-02-25 15:14:51 +0200 (Sat, 25 Feb 2012) "

here.


> Also, you can see in the GIS Layer Manager the output of r.info of one
> of the reflectance images. Notice how all values are equal to zero...

This must be (one of) the old buggy version of the code -- otherwise, there is 
no reason to get all-zero except, I guess, if you feed all-zero data.

 
> This is what the manual says about the "corrected" method:

(Below ignore most of my comments, I just repeat things for my own practice.)

So, this is for 6.4.3 
():

> 
> Corrected at-sensor values (method=corrected)
> At-sensor reflectance values range from zero to one,

right, it's a unitless ratio (see Wikipedia or else on Reflectance -- there is 
also an old post in which I asked Yann Chemin about it...)


> whereas at-sensor radiance must be greater or equal to zero.

right, Spectral Radiance is  W · sr^−1 · m^−3  or  W · m^-2 · sr^-1 · μm^-1  
and it's normal to have values ranging above 1.


> However, since Lmin can be a negative number then the at-sensor values can
> also be negative. To avoid these possible negative values and set the
> minimum possible values at-sensor to zero, this method corrects the radiance 
> to output a corrected at-sensor values using the equations (not for thermal
> bands):

> radiance = (uncorrected_radiance - Lmin)
 
> reflectance = radiance / sun_radiance

> Note: Other possibility to avoid negative values is set to zero this
> values (radiance and/or reflectance), but this option is ease with
> uncorrected method and r.mapcalc.
> -

It was removed in r57858:



?

Browsing more of the source code, I found a comment: "Deleted in 2013".  Let's 
ask Jorge :-).

Nevertheless and in general, I think, we require Spectral Reflectance values 
to practice remote sensing. So having Radiance values, in a way "corrected 
Radiances" to do away with issues arising from "negative" values, doesn't mean 
you'd want to use them directly. You'd probably need to convert them to 
Reflectances, right?

By the way, a nice overview is the presentation entitled

"Calibrated Landsat Digital Number (DN) to Top of Atmosphere (TOA) Reflectance 
Conversion" by Richard Irish.

Greetings, Nikos

[..]

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] i.landsat.toar comments have only 0 value

[Daniel Victoria]

On Fri, Oct 18, 2013 at 12:30 PM, Nikos Alexandris
 wrote:
> Daniel Victoria wrote:
>
>> Niko,
>
> (thanks for paying attention to details, correct, in Greek you have to omit
> the final "s" when you call someone by its name, the vocative case!)
>

It was actually a typo! I forgot to hit the S key. I was not aware of
those differences in Greek. But hey, it worked :)

Just another piece of information. Even though the r.info output shows
all zeros, both the radiance and TOA reflectance values looks correct.
At least for band 1, when compared with radiance and reflectance
calculated manually (using gain/bias and Solar radiance formulas).

Cheers
Daniel
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] r.stream.* addons issue

[Bulent Arikan]

Dear List,

I am trying to add on several (r.stream.*) modules from 
(http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6). I am running Mac OS 10.8.5 
and I tried this both in GRASS 6.4.3 and 6.5 (latest builds by Michael Barton). 
I tried both typing the command into GUI and using g.extension (both command 
dialog and fetch&install methods). In g.extension, I type the name of the 
extension (r.stream.basins), check -s flag (install system-wide, provide the 
SVN URL 
(https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.stream.basins), I 
keep the prefix path at default ($GRASS_ADDON_PATH) (GRASS should ignore this 
anyway because of the -s flag)

I am getting the error below:

Traceback (most recent call last):
  File "/Applications/GRASS_6.4.3/GRASS-6.4.3.app/Contents/M
acOS/etc/gui/scripts/g.extension.py", line 828, in 
sys.exit(main())
  File "/Applications/GRASS_6.4.3/GRASS-6.4.3.app/Contents/M
acOS/etc/gui/scripts/g.extension.py", line 817, in main
install_extension()
  File "/Applications/GRASS_6.4.3/GRASS-6.4.3.app/Contents/M
acOS/etc/gui/scripts/g.extension.py", line 499, in
install_extension
ret = install_extension_other()
  File "/Applications/GRASS_6.4.3/GRASS-6.4.3.app/Contents/M
acOS/etc/gui/scripts/g.extension.py", line 520, in
install_extension_other
gui_list = list_wxgui_extensions(print_module = False)
  File "/Applications/GRASS_6.4.3/GRASS-6.4.3.app/Contents/M
acOS/etc/gui/scripts/g.extension.py", line 273, in
list_wxgui_extensions
f = urlopen(url)
  File "/System/Library/Frameworks/Python.framework/Versions
/2.6/lib/python2.6/urllib2.py", line 126, in urlopen
return _opener.open(url, data, timeout)
  File "/System/Library/Frameworks/Python.framework/Versions
/2.6/lib/python2.6/urllib2.py", line 397, in open
response = meth(req, response)
  File "/System/Library/Frameworks/Python.framework/Versions
/2.6/lib/python2.6/urllib2.py", line 510, in http_response
'http', request, response, code, msg, hdrs)
  File "/System/Library/Frameworks/Python.framework/Versions
/2.6/lib/python2.6/urllib2.py", line 435, in error
return self._call_chain(*args)
  File "/System/Library/Frameworks/Python.framework/Versions
/2.6/lib/python2.6/urllib2.py", line 369, in _call_chain
result = func(*args)
  File "/System/Library/Frameworks/Python.framework/Versions
/2.6/lib/python2.6/urllib2.py", line 518, in
http_error_default
raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 404: Not Found

 
I tried adding on r.stream.distance as well but I am getting a similar error. 
Any suggestions?

Thank you,

BÜLENT 



___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.stream.* addons issue

[Ralf Schäfer]

Dear Bulent

g.extension does not work on Mac to my knowledge.
There is a detailed description of an alternative how to build modules on Mac 
using a few lines in the Shell.
If you install GRASS from kyngchaos, he provides a description in a readme file.
http://www.kyngchaos.com/software/grass
I do not know whether this description is compatible with the installation from 
Michael Barton.

Best regards
Ralf
 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.stream.* addons issue

[Bulent Arikan]

Thank you Ralf!

BÜLENT 



On Oct 18, 2013, at 11:21 PM, Ralf Schäfer  wrote:

> Dear Bulent
> 
> g.extension does not work on Mac to my knowledge.
> There is a detailed description of an alternative how to build modules on Mac 
> using a few lines in the Shell.
> If you install GRASS from kyngchaos, he provides a description in a readme 
> file.
> http://www.kyngchaos.com/software/grass
> I do not know whether this description is compatible with the installation 
> from Michael Barton.
> 
> Best regards
> Ralf

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.stream.* addons issue

[William Kyngesburye]

Actually, I think g.extension should work now, I forgot to update the readme.  
I haven't tried it from the GUI, or installing system-wide.

On Oct 18, 2013, at 3:36 PM, Bulent Arikan wrote:

> Thank you Ralf!
> 
> BÜLENT 
> 
> 
> 
> On Oct 18, 2013, at 11:21 PM, Ralf Schäfer  wrote:
> 
>> Dear Bulent
>> 
>> g.extension does not work on Mac to my knowledge.
>> There is a detailed description of an alternative how to build modules on 
>> Mac using a few lines in the Shell.
>> If you install GRASS from kyngchaos, he provides a description in a readme 
>> file.
>> http://www.kyngchaos.com/software/grass
>> I do not know whether this description is compatible with the installation 
>> from Michael Barton.
>> 
>> Best regards
>> Ralf
> 
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user

-
William Kyngesburye 
http://www.kyngchaos.com/

Theory of the Universe

There is a theory which states that if ever anyone discovers exactly what the 
universe is for and why it is here, it will instantly disappear and be replaced 
by something even more bizarrely inexplicable.  There is another theory which 
states that this has already happened.

-Hitchhiker's Guide to the Galaxy 2nd season intro


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.stream.* addons issue

[Bulent Arikan]

Unfortunately, it still does not work. I downloaded the stable version of Grass 
from your website and I am having the same issue. Meanwhile, I am trying to 
remember an old trick I learned from a friend. I saved the .html file as a 
plain text file and dropped it into the Scripts folder in Contents>MacOS. I 
used to type a command starting with 'chmod' to make that plain text file a 
Unix executable file. It worked in the past for several addons.

BÜLENT 



On Oct 19, 2013, at 1:39 AM, William Kyngesburye  wrote:

> Actually, I think g.extension should work now, I forgot to update the readme. 
>  I haven't tried it from the GUI, or installing system-wide.
> 
> On Oct 18, 2013, at 3:36 PM, Bulent Arikan wrote:
> 
>> Thank you Ralf!
>> 
>> BÜLENT 
>> 
>> 
>> 
>> On Oct 18, 2013, at 11:21 PM, Ralf Schäfer  wrote:
>> 
>>> Dear Bulent
>>> 
>>> g.extension does not work on Mac to my knowledge.
>>> There is a detailed description of an alternative how to build modules on 
>>> Mac using a few lines in the Shell.
>>> If you install GRASS from kyngchaos, he provides a description in a readme 
>>> file.
>>> http://www.kyngchaos.com/software/grass
>>> I do not know whether this description is compatible with the installation 
>>> from Michael Barton.
>>> 
>>> Best regards
>>> Ralf
>> 
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
> 
> -
> William Kyngesburye 
> http://www.kyngchaos.com/
> 
> Theory of the Universe
> 
> There is a theory which states that if ever anyone discovers exactly what the 
> universe is for and why it is here, it will instantly disappear and be 
> replaced by something even more bizarrely inexplicable.  There is another 
> theory which states that this has already happened.
> 
> -Hitchhiker's Guide to the Galaxy 2nd season intro
> 
> 

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.stream.* addons issue

[William Kyngesburye]

On Oct 18, 2013, at 9:50 PM, Bulent Arikan wrote:

> Unfortunately, it still does not work. I downloaded the stable version of 
> Grass from your website and I am having the same issue.

Like I said, I haven't tried it from the GUI.  It's different code (python) 
than the CLI version (shell script), so maybe something isn't working right in 
python.  Try running g.extension in the GRASS Terminal, not from the GUI.  
Works fine for me in the default GRASS_ADDON_PATH prefix (not global).

It is not recommended to install globally on OS X, that's the GRASS.app.  
Mainly, it's just not the Mac way to add something to an existing application.  
Global installation on OS X should be the /Library/GRASS addons folder, but I 
don't think there is a default behavior in g.extension for that yet.  You woud 
have to manually specify the prefix and make sure you are logged in as an 
administrator user (both the -s and -u flags force the prefix to be the GRASS 
app).

Something like:

g.extension ext=r.stream.basins prefix=/Library/GRASS/6.4/Modules

> Meanwhile, I am trying to remember an old trick I learned from a friend. I 
> saved the .html file as a plain text file and dropped it into the Scripts 
> folder in Contents>MacOS. I used to type a command starting with 'chmod' to 
> make that plain text file a Unix executable file. It worked in the past for 
> several addons.
> 
That sounds dangerous - making html executable, anything could happen if there 
was some valid script code in the html.

> BÜLENT 
> 
> 
> 
> On Oct 19, 2013, at 1:39 AM, William Kyngesburye  
> wrote:
> 
>> Actually, I think g.extension should work now, I forgot to update the 
>> readme.  I haven't tried it from the GUI, or installing system-wide.
>> 
>> On Oct 18, 2013, at 3:36 PM, Bulent Arikan wrote:
>> 
>>> Thank you Ralf!
>>> 
>>> BÜLENT 
>>> 
>>> 
>>> 
>>> On Oct 18, 2013, at 11:21 PM, Ralf Schäfer  wrote:
>>> 
 Dear Bulent
 
 g.extension does not work on Mac to my knowledge.
 There is a detailed description of an alternative how to build modules on 
 Mac using a few lines in the Shell.
 If you install GRASS from kyngchaos, he provides a description in a readme 
 file.
 http://www.kyngchaos.com/software/grass
 I do not know whether this description is compatible with the installation 
 from Michael Barton.
 
 Best regards
 Ralf
>>> 
>>> ___
>>> grass-user mailing list
>>> grass-user@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-user
>> 
>> -
>> William Kyngesburye 
>> http://www.kyngchaos.com/
>> 
>> Theory of the Universe
>> 
>> There is a theory which states that if ever anyone discovers exactly what 
>> the universe is for and why it is here, it will instantly disappear and be 
>> replaced by something even more bizarrely inexplicable.  There is another 
>> theory which states that this has already happened.
>> 
>> -Hitchhiker's Guide to the Galaxy 2nd season intro
>> 
>> 
> 
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user

-
William Kyngesburye 
http://www.kyngchaos.com/

"Mon Dieu! but they are all alike.  Cheating, murdering, lying, fighting, and 
all for things that the beasts of the jungle would not deign to possess - money 
to purchase the effeminate pleasures of weaklings.  And yet withal bound down 
by silly customs that make them slaves to their unhappy lot while firm in the 
belief that they be the lords of creation enjoying the only real pleasures of 
existence

- the wisdom of Tarzan


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.stream.* addons issue

[Bulent Arikan]

Thanks William!

BÜLENT 



On Oct 19, 2013, at 6:23 AM, William Kyngesburye  wrote:

> On Oct 18, 2013, at 9:50 PM, Bulent Arikan wrote:
> 
>> Unfortunately, it still does not work. I downloaded the stable version of 
>> Grass from your website and I am having the same issue.
> 
> Like I said, I haven't tried it from the GUI.  It's different code (python) 
> than the CLI version (shell script), so maybe something isn't working right 
> in python.  Try running g.extension in the GRASS Terminal, not from the GUI.  
> Works fine for me in the default GRASS_ADDON_PATH prefix (not global).
> 
> It is not recommended to install globally on OS X, that's the GRASS.app.  
> Mainly, it's just not the Mac way to add something to an existing 
> application.  Global installation on OS X should be the /Library/GRASS addons 
> folder, but I don't think there is a default behavior in g.extension for that 
> yet.  You woud have to manually specify the prefix and make sure you are 
> logged in as an administrator user (both the -s and -u flags force the prefix 
> to be the GRASS app).
> 
> Something like:
> 
> g.extension ext=r.stream.basins prefix=/Library/GRASS/6.4/Modules
> 
>> Meanwhile, I am trying to remember an old trick I learned from a friend. I 
>> saved the .html file as a plain text file and dropped it into the Scripts 
>> folder in Contents>MacOS. I used to type a command starting with 'chmod' to 
>> make that plain text file a Unix executable file. It worked in the past for 
>> several addons.
>> 
> That sounds dangerous - making html executable, anything could happen if 
> there was some valid script code in the html.
> 
>> BÜLENT 
>> 
>> 
>> 
>> On Oct 19, 2013, at 1:39 AM, William Kyngesburye  
>> wrote:
>> 
>>> Actually, I think g.extension should work now, I forgot to update the 
>>> readme.  I haven't tried it from the GUI, or installing system-wide.
>>> 
>>> On Oct 18, 2013, at 3:36 PM, Bulent Arikan wrote:
>>> 
 Thank you Ralf!
 
 BÜLENT 
 
 
 
 On Oct 18, 2013, at 11:21 PM, Ralf Schäfer  
 wrote:
 
> Dear Bulent
> 
> g.extension does not work on Mac to my knowledge.
> There is a detailed description of an alternative how to build modules on 
> Mac using a few lines in the Shell.
> If you install GRASS from kyngchaos, he provides a description in a 
> readme file.
> http://www.kyngchaos.com/software/grass
> I do not know whether this description is compatible with the 
> installation from Michael Barton.
> 
> Best regards
> Ralf
 
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user
>>> 
>>> -
>>> William Kyngesburye 
>>> http://www.kyngchaos.com/
>>> 
>>> Theory of the Universe
>>> 
>>> There is a theory which states that if ever anyone discovers exactly what 
>>> the universe is for and why it is here, it will instantly disappear and be 
>>> replaced by something even more bizarrely inexplicable.  There is another 
>>> theory which states that this has already happened.
>>> 
>>> -Hitchhiker's Guide to the Galaxy 2nd season intro
>>> 
>>> 
>> 
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
> 
> -
> William Kyngesburye 
> http://www.kyngchaos.com/
> 
> "Mon Dieu! but they are all alike.  Cheating, murdering, lying, fighting, and 
> all for things that the beasts of the jungle would not deign to possess - 
> money to purchase the effeminate pleasures of weaklings.  And yet withal 
> bound down by silly customs that make them slaves to their unhappy lot while 
> firm in the belief that they be the lords of creation enjoying the only real 
> pleasures of existence
> 
> - the wisdom of Tarzan
> 
> 

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] i.landsat.toar comments have only 0 value

[Markus Neteler]

On Thu, Oct 17, 2013 at 11:00 PM, Daniel Victoria
 wrote:
> Updating my last email. I also see the same problem in WinGrass 6.4.3
>
> And on a similar topic, i.landsat.toar in Grass6 has one extra
> correction method when compared with Grass7.
> In grass6 there is a Corrected at-sensor values options which I don't
> see in Grass7. Why is that?


Both versions are currently not completely in sync (GRASS 7 lagging
behind since Jorge develops for G6).
Hope that gets fixed soon.

Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user