[Feat] Improve computational regions visibility and management in the GUI

[lindakarlovska]

Is your feature request related to a problem? Please describe.

I’d like to open a discussion about improving how computational regions are handled in the GRASS GUI.
Right now, regions are mostly invisible in GUI workflows. The only thing users really see is the current region as a box in the map display. The current region values are not visible anywhere in the GUI; only the history panel shows region values for the command run at that time.

If someone wants to work with regions more systematically (save multiple regions, see saved regions, switch quickly between regions), the workflow is not very friendly: we need to open the region module dialog or script it. I see two parts of the problem:

• First-time users often miss region setup completely. In our 2022 usability testing for https://www.mdpi.com/2220-9964/12/9/376, students had a task using r.lake and r.stats where setting the computational region was necessary. Even with explicit instructions, several students skipped it entirely.

• Advanced users also have problems. I struggled with regions quite recently, and I definitely don’t consider myself a beginner :-). I tested workflows across multiple areas (I did some generalization using rasterization + i.segment on parcels). Saved regions help a lot, but while testing several workflows in the GUI, I felt very uncomfortable managing regions again and again from dialogs or running commands. It would be nice to see regions somewhere and have simple operations accessible right away.

I think regions are a core GRASS concept, and wrong or missing region settings often lead to confusing outputs. So better GUI support here could significantly improve usability and reduce errors.

Describe the solution you'd like

I have a few ideas:

• Add a Set region button in raster module dialogs

I’m not sure how hard this is to implement, but this expectation came up in testing notes from laboratory testing in 2022 (3/10 students).

• Add a dedicated Regions pane

It could show current region, default region, saved regions, maybe previous regions, and allow quick actions like Set as current, Save region, Zoom to region, etc. I would also appreciate selected vs current parameter differences (or even a simple map preview). I did a bit of AI brainstorming and it could look, for example, like this:

That might be a bit overkill - depends how much importance we want to give computational regions in the GUI (a full pane would of course mean more maintenance).

There is also this option (after some discussion on this topic and showing the Regions pane, this was proposed as a simpler solution by @petrasovaa):

• Add computational regions directly to Data Catalog

I think this is a good idea and I made a wxPython mockup where each mapset has a Computational regions node (with Default region for PERMANENT, Current region, Saved regions), and there would be context menu actions like Set as current, Save, Zoom to region, etc. Icons and final UX details are just brainstorming for now. Adding regions would probably also mean adding/maintaining subnodes like Vector maps, Raster maps, 3D Raster maps, Spatio-temporal datasets, and Regions.

Would love feedback on:

• Do you have other ideas how to improve UX of comp. regions?
• Do you have in mind context menu options or buttons/functions related to regions that you would appreciate?
• Is region diff (selected vs current) worth adding?

Additional context

• If we decide to implement computational regions in Data Catalog, it would also be good to consider the broader context, for example PR wxGUI/datacatalog : Add STDS in datacatalog #7608, which newly adds STDS to Data Catalog.

• There is also a recent PR wxGUI/datacatalog: Add EPSG statusbar button and data catalog context menu options #7297 adding a Show current region context menu option to mapset. I found this very useful as a first step in Data Catalog for quickly showing current region values, but later, if Data Catalog is enhanced with region management, this context menu option could be moved to the region node context menu.

[ecodiv]

I really love the idea. I am experiencing similar issues with my students overlooking or forgetting about the region. Having it in the data catalog would make it more accessible and therefore easier to remember. And for more experienced users, it takes away the friction of working with multiple regions over different sessions, having to remember them.

[lindakarlovska]

Thinking about it more, it may be confusing that computational regions are considered as simply another group in the Data Catalog - it is not Data, rather Settings. One way coming to my mind and quite easy to implement is to distinguish Data and Settings nodes by headers. The mockup from wxpython demo is here:

Going further in the mockup, thanks to the subnodes, it could be also interesting to add the info about number of maps/regions in subnodes:

Or if we are not planning to add any other Settings stuff (we talked sometime ago about workspaces but it does not seem they are planned to become visible in Data Catalog - see discusstion in PR #3113), we could simply have it as follows:

Looking forward to any comments/ideas!

[mazingaro]

Not sure if I can contribute much to the brainstorming here, and this may be a separate topic, but if computational regions become first class objects in the Data Catalog, it opens up some interesting possibilities. I'm sure many users work with the same study area in different CRSs (e.g. Slovenia TM, UTM, WGS84), so for example features like copying/importing a computational region from another project with reprojection could be a useful GUI feature. And maybe more of those can come out.

[petrasovaa]

We (@petrasovaa, @lindakarlovska, @wenzeslaus, @mazingaro ) discussed this suggestion and decided to start with the simplest option of adding the saved regions into the current flat structure. The hierarchy would require more changes and it's unclear whether it would improve user experience.
We need better icon, perhaps using something like a bookmark icon or a simple rectangle.
Regions would have context options (zoom/set current/set default), as @mazingaro suggests, we could allow copying and reprojecting (more work needed for that).

Default region - the concept may be misunderstood, so we need to think more how to add it, possibly using context option on a project node.
Similarly the current region may need a completely different widget/panel, so not necessarily part of the data catalog, because current/default regions are different "types" than saved regions.

We need to decide the naming: "saved" vs "named" region, we prefer "saved" but we should standardize across GUI and documentation.