Permettre aux add-ins de fournir des dialogues personnalisés (ou des contrôles de paramètres personnalisés) pour les outils de géotraitement

JeffJenness

Résumé du problème

Le cadre de géotraitement est l'un des plus grands atouts d'ArcGIS Pro, et les développeurs tiers y sont à juste titre orientés : un outil construit en tant qu'outil script ou boîte à outils Python bénéficie de l'historique du géotraitement, des paramètres d'environnement, du suivi de progression et des rapports de messages, du mode batch, de la composabilité ModelBuilder, et arcpy scripting — un écosystème qu'aucun dialogue personnalisé ne pourrait jamais recréer.

Mais cet écosystème est livré avec exactement une interface utilisateur : le volet de géotraitement auto-généré. Il n'existe aucune manière prise en charge pour qu'un outil tiers présente une autre interface utilisateur tout en restant un véritable outil de géotraitement. Pour les outils simples, le volet généré convient. Pour des flux de travail interactifs et riches en retours, il est très limitant, et les développeurs font face à un choix inutile :

• Rester un outil GP et accepter les limites du volet généré (pas de widgets personnalisés, pas d'aperçus en direct, contrôle limité de la mise en page, et une longue liste de bizarreries liées à la validation), ou
• Créer un dockpane/fenêtre personnalisé avec exactement l'interface utilisateur souhaitée — et perdre complètement l'historique du géotraitement, les environnements, ModelBuilder, le mode batch et le scripting.

Les propres flux interactifs phares d'Esri démontrent le problème : Suitability Modeler, image Classification Wizard et Georeferencing sont tous des volets personnalisés, pas des dialogues de géotraitement générés. Quand une interaction riche est importante, Esri contourne le volet GP. Les développeurs tiers n'ont aucun moyen pris en charge pour faire de même sans abandonner le cadre de géotraitement.

Amélioration demandée

Dissocier l'interface utilisateur de l'outil. Deux niveaux, chacun représentant une avancée majeure :

Niveau 1 — dialogues d'outil personnalisés (la demande complète). Permettre à un add-in d'enregistrer un dialogue/volet WPF comme interface Pro pour un outil spécifique de géotraitement (outil script, .pyt, ou .atbx). L'outil reste un outil GP de première classe à tous égards :

• Le dialogue personnalisé recueille et valide les paramètres, puis transmet un tableau standard de paramètres au pipeline d'exécution GP normal — ainsi l'exécution est enregistrée dans l'historique du géotraitement, respecte les paramètres d'environnement, rapporte la progression/les messages et ajoute les métadonnées exactement comme aujourd'hui.
• Les contextes qui ne peuvent pas héberger le dialogue personnalisé — ModelBuilder, mode batch, exécutions planifiées, publication serveur, arcpy — basculent automatiquement vers le volet auto-généré et les objets paramètre existants. Rien ne casse.
• Si aucun dialogue personnalisé n'est enregistré, le comportement est exactement celui d'aujourd'hui (entièrement rétrocompatible).

Niveau 2 — contrôles de paramètres personnalisés (une demande plus petite mais toujours transformative). Permettre à un développeur d'enregistrer un contrôle WPF personnalisé pour un paramètre individuel (ou un type de paramètre personnalisé), hébergé dans le volet généré. Cela éliminerait déjà la plupart des difficultés : une table de valeurs pourrait devenir une vraie grille avec retour en temps réel ; un paramètre remap pourrait afficher un histogramme du raster d'entrée ; un seuil pourrait montrer quelles cellules il sélectionne.

Pourquoi c'est important

Les boîtes à outils Python personnalisées sont une voie d'extensibilité de premier ordre pour ArcGIS Pro, et les organisations ainsi que les tiers construisent dessus des suites d'analyse sérieuses et commerciales. La qualité de ce que l'utilisateur voit est limitée non par l'effort du développeur mais par le volet généré. Les développeurs soucieux de l'expérience utilisateur sont poussés à abandonner le cadre du géotraitement — perdant ainsi la traçabilité, la reproductibilité et la scriptabilité, qui sont précisément ce qui rend les outils Pro fiables. Un point d'extensibilité UI pris en charge mettrait fin à ce compromis, élèverait le niveau qualitatif de tout l'écosystème tiers et ne coûterait rien en compatibilité ascendante.

JeffJenness

Concrete limitations met while building one real toolbox — all encountered (and independently reproducible) while porting a large wildlife-analysis toolset to a Python toolbox in ArcGIS Pro 3.7. Each is livable alone; together they show why a supported custom-UI path is needed. Items marked ◆ are also candidates for individual bug reports via My Esri support.

1. ◆ Value-table cell marshaling is inconsistent and undocumented. During dialog validation, a GPValueTable cell holding a map layer or table arrives as the bare display-name text when dragged in, but as a wrapper object (MappingLayerObject / MappingTableObject) whose str() is only a repr (<MappingTableObject object at 0x…>) when picked from the cell's dropdown. Validation code must defensively handle both; naive str() use produces false "does not exist" errors.
2. ◆ No supported project access during validation. arcpy.mp.ArcGISProject("CURRENT") is unreliable/unsupported in updateParameters, so a tool cannot resolve a layer name to its data source to drive smart defaults (e.g., suggesting a companion table that sits beside the input raster in a geodatabase).
3. No opt-out of framework output auto-naming. When the first input changes, Pro fills an empty required output with <first input>_<tool name>. For multi-input tools the first input is often not what the output is about (e.g., one habitat factor out of six), so the suggestion is reliably wrong — and the tool cannot suppress it.
4. No way to set the Browse dialog's starting location per parameter, even when the tool knows exactly where the relevant files live.
5. "Suggest once, let the user clear it" requires an undocumented idiom. .altered does not distinguish a user-cleared value, so usable auto-defaults hinge on the undocumented hasBeenValidated behavior.
6. ◆ A disabled output parameter that still holds a value gets its dataset deleted on Run (overwrite-output pre-delete runs before execute()), even though the parameter is disabled — a data-loss trap for mode-toggle dialogs.
7. No show/hide for parameters, and limited layout control. Category groups always render below all uncategorized parameters, and categories default to collapsed; a parameter cannot be hidden when a mode makes it irrelevant.
8. Empty value-table rows added with "Add another" are pruned whenever the pane refreshes or loses focus, so a user cannot click Browse in a freshly added row — and dragging a layer onto the control does not append a row either. The cell dropdowns are the only reliable way to add a row.
9. Raster inputs can surface as CIMPATH=…/….json URIs in .valueAsText that arcpy.Describe/CopyRaster reject, requiring resolution through the value object instead.
10. No custom widgets of any kind. No histogram or preview of an input raster, no live chart, no color swatches, no rich text. In our suite, an interactive remap-table builder had to be written as a fully custom add-in window — losing geoprocessing history for that step — because the pane simply cannot host it.
11. The multivalue value-list control always offers "Select All," even when selecting everything is semantically wrong — a geographic-transformation list where exactly one entry per datum pair is meaningful, say. No toolbox property suppresses or renames it.
12. ◆ Geometry filters cannot be applied to mixed raster/feature parameters. Parameter.filter.list = ["Polygon"] works on a feature-only composite (["GPFeatureLayer", "DEFeatureClass"]), but raises NameError: The attribute 'list' is not supported on this instance of Filter the moment raster types join the composite (["GPFeatureLayer", "GPRasterLayer", "DEFeatureClass", "DERasterDataset"] — the natural datatype for a tool that combines polygon layers AND rasters in one multivalue list). Consequence: a polyline or point layer cannot be refused at drag-in or browse time; the only available protection is an error posted from updateMessages, which does block Run but only after the wrong layer already sits in the list — and which the developer must remember to re-post on every validation cycle, since messages are cleared each pass.

Why existing workarounds don't substitute: a custom window that calls processing code directly orphans the run from history, environments, and scripting; a custom window that wraps the GP tool via ExecuteToolAsync preserves those but forces the developer to build and maintain two UIs per tool, and ModelBuilder users still see only the generated pane. Both paths exist precisely because the supported one is missing.

I'm happy to file the ◆ items individually via My Esri support and cite this idea as the systemic fix, if that's useful — let me know.