Appliquer le contrôle de version aux modèles ArcGIS ModelBuilder?

Le contrôle de version est un outil indispensable pour le développement de logiciels, permettant de remonter dans le temps de manière fiable et propre jusqu'à la dernière fois que X a fait son travail correctement, ou pour voir ce qui a changé entre hier et maintenant - généralement utilisé pour essayer de comprendre pourquoi X ne fonctionne plus exactement correctement.

Cependant, tous les outils que je connais pour ce travail ne concernent que les fichiers en texte brut. Les boîtes à outils (celles standard, pas les boîtes à outils python introduites dans 10.1), et donc leurs modèles, sont binaires. Quelqu'un a-t-il une méthode pratique pour lui apporter des versions?

Remarque: le versioning est différent de la sauvegarde . Il y a un certain nombre de méthodes simples pour créer des instantanés de fichiers pour une date donnée / heure - sauvegarde Windows, les versions précédentes , xcopy /s d:\foobar\ x:\foobar_%date%, zip stuff_%date%.zip stuff\*et ainsi de suite.

Appliquer un outil tel que git , fossile , mercurial , subversion , ou ... à un fichier binaire est une étape meilleure que d'utiliser xcopy ou zip dans la mesure où l'on peut ajouter un message de validation, "Le modèle foobar% date% remplace désormais le précédent ne résulte que si Baz n'existe pas " , mais reste anémique par rapport à ce que ce même ensemble d'outils peut faire appliqué aux fichiers texte: par exemple, montrez-moi exactement ce qui a changé entre l'année dernière et aujourd'hui .

Tous les logiciels de contrôle de version traditionnels, que ce soit le contrôle de version central central comme SVN ou des solutions distribuées comme Git, Mercurial, Bazaar, etc. permettent le stockage de fichiers binaires. Ils sont tous assez efficaces à la fois en termes de performances et en termes d'espace occupé.

L'inspection des différences entre les révisions / versions d'un fichier est bien sûr une histoire différente. Vous ne pouvez pas faire grand-chose lorsque vous souhaitez comparer des modèles ArcGIS, qui sont en effet binaires. Je ne connais pas d'outils de diff pour les modèles, je doute qu'il y en aura car la plupart des gens n'ont pas besoin de cette fonctionnalité spécifique.

Actuellement, j'ai le flux de travail d' ArcCatalog: ouverture de la boîte à outils> sélection du modèle> édition> fichier> exportation> vers python , basculer vers l'outil SCM > actualiser les modifications> valider les modifications (entrer le commentaire du journal) .

C'est encombrant, donc je ne le fais pas tellement, et je perds ainsi de nombreux avantages du versioning.

ModelBuilder est ancien, maladroit et ne reçoit aucune mise à jour significative avec ArcGIS Pro, si ce tweet est une indication. Je n'en ai jamais été un grand fan (bien que je l'utilise toujours à contrecœur quand je le dois), vous pouvez donc considérer cette réponse comme un contournement de la question et une recommandation de rechercher des alternatives .

FME est sans doute l'alternative ModelBuilder la plus évidente, car il a une interface utilisateur de diagramme de flux similaire. Un avantage pertinent est que ses documents sont au format texte brut, de sorte qu'ils peuvent différer (bien qu'il y ait souvent beaucoup de dépotoirs sans signification et générés automatiquement que vous devez apprendre à ignorer). Il s'agit cependant d'un logiciel commercial, donc son coût peut être hors de portée pour certains.

D'autres que je connais moins comprennent Orfeo Toolbox , Whitebox Geospatial Analysis Tools et le modeleur graphique de QGIS (basé sur SEXTANTE ). Ce sont tous des environnements de modélisation open source avec des interfaces graphiques.

Une grande poussée que j'ai observée au SIG et lors de conférences de données ouvertes ces dernières années est vers l'idée de "recherche reproductible", c'est-à-dire des données et des processus qui peuvent être facilement partagés avec et reproduits par d'autres. Cela signifie souvent utiliser des formats de données ouverts, des logiciels open source et des référentiels partagés. Python et R sont très populaires pour cela.

Je pensais que la présentation de Dharhas Pothina sur Python et SIG au début de cette année constituait un bon argument pour cela. Je suis tout à fait d'accord pour dire qu'une dépendance excessive à l'égard d'une interface graphique nuit à la reproductibilité. Avec le code, tant que vous êtes familier avec le langage, vous pouvez le parcourir assez rapidement et comprendre ce qui se passe, tandis qu'avec une interface graphique, vous devez cliquer et faire défiler de nombreuses fenêtres différentes, souvent imbriquées profondément les unes dans les autres. , pour obtenir des valeurs et des paramètres.

Certes, il y a un compromis ici, mais à mon avis, quiconque fait un travail sérieux (recherche scientifique, élaboration de politiques, etc.) devrait utiliser des outils qui facilitent la reproductibilité.

Désolé que cela ne réponde pas directement à votre question (bien que je ne pense pas qu'il existe une réponse facile).

L'introduction de Python dans ArcGIS 10.1 boîtes à outils pour votre bureau déclaration invalide de quatre ans que tous :

Les boîtes à outils, et donc leurs modèles, sont binaires.

Les boîtes à outils standard sont binaires mais les boîtes à outils Python (* .pyt) sont des fichiers texte.

Par conséquent, je pense que les boîtes à outils Python devraient être considérées si le contrôle de version du code source l'emporte sur l'exigence d'une interface graphique de création de modèle.

Vous en êtes conscient dans votre réponse sur Pourquoi apprendre / utiliser les boîtes à outils Python sur les outils de script Python? mais j'ai pensé que je devrais inclure cela comme une réponse ici afin que l'option d'utiliser des boîtes à outils Python (pour accéder facilement au contrôle de version) plutôt que des boîtes à outils standard ne soit pas négligée par les futurs lecteurs de ce Q&R.

À bien des égards, je suis vraiment heureux qu'ESRI n'ait pas révisé l'intégralité du cadre de géotraitement et de Modelbuilder avec la transition vers ArcGIS Pro. Il existe de nombreuses organisations (de recherche) qui ont investi massivement dans la construction de modèles personnalisés géants qui auraient sans aucun doute besoin d'une refonte complète si ESRI avait rompu la compatibilité.

Comme pour la transition vers Python / Géotraitement depuis l'arrière-plan des macros Arc / Info AML, cela signifierait sans aucun doute un impact géant et de nombreuses personnes à perte. Même environ 5 à 8 ans après la première version d'ArcGIS, il y avait encore des chercheurs et des organisations gouvernementales faisant parfois référence à des modèles AML sur des forums comme celui-ci, qu'ils n'avaient pas encore pu convertir en Python, en raison du temps, de l'argent ou d'autres contraintes. Cela illustre simplement l'impact potentiel d'une telle transition, qui serait sans aucun doute énorme.

Je suis d'accord que ModelBuilder peut être "maladroit" parfois si vous ne le connaissez pas bien, mais depuis que j'ai vraiment commencé à apprendre Python et commencé à comprendre la programmation de la validation des outils ( http://resources.arcgis.com/en/help/main /10.2/index.html#//00150000000v000000 ), une grande partie de la "douleur" a été soulagée. Je comprends maintenant mieux certains des messages d'erreur "cryptiques" que la validation d'outils peut générer et je ne sais plus quelle partie du modèle est cassée, et je peux maintenant les corriger plus efficacement ou les empêcher en écrivant le code de validation d'outil approprié . Ceci est particulièrement utile lors de l '"intégration" de boîtes à outils / modèles non Python avec des scripts Python.

Un souhait bien que j'aie encore, et cela rendrait la vie avec ModelBuilder beaucoupplus facile, c'est si la validation automatique des outils a effectivement mis en évidence les outils et ouvert automatiquement les modèles, ce qui provoque les avertissements ou les erreurs liés aux variables. Alternativement, au minimum, les listes d'erreurs et d'avertissements qui apparaissent une fois que vous avez cliqué sur "OK" sur un modèle non valide, doivent inclure le nom exact de l'outil et le nom du modèle, où réside l'outil, qui n'est pas valide. Si vous avez de nombreux modèles imbriqués, trouver l'outil qui a provoqué une erreur de validation particulière peut parfois être fastidieux avec juste une liste d'erreurs qui n'inclut pas l'outil ou le nom du (sous-) modèle mais seulement le nom de variable non valide. Je ne sais vraiment pas pourquoi ESRI n'a pas inclus le nom de l'outil et du modèle dans la liste, cela semble être une solution facile à ce problème.

En outre, une sorte de fonctionnalité de «recherche», pour trouver des outils par nom tel que défini dans les modèles, serait pratique.