[GRASS-dev] data catalog question

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

Hi Anna,

2016-04-10 5:00 GMT+02:00 Anna Petrášová <kratochanna@gmail.com>:

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.

I would suggest to keep traditional approach at least by default. What
about new option in preferences? In the same way I was thinking about
GUI option "Set up computational region automatically from input
data". Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

Hi Anna:
I can think of at least two configuration policies that could (should?) be different on a single user installation vs. a multi user system: Both mapset access, and installation of extensions -

SIngle user: unlimited access to all mapsets as you mention in the data catalog, and installation of extensions in the user’s .grassrc directory (as is now the case)

Multi-user setup: maintain the current “access to owner only” policy, but allow installation of extensions to some system directory so everyone can use all extensions. Installing extensions with sudo doesn’t work unless root has a full GRASSDBASE directory setup. How can that be overcome so that the GRASS admin can easily install extensions system-wide?

Thanks,
Micha

···

On 10/04/2016 06: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-user@lists.osgeo.org](mailto:grass-user@lists.osgeo.org)
[http://lists.osgeo.org/mailman/listinfo/grass-user](http://lists.osgeo.org/mailman/listinfo/grass-user)
This mail was received via Mail-SeCure System.

Micha Silver
Arava Drainage Authority
+972-523-665918

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 <backup> 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 <backup> 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 <backup> 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-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

On Tue, Apr 12, 2016 at 10:52 AM, Paulo van Breugel
<p.vanbreugel@gmail.com> 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 <backup> 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 <backup> 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 <backup> 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-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

On Tue, Apr 12, 2016 at 10:52 AM, Paulo van Breugel
<p.vanbreugel@gmail.com> 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 <backup> 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-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

On Tue, Apr 12, 2016 at 2:21 PM, Paulo van Breugel
<p.vanbreugel@gmail.com> wrote:

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

On Tue, Apr 12, 2016 at 10:52 AM, Paulo van Breugel
<p.vanbreugel@gmail.com> 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 <backup> 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-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

On Tue, Apr 12, 2016 at 2:29 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

On Tue, Apr 12, 2016 at 2:21 PM, Paulo van Breugel
<p.vanbreugel@gmail.com> wrote:

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

On Tue, Apr 12, 2016 at 10:52 AM, Paulo van Breugel
<p.vanbreugel@gmail.com> 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 <backup> 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-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

When I have a mapset with space, e.g., ‘Dispersal backup’, and I open for the first time the data tab in the main GUI, grass tries to look for a mapset ‘Dispersal’ and a mapset ‘backup’ (underlined below). Note that there also was a real mapset ‘Dispersal’, not sure if that makes a difference. When unlocking (clicking the lock), there is not context menu anymore at right click. From the command line:

···

On 13-04-16 05:24, Anna Petrášová wrote:

On Tue, Apr 12, 2016 at 2:29 PM, Anna Petrášová [<kratochanna@gmail.com>](mailto:kratochanna@gmail.com) wrote:

On Tue, Apr 12, 2016 at 2:21 PM, Paulo van Breugel
[<p.vanbreugel@gmail.com>](mailto:p.vanbreugel@gmail.com) wrote:

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

On Tue, Apr 12, 2016 at 10:52 AM, Paulo van Breugel
[<p.vanbreugel@gmail.com>](mailto:p.vanbreugel@gmail.com) 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 <backup> 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...
D1/5: grass.script.core.start_command(): g.list --q -mt type=raster,raster_3d,vector mapset=ConsStat,Dispersal,Dispersal,backup,EthiopiaJvdS,GeneticDistance,JvdS,LUCC,PERMANENT,climchange,samplesize


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...
GRASS 7.1.svn (nc_spm_08_grass7):~ > Traceback (most recent call last):
  File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/gui_core/treeview.py", line 58, in <lambda>
    self._emitSignal(evt.GetItem(), self.contextMenu))
  File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/gui_core/treeview.py", line 161, in _emitSignal
    signal.emit(node=node, **kwargs)
  File "/usr/local/grass7/grass-7.1.svn/etc/python/grass/pydispatch/signal.py", line 229, in emit
    dispatcher.send(signal=self, *args, **kwargs)
  File "/usr/local/grass7/grass-7.1.svn/etc/python/grass/pydispatch/dispatcher.py", line 349, in send
    **named
  File "/usr/local/grass7/grass-7.1.svn/etc/python/grass/pydispatch/robustapply.py", line 60, in robustApply
    return receiver(*arguments, **named)
  File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/datacatalog/tree.py", line 363, in OnRightClick
    self._popupMenuLayer()
  File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/datacatalog/tree.py", line 725, in _popupMenuLayer
    self.selected_location.label == genv['LOCATION_NAME']:
UnboundLocalError: local variable 'genv' referenced before assignment
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-user@lists.osgeo.org](mailto:grass-user@lists.osgeo.org)
[http://lists.osgeo.org/mailman/listinfo/grass-user](http://lists.osgeo.org/mailman/listinfo/grass-user)



On Wed, Apr 13, 2016 at 2:43 AM, Paulo van Breugel
<p.vanbreugel@gmail.com> wrote:

On 13-04-16 05:24, Anna Petrášová wrote:

On Tue, Apr 12, 2016 at 2:29 PM, Anna Petrášová <kratochanna@gmail.com>
wrote:

On Tue, Apr 12, 2016 at 2:21 PM, Paulo van Breugel
<p.vanbreugel@gmail.com> wrote:

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

On Tue, Apr 12, 2016 at 10:52 AM, Paulo van Breugel
<p.vanbreugel@gmail.com> 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 <backup> 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...

When I have a mapset with space, e.g., 'Dispersal backup', and I open for
the first time the data tab in the main GUI, grass tries to look for a
mapset 'Dispersal' and a mapset 'backup' (underlined below). Note that there
also was a real mapset 'Dispersal', not sure if that makes a difference.

D1/5: grass.script.core.start_command(): g.list --q -mt
type=raster,raster_3d,vector
mapset=ConsStat,Dispersal,Dispersal,backup,EthiopiaJvdS,GeneticDistance,JvdS,LUCC,PERMANENT,climchange,samplesize

I fixed that, now it will list the maps in the mapsets correctly.

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

When unlocking (clicking the lock), there is not context menu anymore at
right click. From the command line:

Fixed, thanks

GRASS 7.1.svn (nc_spm_08_grass7):~ > Traceback (most recent call last):

  File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/gui_core/treeview.py",
line 58, in <lambda>

    self._emitSignal(evt.GetItem(), self.contextMenu))

  File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/gui_core/treeview.py",
line 161, in _emitSignal

    signal.emit(node=node, **kwargs)

  File
"/usr/local/grass7/grass-7.1.svn/etc/python/grass/pydispatch/signal.py",
line 229, in emit

    dispatcher.send(signal=self, *args, **kwargs)

  File
"/usr/local/grass7/grass-7.1.svn/etc/python/grass/pydispatch/dispatcher.py",
line 349, in send

    **named

  File
"/usr/local/grass7/grass-7.1.svn/etc/python/grass/pydispatch/robustapply.py",
line 60, in robustApply

    return receiver(*arguments, **named)

  File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/datacatalog/tree.py",
line 363, in OnRightClick

    self._popupMenuLayer()

  File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/datacatalog/tree.py",
line 725, in _popupMenuLayer

    self.selected_location.label == genv['LOCATION_NAME']:

UnboundLocalError: local variable 'genv' referenced before assignment

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-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

On 13-04-16 15:27, Anna Petrášová wrote:

On Wed, Apr 13, 2016 at 2:43 AM, Paulo van Breugel
<p.vanbreugel@gmail.com> wrote:

On 13-04-16 05:24, Anna Petrášová wrote:

On Tue, Apr 12, 2016 at 2:29 PM, Anna Petrášová <kratochanna@gmail.com>
wrote:

On Tue, Apr 12, 2016 at 2:21 PM, Paulo van Breugel
<p.vanbreugel@gmail.com> wrote:

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

On Tue, Apr 12, 2016 at 10:52 AM, Paulo van Breugel
<p.vanbreugel@gmail.com> 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 <backup> 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...

When I have a mapset with space, e.g., 'Dispersal backup', and I open for
the first time the data tab in the main GUI, grass tries to look for a
mapset 'Dispersal' and a mapset 'backup' (underlined below). Note that there
also was a real mapset 'Dispersal', not sure if that makes a difference.

D1/5: grass.script.core.start_command(): g.list --q -mt
type=raster,raster_3d,vector
mapset=ConsStat,Dispersal,Dispersal,backup,EthiopiaJvdS,GeneticDistance,JvdS,LUCC,PERMANENT,climchange,samplesize

I fixed that, now it will list the maps in the mapsets correctly.

Hi, copying, renaming and displaying works great in the current location. I can also copy and paste layers between mapsets of another location. I cannot, however, copy maps from another location to the current location/mapset. The context menu shows the copy option, and in the status bar (or whatever you call the area with message at the bottom) there is the message that the layer can be copied into the current mapset. However, the 'paste' option is greyed out when right clicking on the current mapset.

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

When unlocking (clicking the lock), there is not context menu anymore at
right click. From the command line:

Fixed, thanks

GRASS 7.1.svn (nc_spm_08_grass7):~ > Traceback (most recent call last):

   File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/gui_core/treeview.py",
line 58, in <lambda>

     self._emitSignal(evt.GetItem(), self.contextMenu))

   File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/gui_core/treeview.py",
line 161, in _emitSignal

     signal.emit(node=node, **kwargs)

   File
"/usr/local/grass7/grass-7.1.svn/etc/python/grass/pydispatch/signal.py",
line 229, in emit

     dispatcher.send(signal=self, *args, **kwargs)

   File
"/usr/local/grass7/grass-7.1.svn/etc/python/grass/pydispatch/dispatcher.py",
line 349, in send

     **named

   File
"/usr/local/grass7/grass-7.1.svn/etc/python/grass/pydispatch/robustapply.py",
line 60, in robustApply

     return receiver(*arguments, **named)

   File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/datacatalog/tree.py",
line 363, in OnRightClick

     self._popupMenuLayer()

   File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/datacatalog/tree.py",
line 725, in _popupMenuLayer

     self.selected_location.label == genv['LOCATION_NAME']:

UnboundLocalError: local variable 'genv' referenced before assignment

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-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

On Wed, Apr 13, 2016 at 11:31 AM, Paulo van Breugel
<p.vanbreugel@gmail.com> wrote:

On 13-04-16 15:27, Anna Petrášová wrote:

On Wed, Apr 13, 2016 at 2:43 AM, Paulo van Breugel
<p.vanbreugel@gmail.com> wrote:

On 13-04-16 05:24, Anna Petrášová wrote:

On Tue, Apr 12, 2016 at 2:29 PM, Anna Petrášová <kratochanna@gmail.com>
wrote:

On Tue, Apr 12, 2016 at 2:21 PM, Paulo van Breugel
<p.vanbreugel@gmail.com> wrote:

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

On Tue, Apr 12, 2016 at 10:52 AM, Paulo van Breugel
<p.vanbreugel@gmail.com> 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 <backup> 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...

When I have a mapset with space, e.g., 'Dispersal backup', and I open for
the first time the data tab in the main GUI, grass tries to look for a
mapset 'Dispersal' and a mapset 'backup' (underlined below). Note that
there
also was a real mapset 'Dispersal', not sure if that makes a difference.

D1/5: grass.script.core.start_command(): g.list --q -mt
type=raster,raster_3d,vector

mapset=ConsStat,Dispersal,Dispersal,backup,EthiopiaJvdS,GeneticDistance,JvdS,LUCC,PERMANENT,climchange,samplesize

I fixed that, now it will list the maps in the mapsets correctly.

Hi, copying, renaming and displaying works great in the current location. I
can also copy and paste layers between mapsets of another location. I
cannot, however, copy maps from another location to the current
location/mapset. The context menu shows the copy option, and in the status
bar (or whatever you call the area with message at the bottom) there is the
message that the layer can be copied into the current mapset. However, the
'paste' option is greyed out when right clicking on the current mapset.

Yes, that's how it is supposed to work now. We don't have reprojection
between mapsets from different locations implemented there yet, that's
why it doesn't allow it. Once this is implemented, the options will
work. We could warn user about it, but I hope we can add the necessary
functionality there soon.

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

When unlocking (clicking the lock), there is not context menu anymore at
right click. From the command line:

Fixed, thanks

GRASS 7.1.svn (nc_spm_08_grass7):~ > Traceback (most recent call last):

   File
"/usr/local/grass7/grass-7.1.svn/gui/wxpython/gui_core/treeview.py",
line 58, in <lambda>

     self._emitSignal(evt.GetItem(), self.contextMenu))

   File
"/usr/local/grass7/grass-7.1.svn/gui/wxpython/gui_core/treeview.py",
line 161, in _emitSignal

     signal.emit(node=node, **kwargs)

   File
"/usr/local/grass7/grass-7.1.svn/etc/python/grass/pydispatch/signal.py",
line 229, in emit

     dispatcher.send(signal=self, *args, **kwargs)

   File

"/usr/local/grass7/grass-7.1.svn/etc/python/grass/pydispatch/dispatcher.py",
line 349, in send

     **named

   File

"/usr/local/grass7/grass-7.1.svn/etc/python/grass/pydispatch/robustapply.py",
line 60, in robustApply

     return receiver(*arguments, **named)

   File
"/usr/local/grass7/grass-7.1.svn/gui/wxpython/datacatalog/tree.py",
line 363, in OnRightClick

     self._popupMenuLayer()

   File
"/usr/local/grass7/grass-7.1.svn/gui/wxpython/datacatalog/tree.py",
line 725, in _popupMenuLayer

     self.selected_location.label == genv['LOCATION_NAME']:

UnboundLocalError: local variable 'genv' referenced before assignment

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-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

On Wed, Apr 13, 2016 at 5:35 PM, Anna Petrášová <kratochanna@gmail.com>
wrote:

On Wed, Apr 13, 2016 at 11:31 AM, Paulo van Breugel
<p.vanbreugel@gmail.com> wrote:
>
>
> On 13-04-16 15:27, Anna Petrášová wrote:
>>
>> On Wed, Apr 13, 2016 at 2:43 AM, Paulo van Breugel
>> <p.vanbreugel@gmail.com> wrote:
>>>
>>>
>>> On 13-04-16 05:24, Anna Petrášová wrote:
>>>
>>> On Tue, Apr 12, 2016 at 2:29 PM, Anna Petrášová <kratochanna@gmail.com
>
>>> wrote:
>>>
>>> On Tue, Apr 12, 2016 at 2:21 PM, Paulo van Breugel
>>> <p.vanbreugel@gmail.com> wrote:
>>>
>>> On 12-04-16 18:21, Anna Petrášová wrote:
>>>
>>> On Tue, Apr 12, 2016 at 10:52 AM, Paulo van Breugel
>>> <p.vanbreugel@gmail.com> 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 <backup> 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...
>>>
>>>
>>> When I have a mapset with space, e.g., 'Dispersal backup', and I open
for
>>> the first time the data tab in the main GUI, grass tries to look for a
>>> mapset 'Dispersal' and a mapset 'backup' (underlined below). Note that
>>> there
>>> also was a real mapset 'Dispersal', not sure if that makes a
difference.
>>>
>>> D1/5: grass.script.core.start_command(): g.list --q -mt
>>> type=raster,raster_3d,vector
>>>
>>>
mapset=ConsStat,Dispersal,Dispersal,backup,EthiopiaJvdS,GeneticDistance,JvdS,LUCC,PERMANENT,climchange,samplesize
>>
>> I fixed that, now it will list the maps in the mapsets correctly.
>
> Hi, copying, renaming and displaying works great in the current
location. I
> can also copy and paste layers between mapsets of another location. I
> cannot, however, copy maps from another location to the current
> location/mapset. The context menu shows the copy option, and in the
status
> bar (or whatever you call the area with message at the bottom) there is
the
> message that the layer can be copied into the current mapset. However,
the
> 'paste' option is greyed out when right clicking on the current mapset.
>

Yes, that's how it is supposed to work now. We don't have reprojection
between mapsets from different locations implemented there yet, that's
why it doesn't allow it. Once this is implemented, the options will
work. We could warn user about it, but I hope we can add the necessary
functionality there soon.

OK, that means the message in the bottom is wrong for now, but will be
correct soon :-). In any case, I really like this functionality. I never
think about using the data catalog, but I can see that changing now.

>
>>>
>>>
>>>
>>> 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...
>>>
>>>
>>> When unlocking (clicking the lock), there is not context menu anymore
at
>>> right click. From the command line:
>>
>>
>> Fixed, thanks
>>
>>> GRASS 7.1.svn (nc_spm_08_grass7):~ > Traceback (most recent call last):
>>>
>>> File
>>> "/usr/local/grass7/grass-7.1.svn/gui/wxpython/gui_core/treeview.py",
>>> line 58, in <lambda>
>>>
>>> self._emitSignal(evt.GetItem(), self.contextMenu))
>>>
>>> File
>>> "/usr/local/grass7/grass-7.1.svn/gui/wxpython/gui_core/treeview.py",
>>> line 161, in _emitSignal
>>>
>>> signal.emit(node=node, **kwargs)
>>>
>>> File
>>>
"/usr/local/grass7/grass-7.1.svn/etc/python/grass/pydispatch/signal.py",
>>> line 229, in emit
>>>
>>> dispatcher.send(signal=self, *args, **kwargs)
>>>
>>> File
>>>
>>>
"/usr/local/grass7/grass-7.1.svn/etc/python/grass/pydispatch/dispatcher.py",
>>> line 349, in send
>>>
>>> **named
>>>
>>> File
>>>
>>>
"/usr/local/grass7/grass-7.1.svn/etc/python/grass/pydispatch/robustapply.py",
>>> line 60, in robustApply
>>>
>>> return receiver(*arguments, **named)
>>>
>>> File
>>> "/usr/local/grass7/grass-7.1.svn/gui/wxpython/datacatalog/tree.py",
>>> line 363, in OnRightClick
>>>
>>> self._popupMenuLayer()
>>>
>>> File
>>> "/usr/local/grass7/grass-7.1.svn/gui/wxpython/datacatalog/tree.py",
>>> line 725, in _popupMenuLayer
>>>
>>> self.selected_location.label == genv['LOCATION_NAME']:
>>>
>>> UnboundLocalError: local variable 'genv' referenced before assignment
>>>
>>>
>>>
>>>
>>> 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-user@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>>
>>>
>