fix(processing): honor WASM tool defaults and offer attribute pickers for field parameters - #1464
Conversation
… for field parameters Fixes #1458 Fixes #1459 Points Along Lines dropped every line's endpoint and gave no hint that its spacing is measured in degrees, and Points To Line made the user type a column name from memory. Both are Processing toolbox issues in local (WASM) mode. Honor the WASM manifest's defaults. `manifestToWhiteboxTool` discarded the manifest's `defaults` map, so the dialog fell back to `false` for every bool. `points_along_lines` documents "Include line endpoints (default true)" but rendered as an unchecked box and sent `--include_end=false`: on the reporter's 0.36-degree line, spacing 0.1 produced 3 points instead of 4, and 0.2 produced a single point, which reads as "nothing happens". 1028 optional parameters across the catalog gain their documented default, 103 of them bools documented as true. The map doubles as the tool's example invocation, so dataset and required entries are dropped: `points_along_lines` lists `input: "lines.shp"` and `spacing: 50` next to the one real default, and prefilling those would offer a path that does not exist and an arbitrary value for a required distance. A parameter the manifest leaves undefaulted now falls back to the catalog's default, so WASM mode opens a tool with the same values the sidecar would. State the coordinate units. Vector inputs reach the WASM runner as GeoJSON, which RFC 7946 fixes to WGS84, so a distance, spacing or tolerance parameter is in degrees. Nothing said so, which is how a spacing of 0.1 (about 11 km) yielded a handful of points on a city-scale line. The parameter list now carries a note with the degree-to-metre scale. Offer the layer's columns for a field parameter. A `*_field` / `*_attribute` string parameter names a column of one of the tool's vector inputs, matched on the name suffix so this covers ~170 tools rather than a hard-coded list. The picker is filled from the layer chosen for the vector input the parameter names, resolved by longest leading name segment for a multi-input tool and falling back to the union of every selected input's columns when the names do not line up. The text box stays editable alongside it, so a file-path input or a column the property sample missed still works. Verified in the browser against the reporter's coordinates, in both themes: Points To Line now lists Lat/Lon/Label/DT for both attribute parameters, and Points Along Lines opens with "Include line endpoints" checked and returns 4 points at spacing 0.1.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughChangesThe processing toolbox now supports scalar defaults from WASM manifests and catalog reconciliation. Vector field parameters derive attribute names from loaded GeoJSON layers, offer selectable yet editable fields, and display localized WGS84 unit guidance. Processing defaults and reconciliation
Vector field selection
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant ProcessingDialog
participant LoadedGeoJSON
participant ParameterField
ProcessingDialog->>LoadedGeoJSON: sample feature properties
LoadedGeoJSON-->>ProcessingDialog: return attribute names
ProcessingDialog->>ParameterField: provide fieldOptions
ParameterField-->>ProcessingDialog: update selected or typed field
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
🔍 PR preview
|
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/geolibre-desktop/src/i18n/locales/ar.json`:
- Line 3334: Update the Arabic translation for vectorUnitsNote to use the
established GIS term “الطبقات المتجهة” instead of “الطبقات الشعاعية”, preserving
the rest of the note unchanged.
In `@apps/geolibre-desktop/src/i18n/locales/de.json`:
- Line 3119: Update the German vectorUnitsNote translation to use the
established “Abstand” wording for the spacing parameter instead of “Raster,”
while preserving the existing WGS84, degree, and conversion details.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: d42c4e94-952d-426e-b0e6-56047668e5c0
📒 Files selected for processing (22)
apps/geolibre-desktop/src/components/processing/ProcessingDialog.tsxapps/geolibre-desktop/src/i18n/locales/ar.jsonapps/geolibre-desktop/src/i18n/locales/de.jsonapps/geolibre-desktop/src/i18n/locales/en.jsonapps/geolibre-desktop/src/i18n/locales/es.jsonapps/geolibre-desktop/src/i18n/locales/fr.jsonapps/geolibre-desktop/src/i18n/locales/hi.jsonapps/geolibre-desktop/src/i18n/locales/id.jsonapps/geolibre-desktop/src/i18n/locales/it.jsonapps/geolibre-desktop/src/i18n/locales/ja.jsonapps/geolibre-desktop/src/i18n/locales/ka.jsonapps/geolibre-desktop/src/i18n/locales/ko.jsonapps/geolibre-desktop/src/i18n/locales/nl.jsonapps/geolibre-desktop/src/i18n/locales/pt.jsonapps/geolibre-desktop/src/i18n/locales/ru.jsonapps/geolibre-desktop/src/i18n/locales/tr.jsonapps/geolibre-desktop/src/i18n/locales/zh.jsonapps/geolibre-desktop/src/lib/whitebox-field-params.tspackages/processing/src/index.tspackages/processing/src/wasm-client.tstests/wasm-tool-manifests.test.tstests/whitebox-field-params.test.ts
- ar.json: use the established GIS term for a vector layer in `vectorUnitsNote`. `الطبقات الشعاعية` reads as radial layers; the catalog already says `الطبقات المتجهة` in six other strings. - de.json: translate "distance, spacing" as `Entfernungs-, Abstands-` in `vectorUnitsNote`. `Raster` is the project's word for raster/grid imagery, so using it for spacing collided with an unrelated concept; `Abstand` is what `graticule.spacing` and `style.decorations.spacing` already use.
Fixes #1458
Fixes #1459
Both issues are in the Processing toolbox's local (WASM) mode, and both are fixed here.
#1458 — Points Along Lines returns too few points
Two causes, one of them a real bug.
The documented default was thrown away.
manifestToWhiteboxTooldiscarded the WASM manifest'sdefaultsmap, sodefaultParameterValuefell back tofalsefor every bool.points_along_linesdocuments "Include line endpoints (default true)" but rendered as an unchecked box and ran with--include_end=false. On the reporter's 8 points (a 0.36-degree line), that is exactly the reported behaviour:include_endfalse(what shipped)true(documented)The fix lifts the manifest's defaults onto each parameter: 1028 optional parameters across the catalog now open with the value their tool documents, 103 of them bools documented as
true.The map doubles as each tool's example invocation, so dataset and required entries are dropped —
points_along_lineslistsinput: "lines.shp"andspacing: 50alongside the one real default, and prefilling those would offer a path that does not exist on the user's machine and an arbitrary value for a required distance. A parameter the manifest leaves undefaulted falls back to the catalog's default, so WASM mode opens a tool with the same values the sidecar would.The units were never stated. Vector inputs reach the WASM runner as GeoJSON, which RFC 7946 fixes to WGS84, so a distance/spacing/tolerance parameter is in degrees. Nothing said so, which is why a spacing of
0.1(≈ 11 km) yielded a handful of points on a city-scale line. The parameter list now carries a note with the degree-to-metre scale, which is also what the issue asked for ("it could be useful that on the Spacing distance between points to be written also the measurement unit").#1459 — Selectable columns on Points to Line
line_fieldandsort_fieldare plain string parameters, so the dialog rendered them as free text and the column name had to be recalled exactly.A
*_field/*_attributestring parameter now offers the columns of the layer chosen for the tool's vector input. Matching on the name suffix covers ~170 tools rather than a hard-coded list; the kind check keeps a same-named dataset parameter out (join_tables'primary_key_fieldis a vector input). For a tool with several vector inputs the source is resolved by longest leading name segment (target_match_field→target, tolerating a pluralorigin_id_field→origins), falling back to the union of every selected input's columns when the names do not line up, so the right column is always in the list.The text box stays editable next to the picker, so a file-path input (sidecar mode) or a column the property sample missed still works.
Verification
Driven in the browser against the reporter's coordinates, in both light and dark themes:
Lat/Lon/Label/DTfor both attribute parameters; pickingDTfills the field and the run succeeds.0.1now returns 4 points (confirmed in the attribute table) instead of 3.New unit tests cover
manifestScalarDefaults, the catalog-default fallback inmergeWasmToolManifests, and the field-parameter name rules.npm run test:frontend(3962 tests),npm run buildandpre-commitall pass.Not fixed here
points_along_linesstill measures spacing in the layer's coordinate units. Offering meters would need a change inwbtools_oss(opengeos/whitebox-wasm), upstream of geolibre-wasm; this PR makes the current units explicit rather than silently surprising.Summary by CodeRabbit