Re: [GRASS-dev] FW: FW: OSGeo-SoC 2016 application

[Yang, Bo (yangb2)]

Dear Moritz,

Thank you for the reply, and thanks you and Markus could be the mentor of the 
i.segment project! There are only two days left for submitting the proposal, 
take into consideration I think I need to switch to the topic of i.segment 
project now. For my cokriging fusion topic I think I could do it after this 
summer in the future work. 
I've read the source code and Eric's wiki of GSoC 2012 [0]. I think I will 
prepare the proposal following the direction of adding new algorithms to 
segment an image into objects-- more than region-growing algorithm. Moritz, you 
mentioned segmentation algorithm: mean-shift, split-window and watershed. I 
think some unsupervised classification algorithms would also be possible such 
as: dynamic thresholding and markov random field (MRF). If you think it is OK, 
I will start the preparing the draft of proposal from now on, and I think I 
could have the first version send back to you by tomorrow (Thursday). If you 
have any suggestions and comments please let me know.
Thanks again to both you and Luca for your guidance and patient. 

Best wishes,
Bo Yang

[0] https://grasswiki.osgeo.org/wiki/GRASS_GSoC_2012_Image_Segmentation


-Original Message-
From: Moritz Lennert [mailto:mlenn...@club.worldonline.be] 
Sent: Wednesday, March 23, 2016 10:12 AM
To: Yang, Bo (yangb2) 
Cc: Luca Delucchi ; grass-dev@lists.osgeo.org; Markus 
Metz 
Subject: Re: [GRASS-dev] FW: FW: OSGeo-SoC 2016 application

Le Wed, 23 Mar 2016 09:09:06 +0100,
Luca Delucchi  a écrit :

> On 23 March 2016 at 05:04, Yang, Bo (yangb2) 
> wrote:
> > Dear Luca,
> >  
> 
> Dear Bo,
> 
> > Last weekend I've tried using my computer checking out the source 
> > codes and compiled the GRASS in the windows OS environment [0]. In 
> > addition, I've studied both t.rast.gapfill and r.series.interp 
> > modules. I think that it would be possible to add an interpolation 
> > method because it currently supports only linear interpolation. I 
> > think it would be a good idea to add Kriging/cokriging to the 
> > interpolation methods since it is a wide used rater interpolation 
> > algorithm. Although Kriging/cokriging computational time is 
> > significantly longer than the traditional linear method, it 
> > completes the gap filling process within a reasonable period with 
> > much better fusion results, especially for some heterogeneous 
> > region. If you think it is OK, I can prepare the proposal follow 
> > this direction (it is due this Friday).
> 
> I think you should start the proposal, because there is no so much 
> time
> 
> > However, I've got the reply from Soeren (see below). He said he 
> > can't mentor the project due to too busy this year. Do you have any 
> > other person in mind to recommend as mentor? Or are you available 
> > for  mentoring this project? Please advise. Thank you for being 
> > patient and helping me.
> 
> I have no enough C skills to be the first mentor, I could be the 
> co-mentor (for testing, helping you with t.rast.gapfill and adding 
> tests). Is someone else interested to be mentor?

As mentioned privately, I'm only available, like you, as co-mentor for testing 
and applied advice, not so much on the coding side.

In light of the absence of mentors, you might want to reconsider the choice of 
topics. For i.segment, Markus Metz is willing to deal with the C-side and I 
mentor for the rest.

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

Re: [GRASS-dev] [GRASS-SVN] r68127 - grass/trunk/lib/gis

[Huidae Cho]

I partly agree with you, but I think at least there should be consistency
in the same file. Those two options had 4 spaces, but others have tabs or 8
spaces. Well, there is still inconsistency... Why don't we use the indent
script for all files?

On Wed, Mar 23, 2016 at 11:52 PM, Vaclav Petras 
wrote:

>
> On Wed, Mar 23, 2016 at 11:29 PM, Huidae Cho  wrote:
>
>> Vaclav, that script completely removes tabs and I didn't want to
>> introduce a big revision for no reason other than changing those two
>> options to match the rest of the file.
>
>
>
> I think there is no need to do that. There is a lot of files in the source
> code which do not comply with any (!) version of the indent script. If you
> want the file to be consistent, why not to be consistent with the script
> and actually use it? If inconsistencies with Submitting guidelines are OK,
> why change anything? Perhaps it will turn into the new style itself in time
> if we won't be reverting it back. We can also say that we actually want
> everything to be consistent and do that big change.
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r68127 - grass/trunk/lib/gis

[Vaclav Petras]

On Wed, Mar 23, 2016 at 11:29 PM, Huidae Cho  wrote:

> Vaclav, that script completely removes tabs and I didn't want to introduce
> a big revision for no reason other than changing those two options to match
> the rest of the file.



I think there is no need to do that. There is a lot of files in the source
code which do not comply with any (!) version of the indent script. If you
want the file to be consistent, why not to be consistent with the script
and actually use it? If inconsistencies with Submitting guidelines are OK,
why change anything? Perhaps it will turn into the new style itself in time
if we won't be reverting it back. We can also say that we actually want
everything to be consistent and do that big change.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2967: [PATCH] Super quiet mode

[GRASS GIS]

#2967: [PATCH] Super quiet mode
--+-
  Reporter:  rouault  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.1.0
 Component:  Parser   |Version:  svn-trunk
Resolution:   |   Keywords:  patch
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by wenzeslaus):

 * keywords:   => patch
 * version:  unspecified => svn-trunk
 * component:  Default => Parser
 * milestone:  7.0.4 => 7.1.0


Comment:

 Replying to [comment:3 mlennert]:
 > Replying to [ticket:2967 rouault]:
 > > The attached proposed patch adds a --qq option for a super verbose
 mode that suppress everything but fatal warnings.
 >
 > Thanks for the patch. I'm often annoyed by the same issue. I've
 committed your patch to trunk in r68092 for further testing.

 `--qq` doesn't fit into the idea of shortening options/flags:

 {{{
 --verbose --v
 --quiet   --q
 }}}

 This is applied automatically to the module options (e.g. `input` versus
 `in`) and although I'm not sure what is the mechanism for the long
 (standard/common) flags I think the general rules should be the same. So
 now --q is little ambiguous as it can stand for `--quiet` or `--qq`.
 Leaving aside that `--qq` doesn't have the long or short version.

 I suggest to use `--xquiet` (X as in XS and XL). But perhaps there might
 be an way without letter X.

 Please, make also some suggestions on how Python API should be extended,
 that's an important part of this change.

 I tested the following

 {{{
 g.region -p --qq --verbose
 }}}

 and it goes though without any warning. I think the code disables warnings
 and then gives a warning.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS-SVN] r68127 - grass/trunk/lib/gis

[Huidae Cho]

Vaclav, that script completely removes tabs and I didn't want to introduce
a big revision for no reason other than changing those two options to match
the rest of the file.

On Wed, Mar 23, 2016 at 10:59 PM, Vaclav Petras 
wrote:

>
> On Wed, Mar 23, 2016 at 5:29 PM,  wrote:
>
>> Author: hcho
>> Date: 2016-03-23 14:29:40 -0700 (Wed, 23 Mar 2016)
>> New Revision: 68127
>>
>> Modified:
>>grass/trunk/lib/gis/parser_standard_options.c
>> Log:
>> parser: Fix indentation
>>
>>
> Please, see:
>
> https://trac.osgeo.org/grass/browser/grass/trunk/tools/grass_indent.sh
> https://trac.osgeo.org/grass/wiki/Submitting/C#Indentation
>
>
>> Modified: grass/trunk/lib/gis/parser_standard_options.c
>> ===
>> --- grass/trunk/lib/gis/parser_standard_options.c   2016-03-23
>> 19:54:16 UTC (rev 68126)
>> +++ grass/trunk/lib/gis/parser_standard_options.c   2016-03-23
>> 21:29:40 UTC (rev 68127)
>> @@ -659,26 +659,26 @@
>> break;
>>
>>  case G_OPT_M_LOCATION:
>> -Opt->key = "location";
>> -Opt->type = TYPE_STRING;
>> -Opt->required = NO;
>> -Opt->multiple = NO;
>> -Opt->label = _("Location name");
>> -Opt->description = _("Location name (not location path)");
>> -Opt->gisprompt = "old,location,location";
>> -Opt->key_desc = "name";
>> -break;
>> +   Opt->key = "location";
>> +   Opt->type = TYPE_STRING;
>> +   Opt->required = NO;
>> +   Opt->multiple = NO;
>> +   Opt->label = _("Location name");
>> +   Opt->description = _("Location name (not location path)");
>> +   Opt->gisprompt = "old,location,location";
>> +   Opt->key_desc = "name";
>> +   break;
>>
>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r68127 - grass/trunk/lib/gis

[Vaclav Petras]

On Wed, Mar 23, 2016 at 5:29 PM,  wrote:

> Author: hcho
> Date: 2016-03-23 14:29:40 -0700 (Wed, 23 Mar 2016)
> New Revision: 68127
>
> Modified:
>grass/trunk/lib/gis/parser_standard_options.c
> Log:
> parser: Fix indentation
>
>
Please, see:

https://trac.osgeo.org/grass/browser/grass/trunk/tools/grass_indent.sh
https://trac.osgeo.org/grass/wiki/Submitting/C#Indentation


> Modified: grass/trunk/lib/gis/parser_standard_options.c
> ===
> --- grass/trunk/lib/gis/parser_standard_options.c   2016-03-23
> 19:54:16 UTC (rev 68126)
> +++ grass/trunk/lib/gis/parser_standard_options.c   2016-03-23
> 21:29:40 UTC (rev 68127)
> @@ -659,26 +659,26 @@
> break;
>
>  case G_OPT_M_LOCATION:
> -Opt->key = "location";
> -Opt->type = TYPE_STRING;
> -Opt->required = NO;
> -Opt->multiple = NO;
> -Opt->label = _("Location name");
> -Opt->description = _("Location name (not location path)");
> -Opt->gisprompt = "old,location,location";
> -Opt->key_desc = "name";
> -break;
> +   Opt->key = "location";
> +   Opt->type = TYPE_STRING;
> +   Opt->required = NO;
> +   Opt->multiple = NO;
> +   Opt->label = _("Location name");
> +   Opt->description = _("Location name (not location path)");
> +   Opt->gisprompt = "old,location,location";
> +   Opt->key_desc = "name";
> +   break;
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PEP 394 - The "python" Command on Unix-Like Systems

[Luca Delucchi]

On 13 March 2016 at 10:52, Maris Nartiss  wrote:
> I personally would like to see adoption of PEP8 and moving all python
> code to be python3 ready. As old python versions are dying out, there
> is less and less initiative to not do so.
> Also related to
> https://lists.osgeo.org/pipermail/grass-dev/2016-February/078828.html
>

I also have the same feeling, we should work to be python3 ready,
maybe we could release 7.2 and start to work on it

> Māris.
>

my2cents

-- 
ciao
Luca

www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] GRASS 7.0.3 for El Capitan without disabling SIP!

[Michael Barton]

As William and I said, the problem is linked to making binaries that involve 
packaging certain dependencies, like wxPython. If you compile it yourself, it 
may well not be a problem.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu















On Mar 23, 2016, at 11:30 AM, 
grass-dev-requ...@lists.osgeo.org 
wrote:

From: Carlos Grohmann 
>
Subject: Re: [GRASS-dev] [GRASS-user] GRASS 7.0.3 for El Capitan without 
disabling SIP!
Date: March 23, 2016 at 11:29:25 AM EDT
To: Rainer M Krug >
Cc: GRASS user list 
>, grass-dev 
>


I just tested the new brew recipe and it compiles fine. I had to set these to 
get wxgui working:

export GRASS_PYTHON=/usr/local/bin/pythonw
export PYTHONPATH=/usr/local/lib/python2.7/site-packages:$PYTHONPATH


Carlos



On Wed, Mar 23, 2016 at 8:06 AM, Rainer M Krug 
> wrote:

Hi

I just received the news, that the new homebrew recipe for GRASS 7.0
does install on El Capitan with SIP enabled!

This is thanks to Larry Shaffer.

See
https://github.com/OSGeo/homebrew-osgeo4mac/issues/118#issuecomment-200278686

The recipe is part of the Homebrew-osgeo4mac tap, see
https://github.com/OSGeo/homebrew-osgeo4mac
for info on how to use them.

I will see that I can port the changes to my grass-71 formula as well -
will keep you posted when it works.

Thanks a lot Larry,

Rainer

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 
44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982

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



--
Prof. Carlos Henrique Grohmann
Institute of Energy and Environment - Univ. of São Paulo, Brazil
- Digital Terrain Analysis | GIS | Remote Sensing -

http://carlosgrohmann.com
http://orcid.org/-0001-5073-5572

Can’t stop the signal.


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

Re: [GRASS-dev] r.rgb: syntax error, unexpected $end, expecting VARNAME or NAME or STRING

[Markus Neteler]

On Wed, Mar 23, 2016 at 3:50 PM, Vaclav Petras  wrote:
> On Wed, Mar 23, 2016 at 6:44 AM, Markus Neteler  wrote:
>>
>> On Tue, Mar 22, 2016 at 10:37 PM, Markus Metz
>>  wrote:
>> > On Fri, Mar 18, 2016 at 3:10 PM, Markus Neteler 
>> > wrote:
>> ...
>>  GRASS 7.1.svn (nc_spm_08_grass7): > r.rgb input=elevation
>> ...
>> > Is there any reason why this should not work? According to the manual
>> > it should work.
>> >
>> > If neither red or green or blue are given, r.rgb could use
>> > red=${input}.r
>> > green=${input}.g
>> > blue=${input}.b
>>
>> Yes, this would exactly be the user's expectation (at least mine as a
>> user) who has even read the manual :)
>
>
> I though you expected that the names are not generated inside the module
> since you changed the manual according to my commit (r68072) and backported
> both commits.

Yes, to get rid of this behaviour:

GRASS 7.1.svn (nc_spm_08_grass7): > r.rgb input=elevation
syntax error, unexpected $end, expecting VARNAME or NAME or STRING
Parse error
ERROR: parse error
ERROR: An error occurred while running r.mapcalc

Still the requirement to write 3 times almost the same output name is not ideal.

> I like the current state. Perhaps not so convenient when advanced users work
> in the command line but in all other cases it requires you to be explicit,
> thus better for beginners (who don't have to guess the new name) and the GUI
> (wxGUI can automatically show the new maps only when they are specified in
> the command line).

I see. Too bad that I also like the command line :-)

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

Re: [GRASS-dev] r.regression.multi failing

[Vaclav Petras]

On Wed, Mar 23, 2016 at 11:57 AM, Markus Metz  wrote:

>
> > Now this is treated as an error
> > (ERROR: Multiple regression failed"), which I guess is the equivalent of
> > grass.error() in a python script? Perhaps it would be possible to
> provide a
> > warning instead, and give an output that can be captured, like NA for the
> > coefficient estimates, instead of breaking of the function?
>
> Instead of grass.run_command(), you can use
>
> ps = grass.start_command()
> returncode = ps.wait()
>
> returncode is zero if the module finished successfully, non-zero if an
> error occurred, easy to capture in a script.



I don't know if the called module behavior is but or if it should be
improved somehow. Anyway, the way to deal with subprocess failure when
using GRASS Python API is to use try-except. You can also get run_command
to behave the same as in 6.4 version of the API using errors parameter:

returncode = run_command('g.region', ..., errors='status')

Other possible values are raise, ignore and exit. raise is the default and
it raises a CalledModuleError exception. Note that the exception is the
default because that's how the errors are handled in Python and it works
well also for read_command() which returns the module stdout by value.
There are different *_command() functions to conveniently cover different
cases. The most general is start_command() which is used similarly to the
underlying Popen.

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

Re: [GRASS-dev] [GRASS GIS] #2969: r.series: wrong usage of weights

[GRASS GIS]

#2969: r.series: wrong usage of weights
--+---
  Reporter:  mmetz|  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.4
 Component:  Raster   |Version:  7.0.3
Resolution:   |   Keywords:  r.series, weights
   CPU:  Unspecified  |   Platform:  All
--+---

Comment (by mmetz):

 Fixed in r68124,5 (trunk, relbr70).

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] r.regression.multi failing

[Paulo van Breugel]

On Wed, Mar 23, 2016 at 4:57 PM, Markus Metz 
wrote:

> On Wed, Mar 23, 2016 at 4:43 PM, Paulo van Breugel
>  wrote:
> >
> >
> > On 23-03-16 16:21, Moritz Lennert wrote:
> >>
> >> Le Wed, 23 Mar 2016 15:55:40 +0100,
> >> Paulo van Breugel  a écrit :
> >>
> >>> On 23-03-16 15:24, Anna Petrášová wrote:
> 
>  On Wed, Mar 23, 2016 at 10:01 AM, Luca Delucchi
>   wrote:
> >
> > On 23 March 2016 at 14:31, Paulo van Breugel
> >  wrote:
> >>
> >> Hi,
> >>
> >
> > Hi,
> >
> >>
> >> I am using r.regression.multi in a python script (using
> >> grass.run_command()) to compute the variance inflation factor
> >> (VIF).  It runs in a loop, regressing variables one by one to all
> >> the other variables. It sometimes happen that the function fails
> >> with:
> >>
> >> WARNING: Matrix is unsolvable
> >> ERROR: Multiple regression failed
> >>
> >> This looks like a clear bug for me. So, even if I understand that you
> >> need to work around it for now, could you also post a bug report with a
> >> reproductible example ?
> >
> > Not sure it is a bug? It happens when amongst the independent variables
> > there are perfectly correlated variables. The message "WARNING: Matrix is
> > unsolvable" therefore seems correct to me.
>
> Yes, this warning should only occur in case of colinearity
>
> > Now this is treated as an error
> > (ERROR: Multiple regression failed"), which I guess is the equivalent of
> > grass.error() in a python script? Perhaps it would be possible to
> provide a
> > warning instead, and give an output that can be captured, like NA for the
> > coefficient estimates, instead of breaking of the function?
>
> Instead of grass.run_command(), you can use
>
> ps = grass.start_command()
> returncode = ps.wait()
>
> returncode is zero if the module finished successfully, non-zero if an
> error occurred, easy to capture in a script.
>

OK, thanks


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

Re: [GRASS-dev] r.regression.multi failing

[Markus Metz]

On Wed, Mar 23, 2016 at 4:43 PM, Paulo van Breugel
 wrote:
>
>
> On 23-03-16 16:21, Moritz Lennert wrote:
>>
>> Le Wed, 23 Mar 2016 15:55:40 +0100,
>> Paulo van Breugel  a écrit :
>>
>>> On 23-03-16 15:24, Anna Petrášová wrote:

 On Wed, Mar 23, 2016 at 10:01 AM, Luca Delucchi
  wrote:
>
> On 23 March 2016 at 14:31, Paulo van Breugel
>  wrote:
>>
>> Hi,
>>
>
> Hi,
>
>>
>> I am using r.regression.multi in a python script (using
>> grass.run_command()) to compute the variance inflation factor
>> (VIF).  It runs in a loop, regressing variables one by one to all
>> the other variables. It sometimes happen that the function fails
>> with:
>>
>> WARNING: Matrix is unsolvable
>> ERROR: Multiple regression failed
>>
>> This looks like a clear bug for me. So, even if I understand that you
>> need to work around it for now, could you also post a bug report with a
>> reproductible example ?
>
> Not sure it is a bug? It happens when amongst the independent variables
> there are perfectly correlated variables. The message "WARNING: Matrix is
> unsolvable" therefore seems correct to me.

Yes, this warning should only occur in case of colinearity

> Now this is treated as an error
> (ERROR: Multiple regression failed"), which I guess is the equivalent of
> grass.error() in a python script? Perhaps it would be possible to provide a
> warning instead, and give an output that can be captured, like NA for the
> coefficient estimates, instead of breaking of the function?

Instead of grass.run_command(), you can use

ps = grass.start_command()
returncode = ps.wait()

returncode is zero if the module finished successfully, non-zero if an
error occurred, easy to capture in a script.

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

Re: [GRASS-dev] r.regression.multi failing

[Paulo van Breugel]

On 23-03-16 16:21, Moritz Lennert wrote:

Le Wed, 23 Mar 2016 15:55:40 +0100,
Paulo van Breugel  a écrit :


On 23-03-16 15:24, Anna Petrášová wrote:

On Wed, Mar 23, 2016 at 10:01 AM, Luca Delucchi
 wrote:

On 23 March 2016 at 14:31, Paulo van Breugel
 wrote:

Hi,
  

Hi,
  

I am using r.regression.multi in a python script (using
grass.run_command()) to compute the variance inflation factor
(VIF).  It runs in a loop, regressing variables one by one to all
the other variables. It sometimes happen that the function fails
with:

WARNING: Matrix is unsolvable
ERROR: Multiple regression failed

This looks like a clear bug for me. So, even if I understand that you
need to work around it for now, could you also post a bug report with a
reproductible example ?
Not sure it is a bug? It happens when amongst the independent variables 
there are perfectly correlated variables. The message "WARNING: Matrix 
is unsolvable" therefore seems correct to me. Now this is treated as an 
error (ERROR: Multiple regression failed"), which I guess is the 
equivalent of grass.error() in a python script? Perhaps it would be 
possible to provide a warning instead, and give an output that can be 
captured, like NA for the coefficient estimates, instead of breaking of 
the function?




Moritz


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

Re: [GRASS-dev] [GRASS-user] GRASS 7.0.3 for El Capitan without disabling SIP!

[Carlos Grohmann]

I just tested the new brew recipe and it compiles fine. I had to set these
to get wxgui working:

export GRASS_PYTHON=/usr/local/bin/pythonw
export PYTHONPATH=/usr/local/lib/python2.7/site-packages:$PYTHONPATH


Carlos



On Wed, Mar 23, 2016 at 8:06 AM, Rainer M Krug  wrote:

>
> Hi
>
> I just received the news, that the new homebrew recipe for GRASS 7.0
> does install on El Capitan with SIP enabled!
>
> This is thanks to Larry Shaffer.
>
> See
>
> https://github.com/OSGeo/homebrew-osgeo4mac/issues/118#issuecomment-200278686
>
> The recipe is part of the Homebrew-osgeo4mac tap, see
> https://github.com/OSGeo/homebrew-osgeo4mac
> for info on how to use them.
>
> I will see that I can port the changes to my grass-71 formula as well -
> will keep you posted when it works.
>
> Thanks a lot Larry,
>
> Rainer
>
> --
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
> Biology, UCT), Dipl. Phys. (Germany)
>
> Centre of Excellence for Invasion Biology
> Stellenbosch University
> South Africa
>
> Tel :   +33 - (0)9 53 10 27 44
> Cell:   +33 - (0)6 85 62 59 98
> Fax :   +33 - (0)9 58 10 27 44
>
> Fax (D):+49 - (0)3 21 21 25 22 44
>
> email:  rai...@krugs.de
>
> Skype:  RMkrug
>
> PGP: 0x0F52F982
>
> ___
> grass-user mailing list
> grass-u...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>



-- 
Prof. Carlos Henrique Grohmann
Institute of Energy and Environment - Univ. of São Paulo, Brazil
- Digital Terrain Analysis | GIS | Remote Sensing -

http://carlosgrohmann.com
http://orcid.org/-0001-5073-5572

Can’t stop the signal.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.regression.multi failing

[Moritz Lennert]

Le Wed, 23 Mar 2016 15:55:40 +0100,
Paulo van Breugel  a écrit :

> On 23-03-16 15:24, Anna Petrášová wrote:
> > On Wed, Mar 23, 2016 at 10:01 AM, Luca Delucchi
> >  wrote:  
> >> On 23 March 2016 at 14:31, Paulo van Breugel
> >>  wrote:  
> >>> Hi,
> >>>  
> >> Hi,
> >>  
> >>> I am using r.regression.multi in a python script (using
> >>> grass.run_command()) to compute the variance inflation factor
> >>> (VIF).  It runs in a loop, regressing variables one by one to all
> >>> the other variables. It sometimes happen that the function fails
> >>> with:
> >>>
> >>> WARNING: Matrix is unsolvable
> >>> ERROR: Multiple regression failed

This looks like a clear bug for me. So, even if I understand that you
need to work around it for now, could you also post a bug report with a
reproductible example ?

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

Re: [GRASS-dev] r.regression.multi failing

[Paulo van Breugel]

On 23-03-16 15:24, Anna Petrášová wrote:

On Wed, Mar 23, 2016 at 10:01 AM, Luca Delucchi  wrote:

On 23 March 2016 at 14:31, Paulo van Breugel  wrote:

Hi,


Hi,


I am using r.regression.multi in a python script (using grass.run_command())
to compute the variance inflation factor (VIF).  It runs in a loop,
regressing variables one by one to all the other variables. It sometimes
happen that the function fails with:

WARNING: Matrix is unsolvable
ERROR: Multiple regression failed

This causes my script to stop. However, I would like to capture this warning
/ error, and continue. Do you know how I can accomplish this?


did you try with try except ?

Yes, specifically:

from grass.exceptions import CalledModuleError

try:
 gscript.run_command(...)
except CalledModuleError:
...

Thanks Luca and Anna, I'll have a look at except and give it a try





Paulo


--
ciao
Luca

www.lucadelu.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] r.rgb: syntax error, unexpected $end, expecting VARNAME or NAME or STRING

[Vaclav Petras]

On Wed, Mar 23, 2016 at 6:44 AM, Markus Neteler  wrote:

> On Tue, Mar 22, 2016 at 10:37 PM, Markus Metz
>  wrote:
> > On Fri, Mar 18, 2016 at 3:10 PM, Markus Neteler 
> wrote:
> ...
>  GRASS 7.1.svn (nc_spm_08_grass7): > r.rgb input=elevation
> ...
> > Is there any reason why this should not work? According to the manual
> > it should work.
> >
> > If neither red or green or blue are given, r.rgb could use
> > red=${input}.r
> > green=${input}.g
> > blue=${input}.b
>
> Yes, this would exactly be the user's expectation (at least mine as a
> user) who has even read the manual :)


I though you expected that the names are not generated inside the module
since you changed the manual according to my commit (r68072) and backported
both commits.

I like the current state. Perhaps not so convenient when advanced users
work in the command line but in all other cases it requires you to be
explicit, thus better for beginners (who don't have to guess the new name)
and the GUI (wxGUI can automatically show the new maps only when they are
specified in the command line).

https://trac.osgeo.org/grass/changeset/68108
https://trac.osgeo.org/grass/changeset/68077
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #2969: r.series: wrong usage of weights

[GRASS GIS]

#2969: r.series: wrong usage of weights
---+-
 Reporter:  mmetz  |  Owner:  grass-dev@…
 Type:  defect | Status:  new
 Priority:  normal |  Milestone:  7.0.4
Component:  Raster |Version:  7.0.3
 Keywords:  r.series, weights  |CPU:  Unspecified
 Platform:  All|
---+-
 A weighted average is calculated with

 {{{
 avg = sum(w[i] * x[i]) / sum(w[i])
 }}}

 r.series calculates weighted averages with
 {{{
 avg = sum(w[i] * x[i]) / count
 }}}

 r.series should instead behave like r.neighbors and use the corresponding
 weighing functions from libstats if available.

 Test commands:
 {{{
 # set the region
 g.region -p n=10 s=0 w=0 e=10 res=1
 # create identical input maps
 r.mapcalc "input1 = 1"
 r.mapcalc "input2 = 1"
 r.mapcalc "input3 = 1"
 r.mapcalc "input4 = 1"
 r.mapcalc "input5 = 1"

 # average
 r.series in=input1,input2,input3,input4,input5 method=average out=avg
 # weighted average
 r.series in=input1,input2,input3,input4,input5 method=average out=avg_w
 weights=0.1,0.2,0.3,0.2,0.1
 }}}

 Without weights the result is 1, with weights the result is 0.18 instead
 of 1. Weights have been added to r.series in r49946. I am going to change
 r.series in trunk and relbr70.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] r.regression.multi failing

[Anna Petrášová]

On Wed, Mar 23, 2016 at 10:01 AM, Luca Delucchi  wrote:
> On 23 March 2016 at 14:31, Paulo van Breugel  wrote:
>> Hi,
>>
>
> Hi,
>
>> I am using r.regression.multi in a python script (using grass.run_command())
>> to compute the variance inflation factor (VIF).  It runs in a loop,
>> regressing variables one by one to all the other variables. It sometimes
>> happen that the function fails with:
>>
>> WARNING: Matrix is unsolvable
>> ERROR: Multiple regression failed
>>
>> This causes my script to stop. However, I would like to capture this warning
>> / error, and continue. Do you know how I can accomplish this?
>>
>
> did you try with try except ?

Yes, specifically:

from grass.exceptions import CalledModuleError

try:
gscript.run_command(...)
except CalledModuleError:
   ...


>
>> Paulo
>>
>
> --
> ciao
> Luca
>
> www.lucadelu.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] FW: FW: OSGeo-SoC 2016 application

[Moritz Lennert]

Le Wed, 23 Mar 2016 09:09:06 +0100,
Luca Delucchi  a écrit :

> On 23 March 2016 at 05:04, Yang, Bo (yangb2) 
> wrote:
> > Dear Luca,
> >  
> 
> Dear Bo,
> 
> > Last weekend I've tried using my computer checking out the source
> > codes and compiled the GRASS in the windows OS environment [0]. In
> > addition, I've studied both t.rast.gapfill and r.series.interp
> > modules. I think that it would be possible to add an interpolation
> > method because it currently supports only linear interpolation. I
> > think it would be a good idea to add Kriging/cokriging to the
> > interpolation methods since it is a wide used rater interpolation
> > algorithm. Although Kriging/cokriging computational time is
> > significantly longer than the traditional linear method, it
> > completes the gap filling process within a reasonable period with
> > much better fusion results, especially for some heterogeneous
> > region. If you think it is OK, I can prepare the proposal follow
> > this direction (it is due this Friday). 
> 
> I think you should start the proposal, because there is no so much
> time
> 
> > However, I've got the reply from Soeren (see below). He said he
> > can't mentor the project due to too busy this year. Do you have any
> > other person in mind to recommend as mentor? Or are you available
> > for  mentoring this project? Please advise. Thank you for being
> > patient and helping me. 
> 
> I have no enough C skills to be the first mentor, I could be the
> co-mentor (for testing, helping you with t.rast.gapfill and adding
> tests). Is someone else interested to be mentor?

As mentioned privately, I'm only available, like you, as co-mentor for
testing and applied advice, not so much on the coding side.

In light of the absence of mentors, you might want to reconsider the
choice of topics. For i.segment, Markus Metz is willing to deal with
the C-side and I mentor for the rest.

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

Re: [GRASS-dev] r.regression.multi failing

[Luca Delucchi]

On 23 March 2016 at 14:31, Paulo van Breugel  wrote:
> Hi,
>

Hi,

> I am using r.regression.multi in a python script (using grass.run_command())
> to compute the variance inflation factor (VIF).  It runs in a loop,
> regressing variables one by one to all the other variables. It sometimes
> happen that the function fails with:
>
> WARNING: Matrix is unsolvable
> ERROR: Multiple regression failed
>
> This causes my script to stop. However, I would like to capture this warning
> / error, and continue. Do you know how I can accomplish this?
>

did you try with try except ?

> Paulo
>

-- 
ciao
Luca

www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] r.regression.multi failing

[Paulo van Breugel]

Hi,

I am using r.regression.multi in a python script (using 
grass.run_command()) to compute the variance inflation factor (VIF).  It 
runs in a loop, regressing variables one by one to all the other 
variables. It sometimes happen that the function fails with:


WARNING: Matrix is unsolvable
ERROR: Multiple regression failed

This causes my script to stop. However, I would like to capture this 
warning / error, and continue. Do you know how I can accomplish this?


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

Re: [GRASS-dev] raster query/r.what error with a r.external-linked raster

[Helmut Kudrnovsky]

wenzeslaus wrote
> On Tue, Mar 22, 2016 at 10:03 AM, Helmut Kudrnovsky 

> hellik@

>  wrote:
> 
>>
>> as I'm not used to compile on Linux, what may be the command to
>> compile with -ggdb? configure? make?
>>
> 
> It is a compiler flag and it can be set using before you run ./configure
> using the CFLAGS environmental variable, so e.g.
> 
> export CFLAGS="-ggdb -Wall"
> ./configure ...
> 
> see full examples here
> 
> https://grasswiki.osgeo.org/wiki/Compile_and_Install_Ubuntu


(gdb) run -rf map=es_l1_1km@bugs coordinates=4395123.966942,2799025.206612
Starting program:
/home/bugs/dev/cpp/grass7_trunk/dist.x86_64-pc-linux-gnu/bin/r.what -rf
map=es_l1_1km@bugs coordinates=4395123.966942,2799025.206612
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x74418090 in vtable for __cxxabiv1::__si_class_type_info ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6

(gdb) bt
#0  0x74418090 in vtable for __cxxabiv1::__si_class_type_info ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x7fffed6778e3 in GDALRegister_VICAR () at vicardataset.cpp:824
#2  0x7fffed494ded in GDALAllRegister () at gdalallregister.cpp:234
#3  0x77bcf6af in Rast_init_gdal () at gdal.c:220
#4  0x77bcf85d in Rast_get_gdal_link (
name=name@entry=0x7ffca990 "es_l1_1km", 
mapset=mapset@entry=0x7ffcaa90 "bugs") at gdal.c:317
#5  0x77bc6d49 in Rast__open_old (name=0x7ffca990 "es_l1_1km", 
mapset=0x7ffcaa90 "bugs") at open.c:272
#6  0x77bc7316 in Rast_open_old (name=, 
mapset=) at open.c:116
#7  0x00401c07 in main (argc=6639232, argv=0x7fffeda9434b)
at main.c:205
(gdb) 

tested with

System Info 
GRASS Version: 7.1.svn  
GRASS SVN revision: 68112   
Build date: 2016-03-23  
Build platform: x86_64-pc-linux-gnu 
GDAL: 2.0.2 
PROJ.4: 4.8.0   
GEOS: 3.4.2 
SQLite: 3.8.7.1 
Python: 2.7.9   
wxPython: 3.0.1.1   
Platform: Linux-3.16.0-4-amd64-x86_64-with-debian-8.3




-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/raster-query-r-what-error-with-a-r-external-linked-raster-tp5256308p5257987.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] GRASS 7.0.3 for El Capitan without disabling SIP!

[Rainer M Krug]

Hi

I just received the news, that the new homebrew recipe for GRASS 7.0
does install on El Capitan with SIP enabled!

This is thanks to Larry Shaffer.

See
https://github.com/OSGeo/homebrew-osgeo4mac/issues/118#issuecomment-200278686

The recipe is part of the Homebrew-osgeo4mac tap, see
https://github.com/OSGeo/homebrew-osgeo4mac
for info on how to use them.

I will see that I can port the changes to my grass-71 formula as well -
will keep you posted when it works.

Thanks a lot Larry,

Rainer

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


signature.asc
Description: PGP signature
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.rgb: syntax error, unexpected $end, expecting VARNAME or NAME or STRING

[Markus Neteler]

On Tue, Mar 22, 2016 at 10:37 PM, Markus Metz
 wrote:
> On Fri, Mar 18, 2016 at 3:10 PM, Markus Neteler  wrote:
...
 GRASS 7.1.svn (nc_spm_08_grass7): > r.rgb input=elevation
...
> Is there any reason why this should not work? According to the manual
> it should work.
>
> If neither red or green or blue are given, r.rgb could use
> red=${input}.r
> green=${input}.g
> blue=${input}.b

Yes, this would exactly be the user's expectation (at least mine as a
user) who has even read the manual :)

markusN

> That would be easy to fix.
>
> Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Addon manual pages offline

[Paulo van Breugel]

On 23-03-16 11:15, Markus Neteler wrote:

On Wed, Mar 23, 2016 at 10:27 AM, Paulo van Breugel
 wrote:

Most manual pages for addons are missing (see also
https://grass.osgeo.org/grass70/manuals/addons/ with only links to few
addons)

 From here it looks all fine, I checked in two browsers.

(Yesterday I added table of content support on that page. Also checked
the result in http://validator.w3.org/ successfully).

Anyone else having issues?


Just as additional info, I checked this morning on my PC and on my phone 
browser, and the pages were not available on both. But having said that, 
the manual pages are back online for me now, so problem (if there was 
any to start with) has been solved.




Markus


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

Re: [GRASS-dev] Addon manual pages offline

[Markus Neteler]

On Wed, Mar 23, 2016 at 10:27 AM, Paulo van Breugel
 wrote:
> Most manual pages for addons are missing (see also
> https://grass.osgeo.org/grass70/manuals/addons/ with only links to few
> addons)

From here it looks all fine, I checked in two browsers.

(Yesterday I added table of content support on that page. Also checked
the result in http://validator.w3.org/ successfully).

Anyone else having issues?

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

[GRASS-dev] Addon manual pages offline

[Paulo van Breugel]

Most manual pages for addons are missing (see also 
https://grass.osgeo.org/grass70/manuals/addons/ with only links to few 
addons)


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

Re: [GRASS-dev] FW: FW: OSGeo-SoC 2016 application

[Luca Delucchi]

On 23 March 2016 at 05:04, Yang, Bo (yangb2)  wrote:
> Dear Luca,
>

Dear Bo,

> Last weekend I've tried using my computer checking out the source codes and 
> compiled the GRASS in the windows OS environment [0]. In addition, I've 
> studied both t.rast.gapfill and r.series.interp modules. I think that it 
> would be possible to add an interpolation method because it currently 
> supports only linear interpolation. I think it would be a good idea to add 
> Kriging/cokriging to the interpolation methods since it is a wide used rater 
> interpolation algorithm. Although Kriging/cokriging computational time is 
> significantly longer than the traditional linear method, it completes the gap 
> filling process within a reasonable period with much better fusion results, 
> especially for some heterogeneous region. If you think it is OK, I can 
> prepare the proposal follow this direction (it is due this Friday).
>

I think you should start the proposal, because there is no so much time

> However, I've got the reply from Soeren (see below). He said he can't mentor 
> the project due to too busy this year. Do you have any other person in mind 
> to recommend as mentor? Or are you available for  mentoring this project? 
> Please advise.
> Thank you for being patient and helping me.
>

I have no enough C skills to be the first mentor, I could be the
co-mentor (for testing, helping you with t.rast.gapfill and adding
tests). Is someone else interested to be mentor?

> Best wishes,
> Bo Yang
>


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