wxGUI/datacatalog : Add STDS in datacatalog

[saket0187]

This PR implements the Data Catalog integration for Space Time Datasets, adding several context menu options, automatic UI updates, and native STDS listing. Adding features mentioned in #861

Features added

• List STDS in the Data Catalog.
• Auto-refresh STDS instantly across the GUI when datasets are modified or created via commands.
• Add t.*.import into Data Catalog toolbar item “Select another import option”.
• Search functionality now supports STDS.
• Context menu options:
  • Mapset node
    • Create temporal datasets
  • STDS node
    • Register maps
    • Unregister maps
    • Merge dataset
    • Update metadata
    • Delete dataset (contains checkbox to let user decide if they want to unregistered/delete maps as well)
    • Rename dataset
    • Export dataset
    • Show metadata
    • Plot Timeline
  • Temporal map node
    • Unregister map
    • Copy
    • Copy name
    • Display layer
    • Show metadata
• Behavior: We now hide listed maps that are registered to an STDS; they are only visible from inside the dataset node to keep the tree clean.

Current State

Please refer to the video below to see the current state of the PR.

Demo Link - New Demo video will be uploaded soon.

[ninsbl]

Good start. Please see my initial feedback below...

[ninsbl]

As discussed, some screenshots or the like would be very helpful also for others to better grasp the changes in the UI...

[petrasovaa]

It's not working for me, I think the problem is with the recent changes in t.list. If you don't have temporal connection in PERMANENT, t.list doesn't list anything in other mapsets.

[saket0187]

It's not working for me, I think the problem is with the recent changes in t.list. If you don't have temporal connection in PERMANENT, t.list doesn't list anything in other mapsets.

This should most probably handle both issues.

[ninsbl]

Having a context menu entry to plot the timeline (https://grass.osgeo.org/grass-stable/manuals/g.gui.timeline.html) of one ore more selected STDS would be a useful UI component IMHO, what do you think?

[ninsbl]

Also modifying metadata (https://grass.osgeo.org/grass-stable/manuals/t.support.html) would make sense to me.

[lindakarlovska]

Just a thought on icons: we could already start preparing Data Catalog for region integration here (#7614), specifically by creating subnodes for type groups. For the STDS dataset subnode, we could use either a plain clock icon or a plain timeline icon as suggested by @petrasovaa. The specific STDS items underneath could then use the standard vector and raster icons.

[ninsbl]

Hi @saket0187 ,

I have been testing your code locally on my linux machine. I fetched your fork and branch and built from a clean state.

Unfortunately, the data catalog never loads and the progress indicator just keeps spinning. Could you please report load times for the data catalog on your machine (together with a rough estimate of the number of proects, mapsets, and maps)?

I do not have that many maps in my current dev-project:

$ g.list mapset=* type=all | wc -l
209

But the other projects do not contain that much more either...

I do see some critical wx / gtk messages in the console:

(wxgui.py:118891): Gtk-CRITICAL **: 11:08:30.877: gtk_widget_set_size_request: assertion 'height >= -1' failed

(wxgui.py:118891): Gtk-CRITICAL **: 11:08:30.877: gtk_widget_set_size_request: assertion 'height >= -1' failed

(wxgui.py:118891): Gtk-CRITICAL **: 11:08:30.877: gtk_widget_set_size_request: assertion 'height >= -1' failed

(wxgui.py:118891): Gtk-CRITICAL **: 11:08:30.877: gtk_widget_set_size_request: assertion 'height >= -1' failed

(wxgui.py:118891): Gtk-CRITICAL **: 11:08:30.902: gtk_widget_set_size_request: assertion 'height >= -1' failed

(wxgui.py:118891): Gtk-CRITICAL **: 11:08:30.902: gtk_widget_set_size_request: assertion 'height >= -1' failed

But I am not sure if they are related....

This is the system I have right now:
g.version -gbre
version=8.6.0dev
date=2026
revision=763b17e9a5
build_date=2026-07-09
build_platform=x86_64-pc-linux-gnu
build_off_t_size=8

./configure --without-pdal
libgis_revision=f37d752dc5
libgis_date=2026-05-28T18:08:24+00:00
proj=9.6.2
gdal=3.10.3
geos=
sqlite=3.47.2

My version of wxpython is 4.2.2 and Python is 3.13.13.

I can update elements if there is indication that it could fix some of the issues. Anyway, it would be great if you could investigate...

I alos tested on Windows Subsystem for Linux (WSL), but there the GUI justs starts and crashes (which may be due to WSL limitations, though other GUI applications do work there).

[echoix]

The gui can work on wsl, but I just wouldn’t consider resolution or visual theme weirdnesses as grass bugs. But it does work enough to see something

[saket0187]

Hello! I have two questions about the desired behavior for space-time datasets in the Data Catalog:

1. When a user registers (or unregisters) a map to a dataset via the context menu, should that map automatically hide from (or reappear in) the regular map list? Currently, the register/unregister actions only reload the dataset node itself, so the regular map list doesn't update to reflect the change. If it should update, is it acceptable to reload the entire mapset node every time, or is there a more optimal way to do this?
2. Regarding dataset deletion (t.remove), I've added a checkbox in the delete dialog to "Also unregister maps" (which currently uses the -rf flags to remove the dataset and unregister the maps, but does not delete them). If this is checked, should I instead be using the -fd flags to unregister and completely delete the maps from the mapset? Furthermore, would it be better to have two distinct context menu options (e.g., "Delete dataset" and "Delete dataset and maps") instead of a single option with a checkbox?

[petrasovaa]

Hello! I have two questions about the desired behavior for space-time datasets in the Data Catalog:

1. When a user registers (or unregisters) a map to a dataset via the context menu, should that map automatically hide from (or reappear in) the regular map list? Currently, the register/unregister actions only reload the dataset node itself, so the regular map list doesn't update to reflect the change. If it should update, is it acceptable to reload the entire mapset node every time, or is there a more optimal way to do this?

It should update. I think reloading entire mapset node is acceptable, not everybody has hundreds of maps. But we can look into more efficient solutions.

2. Regarding dataset deletion (t.remove), I've added a checkbox in the delete dialog to "Also unregister maps" (which currently uses the -rf flags to remove the dataset and unregister the maps, but does not delete them). If this is checked, should I instead be using the -fd flags to unregister and completely delete the maps from the mapset? Furthermore, would it be better to have two distinct context menu options (e.g., "Delete dataset" and "Delete dataset and maps") instead of a single option with a checkbox?

It should be:

• Delete dataset only
• Delete dataset and maps
  (see our GSOC Google document)

[petrasovaa]

When testing I am getting:

Process Process-11:
Traceback (most recent call last):
  File "/usr/lib/python3.12/multiprocessing/process.py", line 314, in _bootstrap
    self.run()
  File "/usr/lib/python3.12/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/home/anna/dev/grass/grass/dist.x86_64-pc-linux-gnu/gui/wxpython/datacatalog/tree.py", line 186, in getLocationTree
    reg_maps = tgis.registered_maps_grouped(dbif=dbif)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/anna/dev/grass/grass/dist.x86_64-pc-linux-gnu/etc/python/grass/temporal/gui_support.py", line 197, in registered_maps_grouped
    maps.sort(key=sort_key)
TypeError: '<' not supported between instances of 'int' and 'datetime.datetime'

[saket0187]

When testing I am getting:

Process Process-11:
Traceback (most recent call last):
  File "/usr/lib/python3.12/multiprocessing/process.py", line 314, in _bootstrap
    self.run()
  File "/usr/lib/python3.12/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/home/anna/dev/grass/grass/dist.x86_64-pc-linux-gnu/gui/wxpython/datacatalog/tree.py", line 186, in getLocationTree
    reg_maps = tgis.registered_maps_grouped(dbif=dbif)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/anna/dev/grass/grass/dist.x86_64-pc-linux-gnu/etc/python/grass/temporal/gui_support.py", line 197, in registered_maps_grouped
    maps.sort(key=sort_key)
TypeError: '<' not supported between instances of 'int' and 'datetime.datetime'

Thanks for reporting that.
It works fine for me with the test data and my other datasets, so I couldn't hit it directly at first. I reproduced it by pointing a map's registered_stds at a different-typed dataset with an SQL query, and that produces exactly your error.

I did some research and t.register does guard against this: Re-reads each temporal type from the database and refuses if it doesn't match the dataset. So I think one of your datasets may have been modified outside of GRASS at some point, maybe by an SQL query. Could you check?

The Data Catalog shouldn't crash on that either way. I've fixed it in gui_support.py in the latest commit so it handles mixed types.

Could you try the update? If it still fails, please share the full traceback.

[petrasovaa]

Could you try the update? If it still fails, please share the full traceback.

That fixes it! Thank you.

It would be interesting to measure how long the loading takes, e.g. measure time to load the temporal testing dataset with this PR vs on main branch (i.e. without the changes adding the STDS).

[petrasovaa]

Thanks for reporting that. It works fine for me with the test data and my other datasets, so I couldn't hit it directly at first. I reproduced it by pointing a map's registered_stds at a different-typed dataset with an SQL query, and that produces exactly your error.

I did some research and t.register does guard against this: Re-reads each temporal type from the database and refuses if it doesn't match the dataset. So I think one of your datasets may have been modified outside of GRASS at some point, maybe by an SQL query. Could you check?

I thought just mix of relative and absolute datasets in one mapset might trigger it but I didn't check, anyway, it's fixed.

[saket0187]

Maybe document this behavior (absolute first, then relative) in the comment or docstring

Added the comment and one small optimisation in unregistermap.

It would be interesting to measure how long the loading takes, e.g. measure time to load the temporal testing dataset with this PR vs on main branch (i.e. without the changes adding the STDS).

The GUI, with the changes, takes around 4 seconds more.

[echoix]

It would be interesting to measure how long the loading takes, e.g. measure time to load the temporal testing dataset with this PR vs on main branch (i.e. without the changes adding the STDS).

The GUI, with the changes, takes around 4 seconds more.

Is this expected and how bad is it?

[ninsbl]

Hi @saket0187 , I will test the latest version more thoroughly with the different test data and check performance on my system with the test data.
Things I noticed / wonder from trying out: timeline plotting is greyed out when I am not in the STDS mapset or when dependencies are missing (e.g. matplotlib). Would it be possible to have a hover-effect telling the user why it is greyed-out and unavailable?
Esp. timeline plotting is useful across mapsets, so reading STDS from other mapsets without searchpath modification would be useful (see #7670).
Probably not related, but I noticed that 3D plots of g.gui.tplot get plotted on top of the previous plot. Can you confirm?
Not for this PR, and probably not even for your GSoC project but more general for STDS GUI tools: we do have g.gui.tplot and g.gui.animation, and we have also similar functionality to the animation tool in Jupyter, but not really a CLI tool. May worth considering...

[ninsbl]

P.S.: It is not possible to re-size the window from g.gui.tplot other than maximize. Would be good if size can be adjusted...

[saket0187]

Is this expected and how bad is it?

@echoix Yes, 3-4 seconds expected.

Things I noticed / wonder from trying out: timeline plotting is greyed out when I am not in the STDS mapset or when dependencies are missing (e.g. matplotlib). Would it be possible to have a hover-effect telling the user why it is greyed-out and unavailable?

Good idea, but as far as I can tell wx does not support tooltips on menu items. What I can do is put the reason in the label itself, which changes depending on why it is unavailable. Not sure if that is a good idea though. See below.

Esp. timeline plotting is useful across mapsets, so reading STDS from other mapsets without searchpath modification would be useful

Thanks, I looked at #7670. I can do a small follow-up for timeline after it gets merged.

Not for this PR, and probably not even for your GSoC project but more general for STDS GUI tools: we do have g.gui.tplot and g.gui.animation, and we have also similar functionality to the animation tool in Jupyter, but not really a CLI tool. May worth considering...

Agreed, worth considering. I'm already working on g.gui.animation, so I'll keep this in mind.

P.S.: It is not possible to re-size the window from g.gui.tplot other than maximize. Would be good if size can be adjusted...

@ninsbl On macOS the window isn't locked to a fixed size, so I can drag-resize freely. I can't reproduce issue for now.

Probably not related, but I noticed that 3D plots of g.gui.tplot get plotted on top of the previous plot. Can you confirm?

I'll try.

[petrasovaa]

Claude review found several issues. I will post it here:

Details

Correctness

1. gui/wxpython/core/gconsole.py:855 — loop variable prompt is overwritten inside the inner loop.
   prompt is read per parameter at line 824, but reassigned by prompt = next((...), None) inside for lname in lnames. After the first name, prompt is no longer "stds", so remaining names are checked against the type resolved for the first name; if the first lookup fails, prompt becomes None and the next iteration falls into the gs.find_file(lname, element=p.get("element")) branch, where a hit makes None not in stds_prompts true and fires mapCreated.emit(ltype=None, ...) plus grassdbChanged(element=None).
   Currently latent — no in-tree tool has a generic-stds parameter that is both multiple and (age=new or one of the name-special-cased tools), and old + multiple is truncated to lnames[0:1]. An addon or a future G_OPT_STDS_OUTPUTS would expose it. Fix: resolve into a separate local, e.g. resolved_prompt.

2. gui/wxpython/datacatalog/tree.py:2802 (and :3166) — accessibility check compares mapset names only.
   is_accessible = self.selected_mapset[0].data["name"] in self._getMapsetsInSearchPath(); _getMapsetsInSearchPath() returns mapsets of the current project. Right-clicking an STRDS in otherproject/PERMANENT enables "Display temporal extent" and "Merge datasets" because PERMANENT is in the current project's search path. OnDisplayTemporalExtent / OnMergeStds then call RunCmd(...) / GUI().ParseCommand(...) with no env, so the tool runs in the current project and either fails or silently operates on a same-named dataset in the wrong project. The guard should compare grassdb + location nodes against the current ones.

3. gui/wxpython/datacatalog/tree.py:2025 (OnExportStds) — no project/mapset guard at all.
   Register/Unregister/Update metadata are gated on is_active, and OnMetadataStds builds an env via gs.create_environment; Export does neither. It launches t.rast.export input=@ in the current session, so selecting a dataset in a different project exports the current project's same-named dataset or errors out.

4. gui/wxpython/datacatalog/tree.py:963 (_populateMapsetItem) — vector map ids carrying a layer number are mishandled.
   tgis vector ids are name(:layer)@mapset (python/grass/temporal/abstract_dataset.py:237). For an STVDS registering roads:1@PERMANENT: (a) the hide check compares f"{item['name']}@{mapset_name}" = roads@PERMANENT against roads:1@PERMANENT, so the map is listed twice — once at mapset level, once under the dataset; (b) the child node stores map_id="roads:1@PERMANENT" and name="roads:1", and that map_id goes verbatim to AddMaps() (DisplayLayer), v.info map= (OnMetadata) and the clipboard, all of which reject the :layer form.

5. gui/wxpython/datacatalog/tree.py:2853 (_popupMenuStdsMap) — registered maps lose Cut / Paste / Delete / Rename.
   _populateMapsetItem hides any map registered in an STDS of the same mapset from the mapset listing, and the STDS-map menu offers only Copy / Copy name / Display / Show metadata / Unregister. Once a raster is registered in an STRDS there is no longer any way in the Data Catalog to rename or delete it — a regression against the current behavior.

6. gui/wxpython/datacatalog/tree.py:1027 (DefineItems) — mixing a registered map with a normal map yields an empty menu.
   Registered maps are tagged "stds_map", ordinary maps "layer", so set(mixed) has size 2, self.mixed becomes True, and OnRightClick falls through to _popupMenuEmpty(). Ctrl-selecting elevation and a map that happens to be inside an STRDS silently produces no usable context menu.

7. gui/wxpython/datacatalog/tree.py:2797 (_popupMenuStds) — Rename / Delete not gated the way the layer menu is.
   _popupMenuLayer disables Delete and Rename via item.Enable(currentMapset). _popupMenuStds gates Register/Unregister/Update metadata on is_active but leaves "Rename dataset", "Delete dataset only" and "Delete dataset and maps" always enabled, including for datasets in mapsets the user is not in (and, in restricted mode, in other projects).

8. python/grass/grassdb/data.py:62 (stds_exists) — unescaped name in SQL where, and errors indisxist".
   where=f"name='{name}'" breaks on a name containing '; t.list then fatals and except ToolError: r into "no such dataset". In NameEntryDialog.OnOK that means the rename dialog accepts a name itcould not validate and t.rename fails afterwards. The same swallowing in gconsole silently suppresses the tree refresh on a transient failure.

9. gui/wxpython/datacatalog/tree.py:2491 (Filter) — search hits nested in STDS nodes stay hiddenExpandCurrentMapset changed from recursive=True to recursive=False (tree.py:1277). In Filter thens when the filtered model has ≤50 leaves; above that, a match living under an STDS node is neverrevealed, so the search appears to return nothing.
   10. still_registered keys on bare map_id, losing the type._populateMapsetItem:955 keys on (id, type) pairs, but _unhideMapsInMapset collects only child.davector both named elev@PERMANENT share a map_id, so unregistering the raster while the vector isstill registered leaves the raster hidden from the mapset listing with no way to restore it short of a full reload.

10. Finding 4 extends here.name, map_mapset = map_id.split("@", 1) yields name = "roads:1" for an STVDS-registered vector, apset listing under a name no tool accepts.

Performance / cleanup

12. gui/wxpython/core/gconsole.py:854 — up to three t.list subprocesses on the GUI thread per finished command. Resolving a generic stds prompt calls stds_exists once per candidate type, each spawning t.list )). This happens in OnCmdDone on the main thread, so e.g. every t.create blocks the UI for up tothree temporal-DB startups.

13. gui/wxpython/datacatalog/tree.py:1946 (_deleteStds) — O(N) full mapset reloads when deleting N datasets.
    grassdbChanged is emitted inside the per-dataset loop; each emit reaches _updateAfterGrassdbChanged → _reloadMapsetNode, which spawns a getLocationTree subprocess and does copy.deepcopy(self._model). Deleting 20 datasets triggers 20 subprocesses and 20 deep copies. ae853ae added try/finally around the busy cursor heoop. Emitting once after the loop would suffice.

14. gui/wxpython/datacatalog/tree.py:1876 (OnDeleteMap) — re-implements _confirmDialog.
    The rewritten confirmation builds wx.MessageDialog(self, question, _("Delete map"), wx.YES_NO) inline, which is exactly what _confirmDialog does and what the previous code called. The rest of the STDS code does use _confirmDialog.

I think number 5 and 6 are intentional behavior/design decisions to avoid more complexity.
The issues with STVDS datasets that use layers are real problem we haven't discussed, since they are not used frequently. I don't think we should display the layers in the catalog explicitly, at least not at this point. So showing the map once seems enough even if it has multiple layers. But we may need to revisit it later.

See if you can figure out most of these and we can discuss the rest.

[petrasovaa]

Is this expected and how bad is it?

@echoix Yes, 3-4 seconds expected.

If you have no temporal datasets, this PR shouldn't be adding any significant delay. But since people may have empty databases (even opening temporal tool dialog is creating the database, or some other ways), I wonder if there could be any optimization there, but that by itself would be a query, so I don't know...

[saket0187]

I think number 5 and 6 are intentional behavior/design decisions to avoid more complexity.
The issues with STVDS datasets that use layers are real problem we haven't discussed, since they are not used frequently. I don't think we should display the layers in the catalog explicitly, at least not at this point. So showing the map once seems enough even if it has multiple layers. But we may need to revisit it later.
See if you can figure out most of these and we can discuss the rest.

Implemented 1-4 and 8-12

7. gui/wxpython/datacatalog/tree.py:2797 (_popupMenuStds) — Rename / Delete not gated the way the layer menu is.
   _popupMenuLayer disables Delete and Rename via item.Enable(currentMapset). _popupMenuStds gates Register/Unregister/Update metadata on is_active but leaves "Rename dataset", "Delete dataset only" and "Delete dataset and maps" always enabled, including for datasets in mapsets the user is not in (and, in restricted mode, in other projects).

Rename and delete build their own environment with gs.create_environment() for the dataset's mapset, so they already work outside the current mapset by design.

The currentMapset check in _popupMenuLayer is actually vestigial: _isCurrent() returns True unconditionally because _restricted is always False since #6405 turned restrictions off ("this restriction is unexpected especially for new users"), and SetRestriction() has had no callers since. So copying that gate would do nothing.