UX: several friction points found doing real GIS workflows in one sitting

[Ahmedseko]

Summary

Spent a session actually using GeoLibre end-to-end on real data (ArcGIS Pro project import, a large GeoTIFF, an Excel/xls import, general Processing menu navigation) rather than individual features in isolation, and ran into enough friction in a short time that it seems worth reporting as a pattern rather than one-off bugs. Two of these were narrow enough to fix directly (#1899, #1901); this issue is for the broader/structural ones that aren't a small diff.

1. Whitebox vs GeoLibre menu structure is still confusing after #1899

#1899 fixed the literal label collision (two menu items both called "Conversion"), but the deeper structural issue remains: Processing → Whitebox → Conversion has a subcategory literally named "GeoLibre", sitting right next to the actual top-level Processing → GeoLibre menu. Two different, unrelated things share the name "GeoLibre" in the same menu tree. A user (or an LLM assistant navigating the UI on a user's behalf, which is how this was found) has no way to tell them apart from the label alone.

Suggested direction: rename the Whitebox catalog's "GeoLibre" subcategory to something that signals it holds Whitebox-compatible WASM tools authored by GeoLibre (e.g. "GeoLibre Tools" or "GeoLibre (WASM)"), distinct from the top-level GeoLibre menu. This one touches the auto-generated catalog (scripts/gen-whitebox-menu-catalog.mjs / whitebox-menu-catalog.ts), so it's a bigger change than #1899 was.

2. ArcGIS Pro import's warning dialog doesn't scale past a handful of layers

Importing a real ArcGIS Pro project backed by a File Geodatabase produced: "The project was imported, but 257 layers could not be loaded", followed by a flat scrollable list of 257 lines, each reading "The layer's data format is not supported" with no grouping. In practice every one of those had the same root cause (File Geodatabase isn't a supported source), but the dialog gives no way to see that at a glance -- a user has to either scroll all 257 lines or take it on faith.

Suggested direction: group warnings by reason (and layerType where relevant) and show counts, e.g. "245 layers skipped -- File Geodatabase is not a supported data source" with an optional expand, rather than one line per layer regardless of scale. Docs already say FileGDB is explicitly unsupported (docs/user-guide/projects.md), so the dialog reporting that clearly, once, would have saved a lot of scrolling.

3. Excel/spreadsheet data has a rougher path than CSV

Filed separately as #1903 (Add Data has no XY-from-Excel equivalent to ArcGIS's "Add XY Data" -- CSV gets automatic point detection, Excel doesn't). Mentioning here because it's part of the same session's pattern: formats adjacent to a well-supported one (CSV) have noticeably less capable handling, with no signal in the UI that this is the case until the user hits the gap.

Context

All three surfaced from one real workflow (ArcGIS Pro project + large raster + Excel spreadsheet, the kind of mixed-format field-survey data GIS users actually have), not from hunting for edge cases. #1899 and #1901 are narrow fixes for two bugs found along the way; this issue is for the two structural/scale items (#1, #2) that need a maintainer call on direction before someone (possibly me) takes a pass at them.

🤖 Filed with Claude Code

[giswqs]

Traced item 1 through the menu code. Two corrections to the premises first, then the recommendation.

The tree is flatter than described

ProcessingMenu.tsx renders the nine catalog categories as direct children of the Processing dropdown, siblings of the Whitebox item (which just opens the dialog). There is no Processing → Whitebox → … level. So the colliding paths are exact mirror images:

• Processing → Conversion → GeoLibre → … (WASM toolbox catalog)
• Processing → GeoLibre → Conversion → … (app's own dialogs)

And nothing in the menu says those nine categories belong to the toolbox at all, which is the other half of why the two "GeoLibre"s are indistinguishable.

The rename is not a big change

"GeoLibre" is not catalog data. It is GEOLIBRE_SUBCATEGORY at scripts/gen-whitebox-menu-catalog.mjs:24, a generator constant, and nothing keys off the literal (the subcategory sort ranks against the constant itself). One line plus a regenerate.

Also worth noting: #1899 is still open, so the literal Conversion / Conversion collision has not actually landed a fix yet.

The underlying defect

GeoLibre is a provenance label wedged into a function axis. Its siblings are "Flow Routing", "Overlay Math", "Geometry Processing". And it does not scale: Vector → GeoLibre is a flat 208-item submenu and Raster → GeoLibre is 97 (331 GeoLibre-authored tools total, across Vector/Raster/Conversion/Hydrology/Lidar).

The dialog already models this correctly. ProcessingDialog.tsx has an orthogonal Source filter ("All sources / GeoLibre tools / Whitebox tools") sitting next to the Category filter, not inside it. The menu is the only place that folds the two axes together.

Recommendation

Now, two cheap changes with no added depth (opened as #1913):

• Rename the constant to "GeoLibre (WASM)". (WASM) is already this app's user-facing shorthand for the in-browser runtime ("Run locally (WASM)"), so it reads as a runtime note rather than a second product. ("GeoLibre Tools" matches the dialog's Source-filter wording but is weaker disambiguation against a top-level GeoLibre.)
• Add a Whitebox section label above the nine categories, plus a separator before the GeoLibre submenu. That is the signal that was missing, and it costs one muted line rather than the extra hover a Whitebox → parent submenu would put on the way to every tool.

Next, the change that dissolves the problem: give the geolibre-wasm manifests a subcategory upstream in geolibre-rust, either compound "Vector - Geometry Processing" categories like Whitebox's or a new field (tags exists on the manifest but is empty on all 331 tools). The generator then groups GeoLibre-authored tools by function alongside Whitebox's, the provenance bucket disappears by construction, and the 208-item submenu becomes browsable. Provenance stays where it already works: the dialog's Source filter. #1913 is a stopgap until this.

Not recommended: renaming the top-level Processing → GeoLibre. That submenu is the app's own tools and the brand belongs there; #1899 already anchors on it.

Items 2 and 3 of this issue shipped in #1910 and #1906, so item 1 is all that is left here.

🤖 Filed with Claude Code

[giswqs]

This issues have been fixed in #1906, #1911, #1913.