date:20160412

On Tue, Apr 12, 2016 at 2:29 PM, Anna Petrášová  wrote:
> On Tue, Apr 12, 2016 at 2:21 PM, Paulo van Breugel
>  wrote:
>>
>> On 12-04-16 18:21, Anna Petrášová wrote:
>>>
>>> On Tue, Apr 12, 2016 at 10:52 AM, Paulo van Breugel
>>>  wrote:

 Hi Anna

 I just updated GRASS trunk version (GRASS GIS 7.1.svn r68252) to test the
 data catalogue. However, when opening the data tab in the main GUI, after
 some waiting, the GUI crashes with:

 GRASS_INFO_ERROR(30614,1): Mapset  does not exist
>>>
>>> this error comes from g.list mapset=backup ...
>>>
>>> and 'backup' comes from running 'g.mapsets -l' for each location.
>>> Could you run it in the problematic location? Do you get then
>>> 'backup'? Also you can try to switch on debug mode.
>>
>> Found the problem. In one of the locations I had a copy of a mapset folder
>> 'Dispersal' which I named 'Dispersal backup', so it is the space in the name
>> of the second one that caused the problem.
>
> I'll try to reproduce it and see if it can be handle this situation better
>>
>>>
>>> I don't know what the rest of the errors mean. If you find the
>>> problem, I can try to reproduce it.
>>>
>>> Anna

Weird, I created a mapset with space in the name and everything works...

>>>
 On 10-04-16 05:00, Anna Petrášová wrote:
>
> Hi,
>
> I was wondering what is the opinion about the new data catalog (in
> trunk), specifically, whether users should be able to modify (copy,
> rename, delete) maps from other mapsets and locations than the current
> ones.
>>
>> So now I could try out the new functionality. I can display or copy maps
>> from other mapsets, but only if in the same location. If I am in another
>> location, there is still the option to display or copy in the context menu
>> (right click), but when selecting copy, there is the error message that
>> "failed to copy: action is allowed only within the same mapset". When
>> selecting 'display', the message is "failed to display:  not in current
>> mapset or invalid layer".
>
> sorry, I still haven't committed it yet, I haven't added the option to
> change it from settings yet, I'll try to add it later today...

I committed the changes, please test...

Anna

>
>>
>>
>>
> I find it very useful to edit any mapsets, but it goes against
> the traditional GRASS approach. I have this (edit anything behavior)
> implemented locally, but wanted to know before committing if people
> agree with that.
>
> Thanks,
> Anna
> ___
> grass-user mailing list
> grass-u...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user


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

Re: [GRASS-dev] [GRASS GIS] #2799: wxGUI: display toolbar size too large

#2799: wxGUI: display toolbar size too large
--+---
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.4
 Component:  wxGUI|Version:  svn-releasebranch70
Resolution:   |   Keywords:  wxGUI, size, toolbar, mapdisp
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by wenzeslaus):

 Possibly related: r68229

--
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 GIS] #2876: r.sun (mode 1): data are not timestamped correctly

On Tue, Apr 12, 2016 at 3:59 PM, Markus Neteler  wrote:
> On Tue, Apr 12, 2016 at 4:55 PM, Markus Neteler  wrote:
>> On Tue, Apr 12, 2016 at 12:08 AM, Thomas Huld  wrote:
>>> Markus,
>>>
>>> The two patches do the same thing, change the sign of the correction of the
>>> time according to the equation. I thought my version (#2941) was a bit
>>> clearer. The only other difference is the line number to which the patch is
>>> applied, #2876 is for GRASS 6.4.x, #2941 for GRASS 7.0.x.
>>>
>>> Does this make it clearer?
>
> Yes. In order to make progress here and close the issues, I have
> applied the patches as suggested in the respective tickets:
>
> * r68253 in releasebranch_6_4 from #2876
> * r68254 (relbranch70) and r68255 (trunk = 7.12.svn).

Just wondering, do we have any idea how much this changes the results?

Anna

>
> thanks to the contributors,
> Markus
>
>
> --
> Markus Neteler
> http://www.mundialis.de
> http://courses.neteler.org/blog/
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2876: r.sun (mode 1): data are not timestamped correctly

On Tue, Apr 12, 2016 at 4:55 PM, Markus Neteler  wrote:
> On Tue, Apr 12, 2016 at 12:08 AM, Thomas Huld  wrote:
>> Markus,
>>
>> The two patches do the same thing, change the sign of the correction of the
>> time according to the equation. I thought my version (#2941) was a bit
>> clearer. The only other difference is the line number to which the patch is
>> applied, #2876 is for GRASS 6.4.x, #2941 for GRASS 7.0.x.
>>
>> Does this make it clearer?

Yes. In order to make progress here and close the issues, I have
applied the patches as suggested in the respective tickets:

* r68253 in releasebranch_6_4 from #2876
* r68254 (relbranch70) and r68255 (trunk = 7.12.svn).

thanks to the contributors,
Markus


-- 
Markus Neteler
http://www.mundialis.de
http://courses.neteler.org/blog/
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2941: r.sun: wrong sign in equation of time

#2941: r.sun: wrong sign in equation of time
--+-
  Reporter:  tomhuld  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.0.4
 Component:  Raster   |Version:  svn-releasebranch70
Resolution:  fixed|   Keywords:  r.sun
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by neteler):

 * status:  new => closed
 * version:  unspecified => svn-releasebranch70
 * resolution:   => fixed


Comment:

 Thanks for the patch, applied in r68254 (relbranch70) and r68255 (trunk).

 Compare also the equivalent alternative GRASS GIS 7 fix suggested in #2876
 (commented on in cited email in https://lists.osgeo.org/pipermail/grass-
 dev/2016-April/079789.html).

 Closing.

--
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 GIS] #2876: r.sun (mode 1): data are not timestamped correctly

#2876: r.sun (mode 1): data are not timestamped correctly
-+-
  Reporter:  fabriziosossan  |  Owner:  grass-dev@…
  Type:  defect  | Status:  closed
  Priority:  normal  |  Milestone:  7.0.4
 Component:  Raster  |Version:  6.4.5
Resolution:  fixed   |   Keywords:  r.sun
   CPU:  x86-64  |   Platform:  Linux
-+-
Changes (by neteler):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Thanks for testing r.sun and the patch, applied in r68253 in
 releasebranch_6_4.

 Compare also the equivalent alternative GRASS GIS 7 fix suggested in #2941
 (commented on in cited email in
 https://lists.osgeo.org/pipermail/grass-dev/2016-April/079789.html).

 Closing.

--
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 GIS] #2876: r.sun (mode 1): data are not timestamped correctly

On Tue, Apr 12, 2016 at 2:56 PM, Vaclav Petras  wrote:
> On Tue, Apr 12, 2016 at 8:47 AM, Thomas Huld  wrote:
>>
>> The time zone is +1 for Central Europe.
>
> Is somebody willing to contribute a table for the manual with examples of
> time zones and values needed?

Do you mean something like this?
https://en.wikipedia.org/wiki/List_of_UTC_time_offsets
https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

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

Re: [GRASS-dev] [GRASS-user] data catalog question

On Tue, Apr 12, 2016 at 2:21 PM, Paulo van Breugel
 wrote:
>
> On 12-04-16 18:21, Anna Petrášová wrote:
>>
>> On Tue, Apr 12, 2016 at 10:52 AM, Paulo van Breugel
>>  wrote:
>>>
>>> Hi Anna
>>>
>>> I just updated GRASS trunk version (GRASS GIS 7.1.svn r68252) to test the
>>> data catalogue. However, when opening the data tab in the main GUI, after
>>> some waiting, the GUI crashes with:
>>>
>>> GRASS_INFO_ERROR(30614,1): Mapset  does not exist
>>
>> this error comes from g.list mapset=backup ...
>>
>> and 'backup' comes from running 'g.mapsets -l' for each location.
>> Could you run it in the problematic location? Do you get then
>> 'backup'? Also you can try to switch on debug mode.
>
> Found the problem. In one of the locations I had a copy of a mapset folder
> 'Dispersal' which I named 'Dispersal backup', so it is the space in the name
> of the second one that caused the problem.

I'll try to reproduce it and see if it can be handle this situation better
>
>>
>> I don't know what the rest of the errors mean. If you find the
>> problem, I can try to reproduce it.
>>
>> Anna
>>
>>> On 10-04-16 05:00, Anna Petrášová wrote:

 Hi,

 I was wondering what is the opinion about the new data catalog (in
 trunk), specifically, whether users should be able to modify (copy,
 rename, delete) maps from other mapsets and locations than the current
 ones.
>
> So now I could try out the new functionality. I can display or copy maps
> from other mapsets, but only if in the same location. If I am in another
> location, there is still the option to display or copy in the context menu
> (right click), but when selecting copy, there is the error message that
> "failed to copy: action is allowed only within the same mapset". When
> selecting 'display', the message is "failed to display:  not in current
> mapset or invalid layer".

sorry, I still haven't committed it yet, I haven't added the option to
change it from settings yet, I'll try to add it later today...

>
>
>
 I find it very useful to edit any mapsets, but it goes against
 the traditional GRASS approach. I have this (edit anything behavior)
 implemented locally, but wanted to know before committing if people
 agree with that.

 Thanks,
 Anna
 ___
 grass-user mailing list
 grass-u...@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user
>>>
>>>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] data catalog question

2016-04-12 Thread Paulo van Breugel



On 12-04-16 18:21, Anna Petrášová wrote:

On Tue, Apr 12, 2016 at 10:52 AM, Paulo van Breugel
 wrote:

Hi Anna

I just updated GRASS trunk version (GRASS GIS 7.1.svn r68252) to test the
data catalogue. However, when opening the data tab in the main GUI, after
some waiting, the GUI crashes with:

GRASS_INFO_ERROR(30614,1): Mapset  does not exist

this error comes from g.list mapset=backup ...

and 'backup' comes from running 'g.mapsets -l' for each location.
Could you run it in the problematic location? Do you get then
'backup'? Also you can try to switch on debug mode.
Found the problem. In one of the locations I had a copy of a mapset 
folder 'Dispersal' which I named 'Dispersal backup', so it is the space 
in the name of the second one that caused the problem.




I don't know what the rest of the errors mean. If you find the
problem, I can try to reproduce it.

Anna


On 10-04-16 05:00, Anna Petrášová wrote:

Hi,

I was wondering what is the opinion about the new data catalog (in
trunk), specifically, whether users should be able to modify (copy,
rename, delete) maps from other mapsets and locations than the current
ones.
So now I could try out the new functionality. I can display or copy maps 
from other mapsets, but only if in the same location. If I am in another 
location, there is still the option to display or copy in the context 
menu (right click), but when selecting copy, there is the error message 
that "failed to copy: action is allowed only within the same mapset". 
When selecting 'display', the message is "failed to display:  not in 
current mapset or invalid layer".




I find it very useful to edit any mapsets, but it goes against
the traditional GRASS approach. I have this (edit anything behavior)
implemented locally, but wanted to know before committing if people
agree with that.

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




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

Re: [GRASS-dev] [GRASS-user] data catalog question

On Tue, Apr 12, 2016 at 10:52 AM, Paulo van Breugel
 wrote:
> Hi Anna
>
> I just updated GRASS trunk version (GRASS GIS 7.1.svn r68252) to test the
> data catalogue. However, when opening the data tab in the main GUI, after
> some waiting, the GUI crashes with:
>
> GRASS_INFO_ERROR(30614,1): Mapset  does not exist

this error comes from g.list mapset=backup ...

and 'backup' comes from running 'g.mapsets -l' for each location.
Could you run it in the problematic location? Do you get then
'backup'? Also you can try to switch on debug mode.

I don't know what the rest of the errors mean. If you find the
problem, I can try to reproduce it.

Anna

>
> GRASS_INFO_END(30614,1)
>
> python: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
>
>
> There was indeed a reference to a non-existing backup mapset in one of the
> SEARCH_PATH files, but also after removing that reference, I am getting the
> same crash with message (below), which makes me wonder where else to look
> for a reference to an non-existing mapset.
>
> GRASS_INFO_ERROR(32753,1): Mapset  does not exist
>
> GRASS_INFO_END(32753,1)
>
> python: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
>
>
> I tried it again, and got a slightly different message:
>
> GRASS_INFO_ERROR(31864,1): Mapset  does not exist
>
> GRASS_INFO_END(31864,1)
>
> python: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
>
> Xlib: request 54 length 8 would exceed buffer size.
>
>
> and yet another time, with the message below, which does not seem terribly
> helpful, but I am copying anyway.
>
> GRASS_INFO_END(32455,1)
>
> The program 'python' received an X Window System error.
>
> This probably reflects a bug in the program.
>
> The error was 'BadLength (poly request too large or internal Xlib length
> erro'.
>
>   (Details: serial 15786 error_code 16 request_code 139 minor_code 4)
>
>   (Note to programmers: normally, X errors are reported asynchronously;
>
>that is, you will receive the error a while after causing it.
>
>To debug your program, run it with the --sync command line
>
>option to change this behavior. You can then get a meaningful
>
>backtrace from your debugger if you break on the gdk_x_error() function.)
>
> The program 'python' received an X Window System error.
>
> This probably reflects a bug in the program.
>
> The error was 'BadLength (poly request too large or internal Xlib length
> erro'.
>
>   (Details: serial 15795 error_code 16 request_code 130 minor_code 0)
>
>   (Note to programmers: normally, X errors are reported asynchronously;
>
>that is, you will receive the error a while after causing it.
>
>To debug your program, run it with the --sync command line
>
>option to change this behavior. You can then get a meaningful
>
>backtrace from your debugger if you break on the gdk_x_error() function.)
>
>
>
>
>
> On 10-04-16 05:00, Anna Petrášová wrote:
>>
>> Hi,
>>
>> I was wondering what is the opinion about the new data catalog (in
>> trunk), specifically, whether users should be able to modify (copy,
>> rename, delete) maps from other mapsets and locations than the current
>> ones. I find it very useful to edit any mapsets, but it goes against
>> the traditional GRASS approach. I have this (edit anything behavior)
>> implemented locally, but wanted to know before committing if people
>> agree with that.
>>
>> Thanks,
>> Anna
>> ___
>> grass-user mailing list
>> grass-u...@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: Re: [GRASS-SVN] r68240 - grass/trunk/scripts/v.report

2016-04-12 Thread Huidae Cho

I don't think we have a consensus yet...

-- 
Sent from my phone
On Apr 12, 2016 11:01 AM, "Markus Neteler"  wrote:

> On Mon, Apr 11, 2016 at 3:57 PM, Huidae Cho  wrote:
> ...
> > 11 scripts use \r\n and 5 use os.linesep. g.extension uses \r\n for
> reading
> > and os.linesep for printing.
>
> Any volunteer to homogenize that?
>
> thanks
> Markus
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: Re: [GRASS-SVN] r68240 - grass/trunk/scripts/v.report

On Mon, Apr 11, 2016 at 3:57 PM, Huidae Cho  wrote:
...
> 11 scripts use \r\n and 5 use os.linesep. g.extension uses \r\n for reading
> and os.linesep for printing.

Any volunteer to homogenize that?

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

Re: [GRASS-dev] [GRASS GIS] #2876: r.sun (mode 1): data are not timestamped correctly

On Tue, Apr 12, 2016 at 12:08 AM, Thomas Huld  wrote:
> Markus,
>
> The two patches do the same thing, change the sign of the correction of the
> time according to the equation. I thought my version (#2941) was a bit
> clearer. The only other difference is the line number to which the patch is
> applied, #2876 is for GRASS 6.4.x, #2941 for GRASS 7.0.x.
>
> Does this make it clearer?
>
> Cheers,
>
> Thomas


Thanks, Thomas. We shall decide now based on your comment.

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

Re: [GRASS-dev] [GRASS-user] data catalog question

2016-04-12 Thread Paulo van Breugel


Hi Anna

I just updated GRASS trunk version (GRASS GIS 7.1.svn r68252) to test 
the data catalogue. However, when opening the data tab in the main GUI, 
after some waiting, the GUI crashes with:


GRASS_INFO_ERROR(30614,1): Mapset  does not exist

GRASS_INFO_END(30614,1)

python: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.


There was indeed a reference to a non-existing backup mapset in one of 
the SEARCH_PATH files, but also after removing that reference, I am 
getting the same crash with message (below), which makes me wonder where 
else to look for a reference to an non-existing mapset.


GRASS_INFO_ERROR(32753,1): Mapset  does not exist

GRASS_INFO_END(32753,1)

python: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.


I tried it again, and got a slightly different message:

GRASS_INFO_ERROR(31864,1): Mapset  does not exist

GRASS_INFO_END(31864,1)

python: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.

Xlib: request 54 length 8 would exceed buffer size.


and yet another time, with the message below, which does not seem 
terribly helpful, but I am copying anyway.


GRASS_INFO_END(32455,1)

The program 'python' received an X Window System error.

This probably reflects a bug in the program.

The error was 'BadLength (poly request too large or internal Xlib length erro'.

  (Details: serial 15786 error_code 16 request_code 139 minor_code 4)

  (Note to programmers: normally, X errors are reported asynchronously;

   that is, you will receive the error a while after causing it.

   To debug your program, run it with the --sync command line

   option to change this behavior. You can then get a meaningful

   backtrace from your debugger if you break on the gdk_x_error() function.)

The program 'python' received an X Window System error.

This probably reflects a bug in the program.

The error was 'BadLength (poly request too large or internal Xlib length erro'.

  (Details: serial 15795 error_code 16 request_code 130 minor_code 0)

  (Note to programmers: normally, X errors are reported asynchronously;

   that is, you will receive the error a while after causing it.

   To debug your program, run it with the --sync command line

   option to change this behavior. You can then get a meaningful

   backtrace from your debugger if you break on the gdk_x_error() function.)




On 10-04-16 05:00, Anna Petrášová wrote:

Hi,

I was wondering what is the opinion about the new data catalog (in
trunk), specifically, whether users should be able to modify (copy,
rename, delete) maps from other mapsets and locations than the current
ones. I find it very useful to edit any mapsets, but it goes against
the traditional GRASS approach. I have this (edit anything behavior)
implemented locally, but wanted to know before committing if people
agree with that.

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


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

Re: [GRASS-dev] [GRASS GIS] #2928: query tool does not work in wx display

#2928: query tool does not work in wx display
-+-
  Reporter:  veroandreo  |  Owner:  grass-dev@…
  Type:  defect  | Status:  closed
  Priority:  normal  |  Milestone:  7.1.0
 Component:  wxGUI   |Version:  svn-trunk
Resolution:  fixed   |   Keywords:  query tool
   CPU:  x86-64  |   Platform:  Linux
-+-
Changes (by annakrat):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Replying to [comment:3 veroandreo]:
 > Thanks, Anna! Works fine now both using d.mon and the main map display
 in the GUI. However, in both cases, the first time I click over the
 displayed map, I still get this message in the terminal:
 >
 > {{{
 > (main.py:9791): Gtk-CRITICAL **: gtk_widget_set_size_request: assertion
 'height >= -1' failed
 > }}}

 Thanks. The gtk error is unrelated and I think harmless.

--
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 GIS] #2876: r.sun (mode 1): data are not timestamped correctly

2016-04-12 Thread Vaclav Petras

On Tue, Apr 12, 2016 at 8:47 AM, Thomas Huld  wrote:

> The time zone is +1 for Central Europe.



Is somebody willing to contribute a table for the manual with examples of
time zones and values needed?
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2876: r.sun (mode 1): data are not timestamped correctly

2016-04-12 Thread Thomas Huld

Hi Lorenzo,

The time zone is +1 for Central Europe.

Cheers,

Thomas



On Tue, Apr 12, 2016 at 9:39 AM, Lorenzo Bottaccioli <
lorenzo.bottacci...@gmail.com> wrote:

> Hi all,
>
> I'm interested on this issue. Now I'm working on grass 7.0.3 if I want to
> set civili time of Central Europe which sign shall I use +1 or -1.
>
> Tnx
>
> Lorenzo
>
> 2016-04-11 23:15 GMT+02:00 Markus Neteler :
>
>> Thomas,
>>
>> On Tue, Apr 5, 2016 at 8:55 PM, Thomas Huld 
>> wrote:
>> > I presume that by "backport" you mean port of this fix to GRASS7?
>>
>> Yes, to fix 7.0.x.
>>
>> > On 28 February I reported bug #2941 with a suggested patch to Grass 7 to
>> > cover this. Since I'm not a regular contributor, I don't really know
>> what
>> > has happened to it?
>>
>> So far nothing because it is unclear to me (as written in the ticket).
>>
>> > It's just a one-liner, so maybe it would be safest if one of the
>> regulars
>> > would apply the patch?
>>
>> Shall I apply one of them or both?
>> https://trac.osgeo.org/grass/ticket/2876
>> https://trac.osgeo.org/grass/ticket/2941
>>
>> or does the second also include the first? Please let me know,
>>
>> Markus
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] creating temporary mapsets in a parallelized python script

2016-04-12 Thread Moritz Lennert

On 12/04/16 11:29, Helmut Kudrnovsky wrote:

wenzeslaus wrote

On Mon, Apr 11, 2016 at 5:19 PM, Helmut Kudrnovsky

hellik@

wrote:

I see, then it's easier to fix the script and use grass.use_temp_region

From the manual:

script.core.use_temp_region()[source]¶
Copies the current region to a temporary region with “g.region save=”,
then
sets WIND_OVERRIDE to refer to that region. Installs an atexit handler to
delete the temporary region upon termination.

Does this function mean that: while concurrent r.basin runs on different
CPUs in the same mapset, there is no interefering by region settings
change
interefering?

Setting WIND_OVERRIDE (environmental variable) will happen for the current
process, so it won't affect other processes only subprocess which is
desired. (In your case, this won't work if you would use this function
outside of r.basin.) So yes, parallel processes (including g.region) won't
see WIND_OVERRIDE, so they will see and use the original computational
region.

The documentation describes just what happens in the background but not
the
usage. Feel free to update that with your understanding.

Generally, use_temp_region should be used by any module which calls
g.region.

Vaclav

thanks for the hints and clarifications.

are there examples of the correct use of script.core.use_temp_region()
around?

https://grasswiki.osgeo.org/wiki/GRASS_Python_Scripting_Library#Using_temporary_region_for_computations

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

Re: [GRASS-dev] creating temporary mapsets in a parallelized python script

2016-04-12 Thread Helmut Kudrnovsky

wenzeslaus wrote
> On Mon, Apr 11, 2016 at 5:19 PM, Helmut Kudrnovsky 

> hellik@

>  wrote:
> 
>> > I see, then it's easier to fix the script and use grass.use_temp_region
>>
>> From the manual:
>>
>> script.core.use_temp_region()[source]¶
>> Copies the current region to a temporary region with “g.region save=”,
>> then
>> sets WIND_OVERRIDE to refer to that region. Installs an atexit handler to
>> delete the temporary region upon termination.
>>
>> Does this function mean that: while concurrent r.basin runs on different
>> CPUs in the same mapset, there is no interefering by region settings
>> change
>> interefering?
>>
> 
> Setting WIND_OVERRIDE (environmental variable) will happen for the current
> process, so it won't affect other processes only subprocess which is
> desired. (In your case, this won't work if you would use this function
> outside of r.basin.) So yes, parallel processes (including g.region) won't
> see WIND_OVERRIDE, so they will see and use the original computational
> region.
> 
> The documentation describes just what happens in the background but not
> the
> usage. Feel free to update that with your understanding.
> 
> Generally, use_temp_region should be used by any module which calls
> g.region.
> 
> Vaclav

thanks for the hints and clarifications.

are there examples of the correct use of script.core.use_temp_region()
around?

I've found it in [1]:

124 # clone current region
125 grass.use_temp_region()
126 
127 grass.run_command('g.region', res=panres, align=pan)

anything else to do?

[1]
https://trac.osgeo.org/grass/browser/grass/trunk/scripts/i.pansharpen/i.pansharpen.py#L124

thanks



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/creating-temporary-mapsets-in-a-parallelized-python-script-tp5260753p5260826.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

Re: [GRASS-dev] [GRASS GIS] #2903: v.edit break bug with multiple coordinates