Add rename and delete of Location and Mapset in Datacatalog

[wenzeslaus]

Add Rename and Delete actions to the context menu of Location and Mapset tree items in the Datacatalog (Data tab).

Current items (7.4) in the context menu of Mapset:

• Paste
• Switch mapset

Location does not have any associated actions.

[Nikos Alexandris]

For Mapsets, does this mean that there will be a g.remove mapset option? Or a g.mapset -r? 'r' as in remove. And, correspondingly, a way to rename?

[wenzeslaus]

Probably not g.remove mapset because mapset is (at least currently) not considered to be an element (element of a mapset to be exact) like raster or vector maps.

g.mapset -r is difficult to decide. It looks like it makes sense, but on the other hand, in GRASS GIS, you are not allowed to edit data in other mapsets. Deleting other mapset seems to qualify as editing data in other mapset and deleting current mapset does not make much sense.

Nevertheless, now (in the startup) you can do it (you are not really running GRASS yet). It is implemented purely in GUI/Python (AFAIR). It is important for the users who are not using command line and can't use rm /the/full/path/to/mapset or are not confident about the database directory structure to simply navigate there in a file browser and delete it.

Adding rename and delete (of location and mapset) to Datacatalog is an extension of functionality in Startup window and in the Data tab (which is here to be nice towards users without deeper GRASS GIS knowledge or command line knowledge). Another reason for it that the Datacatolog (in a modified) is a candidate for inclusion into the new Startup window. Ideally, the functionality of Datacatalog will be configurable on the code level (so different things can be enabled). There is already runtime configuration, namely unlocking of editing of other mapsets (third button from left - lock which is a toggle).

Thus, I would keep this ticket to be just about the Datacatalog, so if you want to pursue CLI/module-level API for removing mapsets (and locations), please open a new ticket (if it is okay with you). The fact that the functionality is in the GUI is definitively an argument for having it also in the command line (whether it is in a module or in the grass executable).

[jidanni]

And it is weird that g.mapsets.html mentions

mapsets can be removed (operation=remove) from the search path

So users wonder "So in the world of Grass, being removed from the search path means the same as being unlinked from the search path -- means the same thing as being unlinked from the file system??" Or else why don't they also mention how to remove it for good?"

[neteler]

Replying to jidanni:

And it is weird that g.mapsets.html mentions

mapsets can be removed (operation=remove) from the search path

So users wonder "So in the world of Grass, being removed from the search path means the same as being unlinked from the search path -- means the same thing as being unlinked from the file system??" Or else why don't they also mention how to remove it for good?"

Here it only means that the mapset(s) are unlisted from the search path. If you have a better wording, please suggest it at ​https://github.com/OSGeo/grass/tree/master/general/g.mapsets by editing the file(s) and opening a pull request - that would be much appreciated.

[wenzeslaus]

The initial issue migrated to GitHub as Issue 710 with more details included. Closing.

​https://github.com/OSGeo/grass/issues/710

Nikos Alexandris, jidanni, please open new separate issues on GitHub if you are concerned with the CLI or documentation.

BTW, I used resolution "duplicate" which seems okay, but should we add "migrated" as a new resolution to Trac just to make clear for everybody which one to pick when closing a ticket here after opening a new issue on GitHub? Or is duplicate clear enough?