docs(processing): explain the two toolboxes and fix stale menu paths (#1929)

* docs(processing): explain the two toolboxes and fix stale menu paths

The Processing menu carries two independent tool collections whose category
names collide: the Whitebox toolbox catalog (Conversion, Hydrology, LiDAR,
Network, Projection, Raster, Remote Sensing, Terrain, Vector as direct children
of the menu) and GeoLibre's own dialogs under the GeoLibre Toolbox submenu.
Nothing in the docs said so, so 'Processing / Vector / GeoLibre (WASM)' and
'Processing / GeoLibre Toolbox / Vector' read as duplicates.

- New 'Two toolboxes in one menu' section on the Processing Tools page: the
  menu tree as rendered, a side-by-side table of what each toolbox is and
  where it runs, and the specific Vector-vs-Vector pair spelled out. Also
  notes that the dialog's Source filter ('GeoLibre tools' / 'Whitebox tools')
  splits the Whitebox catalog only, which is a third thing again.
- Reorganized the page under 'GeoLibre Toolbox' and 'Whitebox Toolbox'
  headings and documented the families that had no entry at all: Network,
  Spatial Statistics, DGGS, Geocode Addresses, Batch & Models, Object
  Detection, Segment Everything, plus the Raster Analysis group and the
  Vector Movement and Data quality groups.
- Corrected the Conversion section: every conversion tool now has a
  client-side engine, so the per-tool 'Sidecar' engine column was wrong;
  Raster to PMTiles was missing entirely.
- Updated the menu paths that moved under GeoLibre Toolbox across the docs,
  README, and the sidecar README, and repointed the README's
  #geoprocessing-toolbox anchor at #whitebox-toolbox.
- Added a Troubleshooting entry for users who land there after seeing the
  same category name twice.

* docs(processing): scope the conversion allowlist claim, note colliding tool names

Two points from review.

The conversion sidecar's path allowlist is opt-in, not unconditional:
GEOLIBRE_CONVERSION_ROOTS is unset on desktop (app/conversion.py: 'Unset
means no restriction (the default for the desktop app)') and set by the
Docker image, whose sidecar is reachable same-origin through the nginx
proxy. The page inherited a flat 'hardened with a path allowlist' claim
that read as always-on; it now says which deployment sets it and why.

Reviewing a (mistaken) claim that the tutorials' Conversion paths pointed
at the wrong toolbox turned up a sharper case of this PR's own subject:
a few individual tool *names* collide across the toolboxes, not just
category names. The WASM catalog carries vector_to_pmtiles / write_pmtiles
displayed as 'Vector to PMTiles' and 'Raster to PMTiles', which are also
the names of two ConversionDialog tools, so both menus show a 'Vector to
PMTiles' leaf that opens a different dialog. Called out in 'The two paths
that look alike', with a note that these docs mean the GeoLibre Toolbox
one. The existing paths are correct and unchanged.

* docs(processing): correct the separator reference and the result-is-a-layer claim

Two minor review points, both right.

'Everything above the first separator' put AI Assistant inside the
Whitebox block; the Whitebox section is the block between the first and
second separators.

'the result is added to the map styled and ready' held for the analysis
dialogs but not for Conversion, which writes a file. Split the two.

Author: giswqs

README.md

@@ -31,7 +31,7 @@ GeoLibre is built with **Tauri v2**, **React**, **TypeScript**, **MapLibre GL JS
 - **[Get it on Google Play](https://play.google.com/store/apps/details?id=org.geolibre.app)** — the native Android app
 - **[Use the Python package](https://geolibre.app/python/)** — embed and control the full app in Jupyter notebooks
 - **[Use the R package](https://r.geolibre.app/)** — build interactive maps in RStudio, Quarto, R Markdown, and Shiny
-- **[1,000+ geoprocessing tools](https://geolibre.app/user-guide/processing/#geoprocessing-toolbox)** — the full toolbox, in the browser
+- **[1,000+ geoprocessing tools](https://geolibre.app/user-guide/processing/#whitebox-toolbox)** — the full toolbox, in the browser
 - **[Get started](https://geolibre.app/getting-started/)** — install, run from source, and configure
 - **[Features](https://geolibre.app/features/)** — the complete feature list
 
@@ -106,7 +106,7 @@ Switch bodies from the planet switcher in the Layers panel. See [Demos](https://
 
 [![The GeoLibre Whitebox toolbox running locally with WebAssembly, listing the full catalog of 1,000+ tools with the Regularize Building Footprints tool selected](https://assets.geolibre.app/images/whitebox.webp)](https://assets.geolibre.app/images/whitebox.webp)
 
-**Processing → Whitebox** opens a toolbox of **1,000+ geoprocessing tools** that
+**Processing → Whitebox Toolbox** opens a toolbox of **1,000+ geoprocessing tools** that
 execute in the browser through a WebAssembly runtime with native raster and
 vector I/O. There is no Python sidecar to install and no server to call — the
 tools, your data, and the results all stay on your machine, so the full toolbox
@@ -130,7 +130,7 @@ the Processing menu:
 | **Projection** | 4 | reprojection for raster and vector data |
 
 Any tool is deep-linkable with a `?tool=` URL parameter that preselects it and
-pre-fills its form. See the [Processing Tools guide](https://geolibre.app/user-guide/processing/#geoprocessing-toolbox)
+pre-fills its form. See the [Processing Tools guide](https://geolibre.app/user-guide/processing/#whitebox-toolbox)
 for details, and [Geoprocessing in the Browser](https://youtu.be/W32bIQO_nG8) for
 a video walkthrough.
 

backend/geolibre_server/README.md

@@ -50,10 +50,10 @@ WBW_EXTERNAL_PYTHON=/path/to/python
 
 ## Conversion runtime
 
-The **Processing → Conversion** menu uses a dedicated managed runtime
-(DuckDB + rio-cogeo + freestiler), bootstrapped the same way as Whitebox: the
-sidecar finds or installs `uv`, creates a virtual environment, and installs the
-conversion packages on first use.
+The **Processing → GeoLibre Toolbox → Conversion** menu uses a dedicated managed
+runtime (DuckDB + rio-cogeo + freestiler), bootstrapped the same way as Whitebox:
+the sidecar finds or installs `uv`, creates a virtual environment, and installs
+the conversion packages on first use.
 
 - **Vector → GeoParquet** and **CSV → GeoParquet** also run entirely in the
   browser with DuckDB-WASM, so they work in the web build with **no sidecar**.

docs/android.md

@@ -28,7 +28,7 @@ Vector tools (Turf.js / in-browser GeoPandas via Pyodide), the SQL Workspace
 Tools that depend on a **local desktop process** are hidden on mobile, because
 Android has no Python sidecar or local helper binaries:
 
-- Processing → **Raster**, **Conversion**, **AI Segmentation**
+- Processing → GeoLibre Toolbox → **Raster**, **Conversion**, **AI Segmentation**
   (all need the Python sidecar)
 - Add Data → **PostgreSQL** (served by the local Martin tile server)
 

docs/architecture.md

@@ -72,7 +72,7 @@ The FastAPI app in `backend/geolibre_server` backs the format Conversion tools,
 
 The Whitebox toolbox does **not** depend on it: its 1,000+ tools run in the browser on the `geolibre-wasm` WebAssembly runtime by default, and the sidecar is an opt-in alternative engine that can read native file paths for batch runs over a directory.
 
-The Vector tools (Processing → Vector) run client-side with Turf.js and need no sidecar. All of the tools can optionally run on the sidecar's `/vector` endpoints, backed by GeoPandas and Shapely, for projection-aware results; the sidecar reports availability through `/vector/status`, and the dialog falls back to the client engine when the optional `vector` extra is not installed.
+The Vector tools (Processing → GeoLibre Toolbox → Vector) run client-side with Turf.js and need no sidecar. All of the tools can optionally run on the sidecar's `/vector` endpoints, backed by GeoPandas and Shapely, for projection-aware results; the sidecar reports availability through `/vector/status`, and the dialog falls back to the client engine when the optional `vector` extra is not installed.
 
 A third Vector engine, **Python (Pyodide)**, runs the same GeoPandas/Shapely code **in the browser** via [Pyodide](https://pyodide.org) (CPython compiled to WebAssembly), so the GeoPandas path is available on the web build with no server. The geometry logic is a framework-free module, `backend/geolibre_server/geolibre_server/vector_ops.py`, that both the sidecar and the browser run — a Vite plugin (`vite-plugins/copy-vector-ops.ts`) copies it into the app bundle, and a classic Web Worker (`public/pyodide/pyodide-worker.js`) loads Pyodide from a CDN, installs `geopandas`, and calls `run_vector_tool` over a JSON-string boundary. One source of truth means the Sidecar and Pyodide engines return identical results. The Pyodide runtime is downloaded lazily on first use; the `VITE_PYODIDE_INDEX_URL` env var points it at a self-hosted mirror for offline/production deployments.
 

docs/downloads.md

@@ -132,7 +132,7 @@ shipping them broken. Here is how the two macOS builds compare:
 | Feature | Homebrew / DMG | Mac App Store |
 | --- | --- | --- |
 | Whitebox toolbox (1,000+ WebAssembly tools) | Yes | Yes |
-| Processing → Vector, browser-engine Conversion, client raster tools | Yes | Yes |
+| Processing → GeoLibre Toolbox → Vector, browser-engine Conversion, client raster tools | Yes | Yes |
 | SQL Workspace (DuckDB-WASM, PGlite/PostGIS, in-browser Apache Sedona on CereusDB) | Yes | Yes |
 | Python sidecar engines (GeoPandas vector, rasterio raster, GDAL conversion, SamGeo segmentation, the SedonaDB sidecar behind the Apache Sedona engine) | Yes | No |
 | Add Data → PostgreSQL / PostGIS (martin tile server) | Yes | No |

docs/features.md

@@ -200,7 +200,7 @@ kepler.gl, see the [Comparison](comparison.md).
 - Spatial Statistics toolbox, including Emerging Hot Spot Analysis that builds a space-time cube from timestamped points, runs Getis-Ord Gi\* per time slice, and classifies each cell as a new, intensifying, persistent, diminishing, sporadic, oscillating, or historical hot or cold spot
 - Processing batch runner with model and pipeline chaining, to run a sequence of tools as one job
 - Processing History panel that lists every tool run, re-runs any of them with one click, and copies the equivalent Python code
-- Raster Georeferencer (Processing → Georeferencing) that pins a non-georeferenced image to the map with ground control points using a least-squares affine fit, reporting per-GCP and RMS residuals
+- Raster Georeferencer (Processing → GeoLibre Toolbox → Raster → Georeferencing) that pins a non-georeferenced image to the map with ground control points using a least-squares affine fit, reporting per-GCP and RMS residuals
 - Network analysis tools for isochrones, service areas, origin–destination (OD) cost matrices, and sequential routes (directions) through an ordered set of waypoints
 - Geocoding tools for forward, batch, and reverse geocoding through a multi-provider abstraction
 - AI Segmentation (SamGeo) that turns imagery into vector features with [segment-geospatial](https://github.com/opengeos/segment-geospatial) and Meta's SAM 3 — text prompts ("trees", "buildings") or automatic segmentation, proxied to a separate `samgeo-api` model server (GPU recommended). See [AI Segmentation](user-guide/segmentation.md)

docs/index.md

@@ -79,13 +79,13 @@ Run DuckDB Spatial SQL in the browser against loaded layers, local files, and re
 <div class="feature-card" markdown>
 ### Vector tools
 
-Geometry tools under Processing → Vector — buffer, centroids, convex hull, dissolve, bounding box, simplify, smooth, regular grid, clip, overlay (intersect/difference/union), spatial and attribute joins, selection, Voronoi/Delaunay, and H3 grids and binning — run in the browser with Turf.js, with an optional GeoPandas sidecar engine. A Spatial Statistics toolbox and a batch runner with model/pipeline chaining round out Processing.
+Geometry tools under Processing → GeoLibre Toolbox → Vector — buffer, centroids, convex hull, dissolve, bounding box, simplify, smooth, regular grid, clip, overlay (intersect/difference/union), spatial and attribute joins, selection, Voronoi/Delaunay, and H3 grids and binning — run in the browser with Turf.js, with an optional GeoPandas sidecar engine. A Spatial Statistics toolbox and a batch runner with model/pipeline chaining round out Processing.
 </div>
 
 <div class="feature-card" markdown>
 ### Raster tools
 
-Raster tools under Processing → Raster — hillshade, slope, aspect, reproject, resample, clip, polygonize, contour, zonal and focal statistics, raster calculator, reclassify, mosaic, and a Spectral Index toolbox (NDVI, NDWI, EVI with band presets) — run on a rasterio sidecar with a client-side fallback. Includes a Georeferencer and single-band or RGB raster styling.
+Raster tools under Processing → GeoLibre Toolbox → Raster — hillshade, slope, aspect, reproject, resample, clip, polygonize, contour, zonal and focal statistics, raster calculator, reclassify, mosaic, and a Spectral Index toolbox (NDVI, NDWI, EVI with band presets) — run on a rasterio sidecar with a client-side fallback. Includes a Georeferencer and single-band or RGB raster styling.
 </div>
 
 <div class="feature-card" markdown>

docs/ios.md

@@ -45,7 +45,7 @@ Tools that depend on a **local desktop process** are hidden on mobile because
 iOS has no Python sidecar or local helper binaries and its sandbox forbids
 spawning subprocesses:
 
-- Processing → **Raster**, **Conversion**, **AI Segmentation**
+- Processing → GeoLibre Toolbox → **Raster**, **Conversion**, **AI Segmentation**
   (all need the Python sidecar). The Whitebox geoprocessing toolbox runs in
   WebAssembly, needs no sidecar, and stays available.
 - Add Data → **PostgreSQL** (served by the local Martin tile server)

docs/self-hosting.md

@@ -371,7 +371,7 @@ the public internet:
 | --- | --- | --- |
 | Basemaps | OpenFreeMap / CARTO tiles | Use the Basemaps plugin's **custom style URL** and serve your own style plus a PMTiles basemap from your server, or use a blank background. Add the host to the CSP if it is not your own origin. |
 | Geocoding | Public Nominatim | Point it at a self-hosted Nominatim or Pelias (see [Data Integrations](user-guide/data-integrations.md#geocoding)). |
-| Routing and isochrones | Public FOSSGIS Valhalla (`valhalla1.openstreetmap.de`) | Set `VITE_ROUTING_ENDPOINT` to your own Valhalla server. This covers Processing → Network and the **Drive time** / **Walk time** [quick actions](user-guide/map-controls.md#quick-analysis-from-a-clicked-point). Add the host to the CSP. |
+| Routing and isochrones | Public FOSSGIS Valhalla (`valhalla1.openstreetmap.de`) | Set `VITE_ROUTING_ENDPOINT` to your own Valhalla server. This covers Processing → GeoLibre Toolbox → Network and the **Drive time** / **Walk time** [quick actions](user-guide/map-controls.md#quick-analysis-from-a-clicked-point). Add the host to the CSP. |
 | Pointer elevation readout | Public Open-Meteo elevation API, whenever 3D terrain has no sample for the point | Leave the readout off (it is off by default), or decline the consent prompt GeoLibre shows before the first remote lookup — that is the gate the resolver checks. Enabling 3D terrain makes the remote call rare but does not rule it out, since a point terrain cannot answer still falls through. |
 | Python (Pyodide) vector engine | Loads Pyodide from jsDelivr | Set `VITE_PYODIDE_INDEX_URL` to a mirrored copy of the Pyodide distribution. |
 | AI assistant | Off unless configured | Leave `GEOLIBRE_AI_URL` unset, or route it through your own proxy. |

docs/tutorials/cloud-native-data.md

@@ -33,14 +33,14 @@ A Cloud-Optimized GeoTIFF is a regular GeoTIFF organized so clients can read jus
 
 ## Convert local data to cloud-native
 
-Use **Processing → Conversion** to write cloud-native files. See [Processing Tools](../user-guide/processing.md#conversion).
+Use **Processing → GeoLibre Toolbox → Conversion** to write cloud-native files. See [Processing Tools](../user-guide/processing.md#conversion).
 
 - **Vector to GeoParquet** and **CSV to GeoParquet** run in the browser with DuckDB-WASM.
 - **Vector to FlatGeobuf**, **Vector to PMTiles**, and **Raster to COG** run on the Python sidecar (desktop app).
 
 For example, to publish a local GeoJSON as GeoParquet:
 
-1. Open **Processing → Conversion → Vector to GeoParquet**.
+1. Open **Processing → GeoLibre Toolbox → Conversion → Vector to GeoParquet**.
 2. Choose the input file and an output path.
 3. Run the conversion, then add the resulting GeoParquet back to the map to verify it.