Draft Idea: A New Unified Workflow Concept for GRASS

[lindakarlovska]

Following recent discussions at the GRASS Summit (especially during the Jupyter-related session I had on Saturday), I’d like to share a broader idea that came to my mind — something I believe could significantly improve how we structure and manage workflows in the GRASS GUI.

Worflow Trio

While presenting the new planned feature of launching Jupyter notebooks directly from GUI (btw already pushed as a PR #5901) — I realized it’s not “just” a new feature — it could be the third core pillar in GRASS GUI for building and running workflows, alongside

• Graphical Modeler
• Simple Python Editor (Code editor).

Home worflow directory and Worflows pane

At the same time during the Jupyter-related session, we discussed where should be the home Jupyter directory. Initially, I proposed storing notebooks in the current mapset directory ($MAPSET/notebooks). It was convenient in terms of implementation, but several people pointed out that this is not ideal (and I fully agree). Mapsets are designed for spatial data, not scripts or notebooks — and workflows might span multiple mapsets or even locations.

So the question became:
What if workflows (generally) had their own dedicated space outside of ~/grassdata/?

I have tried to go forward with this idea and prepared the presentation, of how it could look like.

The presentation suggests the combination of two new things: new ~/grass-workflows/ directory + New Workflows pane in GUI.

The pane would include the tree structure (similar to the Data Catalog) acting as a central place for all user-created processes. It could look e.g. like this:
~/grass-workflows/
└── hydrology-2025/
├── import_data.py
├── flood_model.gxm
└── analysis.ipynb

(This is not how people will be working, it is just to show which all file types will be gathered - Python scripts, models and Jupyter notebooks).

Via the new Workflow pane, users could:

• browse, run, convert, and edit workflows (.gxm, .py, .ipynb)
• use templates (e.g., template.ipynb) to get started quickly
• treat workflows as first-class citizens — not hidden in scripts or external folders
• take advantage of type-specific actions:
  .ipynb: open in GUI / browser, convert to script, run
  .gxm: open in Modeler, export, run
  .py: open in Python editor or as notebook, run

Possible Next Steps?

• Add ~/grass-workflows/ structure as part of Jupyter integration
• Prototype the new Workflows Pane in GUI
• Define and implement file-type-specific actions
• Allow users to configure multiple workflow directories

I think that this idea also reflects a broader shift in how GRASS is used - 1) from a classic GIS to a geocomputational engine, 2) from tool-driven interaction to modular, reproducible workflowsm, 3) from fragmented interfaces to a unified workflow management.

Let me know what you think — suggestions and collaboration are welcome!
If there’s interest, we could consider launching a small project around this idea by putting together a working group and reaching out to NumFOCUS to explore possible funding options (e.g., a NumFOCUS Small Development Grant).

[YannChemin]

Hi, I used visual modeling in Erdas-Imagine in 1997, for a short time, as a non-programmer then, it helped me build processing chains nicely, but it did also show that programming was actually the way to get things done. Bash shell in GRASS GIS was the natural next step. F/C/Python followed as the years passed.

I see that what you are describing is an onboarding process into the Geocomputing platform GRASS has become, where, following the level of your skills, you can always get the next level with less effort. i.e. You should have seen the eyes of students when they would have filled in a GUI (say: r.tovect) and I would tell them to not use "run" but "copy" and paste the lines in a text editor. On and on until building a first script. Then, run as a block.

This is a small example of what I mean with effortless onboarding, from non-skilled non-programmer, to evolving into full fledged geocomputing scientists/programmers.

[baharmon]

Hi Linda. Generally this sounds like a good idea to me.
I am concerned about the relationship to the data directory though.
If I understand correctly, there would be totally separate workflow and data directories right?
I'm worried that this might be more complicated and thus confusing for new users.
What if both directories were in a workspace together?

~/grass-workflows/
└── project-1/
    ├── script.py
    ├── model.gxm
    └── notebook.ipynb

~/grass-data/
└── project-1/
    └── PERMANENT
    └── mapset-1

vs.

~/grass-workspace/
└── workflows/
|   └── project-1/
|       ├── script.py
|       ├── model.gxm
|       └── notebook.ipynb
└── data/
    └── project-1/
        └── PERMANENT
        └── mapset-1

[lindakarlovska]

Yesterday we discussed this Workflows topic with @petrasovaa and @wenzeslaus and were thinking about the new pane called File Browser that will be limited to the specific file extensions that we want to show. Users could ideally connect any folder they want - it will not be limited to any specific directory as I initially suggested. Still, there is the question what will be the initial Jupyter working directory where server is running... maybe it is ok to have it in mapset/notebooks and then users could have the option in File Browser to set it up differently? ...