Draft Idea: Thinking more abort workspaces in GRASS GUI

[lindakarlovska]

I was thinking about it more and I generally like the idea from #3113 where workspace are part of a mapset - I like it from the point of a user that I will switch to a mapset and the workspace will be automatically created for me. What I like less is thinking about it from the view of storage - I do not like that the data and the technical GUI configuration file is mixed in one directory, though I don’t yet have a perfect solution either.

I think it would make sense to store workspaces on default in the new configuration directory ~/.grass8/workspaces/ and show them in a separate Workspaces tab - also creating its own pane for Workspaces would be not just to manage workspaces more easily, but also to raise their visibility and encourage users to take advantage of them.

I put the idea into short presentation: https://docs.google.com/presentation/d/1cPsE971Iis9WzRRwtR0OoUgZJRcVEmgNN6GjGzUCmUk/edit?slide=id.g3367653f5f2_0_49#slide=id.g3367653f5f2_0_49.

I think that the idea in #3113 is not against what is in the presentation, I actually believe they could complement each other quite well (though it would definitely need some thinking and coordination). That’s why I’m sharing this here — to open it up for discussion and see if others feel similarly or have additional ideas.

[wenzeslaus]

I think the project can store data, computational regions, labels, and yes even the GUI state. I still favor something like #3113 where workspace is integrated into the project, and potentially completely hidden in the sense that there is less concepts to grasp.

Project is the main thing user should focus on

Projects are now naturally the main thing for a user to interact with, with mapsets playing a role of organizing the data further if needed. For desktop GUI users, GUI is in front of them, so GUI can nicely just fall into the same place, i.e. project.

Quoting myself in #3121 (Rename location to project):

We are choosing project as the new name because:

1. Location is the main structure used for organizing data in GRASS GIS. Project is what software packages often use to organize what they work with.
2. The word project should emphasize that this is the level in the hierarchy to focus on. The other two levels might be useful, but this one is crucial.
   ...
   What about GUI workspaces? While the GUI workspace files share a lot in common with projects in other software, the parts they share are state of the GUI. The workspaces in GRASS GIS don’t have the central role project files have in other software.

Projects already store non-data

We adopted the name project, considering that is it is catch-all term, and in fact, projects already store things which are not data.

Myself again now from #2993 (Minimal changes to rename...):

A GRASS location (or mapset) does represent the state of what the user was doing in a sense that it has all the data you were working with, history of what you were doing, current computation extent and resolution, default extent, bookmarked extents (spatial bookmarks aka saved regions), associated styles when stored as color tables, labels for cartography (v.label, d.label), links to external data, even your selected CRS.

One may argue that the state of the GUI is missing [in the GRASS project]. I would agree. I think what is now a workspace file would make most sense as part of a mapset (I'm thinking that since I saw the low uptake of workspace file with stored mapset path and the much more successful data management panel).

While projection or CRS is an import part of what location is in GRASS GIS, both projection and CRS refer to something completely different than data storage and what locations do is storing data. They store them in a particular way which involves data format and CRS, but they are more than just data storage, they also store much of the information users generates when working with the software.

Mixing data and state is common elsewhere

Given this is about desktop GUI and related to management of data, comparison with ArcGIS and QGIS may be helpful:

About ArcGIS and QGIS from #2993:

The ArcGIS Pro project files are grouped together with actual data storage, not just views or links to data.

While QGIS project does not store data, it stores auxiliary data and it can be stored inside a GeoPackage with the data (so go as far as saying [QGIS] GeoPackage Project).

In cases of ArcGIS and QGIS, actual data storage can be part of the project, so it is not just purely state of the GUI. For wxGUI, the workspace file referred originally to state of the GUI (some windows, added layers, d-command styling, 3D) and now it includes also path to mapset.

The word workspace is used in ArcGIS:

Tools that honor the Current Workspace environment use the workspace specified as the default location for geoprocessing tool inputs and outputs. ... In ArcGIS Pro, the default value for the Scratch Workspace and Current Workspace environments is the project default geodatabase.

So the two closet things we have are what is currently called mapset (not location!) and current working directly (pwd, os.getcwd(), getwd()).

And QGIS documentation uses that to refer to whatever sort of the state of the GUI thing:

QGIS can save the state of your workspace into a QGIS project file using the menu options Project ► Save or Project ► Save As….

That would be the GUI workspace file, except that QGIS project can have associated external data like Shapefile on the disk and the workspace file cannot. However, GRASS GIS can do it in a location, or more precisely in a mapset (v.external, r.external).

...so maybe there is not a clear distinction between data and non-data parts of projects. v.external and r.external linked data would be how things are added to a GUI-driven "project" file in other software, in GRASS, it is on the same level as data already.

[veroandreo]

I like the idea of having a dedicated panel or tab in the GUI to list and manage workspaces; this would improve usability and encourage users to make better use of workspaces, well, discover they exist! :)

I personally prefer the concept proposed in #3113, where the workspace remains tied to a mapset. From a user perspective, this feels more natural and organic: when I switch to a mapset, I would expect the relevant workspace to be automatically loaded, or have the chance to select the one I want from a panel - I'm thinking of various workspaces per mapset displaying different sets of maps, without needing to browse a separate list disconnected from the project structure.

[YannChemin]

I like the idea of having a dedicated panel or tab in the GUI to list and manage workspaces; this would improve usability and encourage users to make better use of workspaces

That, I would use daily. I need to switch half a dozen projects' mapset in a day, already the "double-click mapset" to switch is great in the GUI, but I still need to load my workspace each time again.