Applicare il controllo versione ai modelli ArcGIS ModelBuilder?

Il controllo della versione è uno strumento indispensabile per lo sviluppo del software, che consente di fare un passo indietro nel tempo in modo affidabile e pulito all'ultima volta in cui X ha fatto il suo lavoro esattamente, o per vedere cosa è cambiato tra allora e ora, in genere utilizzato quando si cerca di capire perché X non funziona più esattamente.

Tuttavia, tutti gli strumenti che conosco per questo lavoro funzionano solo su file di testo semplice. Toolbox (quelli standard, non quelli di Python introdotti in 10.1), e quindi i loro modelli, sono binari. Qualcuno ha un metodo praticabile per portare il versioning a loro?

Nota: il controllo delle versioni è diverso dal backup . Ci sono un certo numero di metodi semplici per creare istantanee di file per una particolare data / ora - di backup di Windows, le versioni precedenti , xcopy /s d:\foobar\ x:\foobar_%date%,zip stuff_%date%.zip stuff\* e così via.

Applicare uno strumento come git , fossil , mercurial , sovversione o ... a un file binario è un passo in più rispetto all'utilizzo di xcopy o zip in quanto si può aggiungere un messaggio di commit "Il modello foobar% date% ora sovrascrive precedente risulta solo se Baz non esiste " , ma è ancora anemico rispetto a ciò che lo stesso set di strumenti può fare applicato ai file di testo: ad esempio, mostrami esattamente cosa è cambiato tra l'anno scorso e oggi .

Tutti i software di controllo della versione mainstream, sia esso il controllo centrale della versione centrale come SVN o soluzioni distribuite come Git, Mercurial, Bazaar ecc. Consentono l'archiviazione di file binari. Sono tutti abbastanza efficaci sia dal punto di vista delle prestazioni che in termini di spazio occupato.

L'ispezione delle differenze tra le revisioni / versioni di un file è ovviamente una storia diversa. Non c'è molto che puoi fare quando vuoi confrontare i modelli ArcGIS, che in effetti sono binari. Non conosco strumenti diff per i modelli, dubito che ce ne saranno perché la maggior parte delle persone non ha bisogno di questa specifica funzionalità.

Attualmente ho il flusso di lavoro di ArcCatalog: apertura della casella degli strumenti> selezione del modello> modifica> file> esportazione> su Python , passaggio allo strumento SCM > aggiornamento modifiche> commit modifiche (immissione commento registro) .

È ingombrante, quindi non lo faccio molto, e quindi perdo molti dei vantaggi del controllo delle versioni.

ModelBuilder è vecchio, goffo e non ottiene aggiornamenti significativi con ArcGIS Pro, se questo tweet è indicativo. Non ne sono mai stato un grande fan (anche se a malincuore lo uso ancora quando devo), quindi potresti considerare questa risposta come un elusione della domanda e una raccomandazione a guardare le alternative .

FME è probabilmente l'alternativa ModelBuilder più ovvia, in quanto ha un UI di diagramma di flusso simile. Un vantaggio rilevante è che i suoi documenti sono in formato testo normale, quindi possono differire (anche se spesso c'è un sacco di cruft insignificanti e generati automaticamente che devi imparare a ignorare). È un software commerciale, tuttavia, per alcuni il suo costo potrebbe essere irraggiungibile.

Altri che ho meno familiarità includono Orfeo Toolbox , Whitebox Geospatial Analysis Tools e il modellatore grafico di QGIS (basato su SEXTANTE ). Questi sono tutti ambienti di modellazione open source con GUI.

Una grande spinta che ho osservato al GIS e alle conferenze sui dati aperti negli ultimi anni è verso l'idea di "ricerca riproducibile", ovvero dati e processi che possono essere facilmente condivisi e riprodotti da altri. Ciò significa spesso utilizzare formati di dati aperti, software open source e repository condivisi. Python e R sono molto popolari per questo.

Pensavo che la presentazione di Dharhas Pothina su Python e GIS all'inizio di quest'anno fosse un valido argomento per questo. Concordo abbastanza fermamente sul fatto che l'eccessiva dipendenza da una GUI sia dannosa per la riproducibilità. Con il codice, a patto che tu abbia familiarità con la lingua, puoi scansionarla abbastanza rapidamente e capire cosa sta succedendo, mentre con una GUI devi fare clic e scorrere molte finestre diverse, spesso annidate l'una nell'altra , per ottenere valori e impostazioni.

Certamente, c'è un compromesso qui, ma a mio avviso, chiunque stia facendo un lavoro serio (ricerca scientifica, elaborazione delle politiche, ecc.) Dovrebbe usare strumenti che facilitino la riproducibilità.

Mi dispiace che questo non risponda direttamente alla tua domanda (anche se non credo che ci sia una risposta facile).

L'introduzione di Python cassette in ArcGIS 10.1 for Desktop invalida la sua dichiarazione di quattro anni che tutti :

Le cassette degli attrezzi, e quindi i loro modelli, sono binarie.

Le caselle degli strumenti standard sono binarie ma le caselle degli strumenti Python (* .pyt) sono file di testo.

Di conseguenza, penso che le caselle degli strumenti di Python debbano essere prese in considerazione se il controllo della versione del codice sorgente supera i requisiti per una GUI per la creazione di modelli.

Ne sei consapevole dalla tua risposta su Perché apprendere / usare Python Toolboxes su Python Script Tools? ma ho pensato di includerlo qui come una risposta in modo che l'opzione di utilizzare le caselle degli strumenti di Python (per ottenere un facile accesso al controllo della versione) piuttosto che le caselle degli strumenti standard non venga trascurata dai futuri lettori di queste domande e risposte.

In molti modi, sono davvero felice che ESRI non abbia revisionato l'intero Geoprocessing Framework e Modelbuilder con il passaggio ad ArcGIS Pro. Ci sono molte organizzazioni (di ricerca) che hanno investito molto nella costruzione di modelli personalizzati giganti che senza dubbio avrebbero bisogno di una revisione completa se ESRI avesse rotto la compatibilità.

Come con la transizione a Python / Geoprocessing dallo sfondo delle macro Arc / Info AML, ciò indubbiamente significherebbe un impatto enorme e molte persone in perdita. Anche circa 5-8 anni dopo la prima uscita di ArcGIS, c'erano ancora ricercatori e organizzazioni governative che occasionalmente si riferivano a modelli AML su forum come questo, che non erano ancora stati in grado di convertire in Python, a causa del tempo, dei soldi o altri vincoli. Questo dimostra solo il potenziale impatto di tale transizione, che senza dubbio sarebbe enorme.

Sono d'accordo che ModelBuilder può essere "goffo" a volte se non lo conosci bene, ma da quando ho davvero iniziato a imparare Python e ho iniziato a capire la programmazione di validazione degli strumenti ( http://resources.arcgis.com/en/help/main /10.2/index.html#//00150000000v000000 ), gran parte del "dolore" è stato alleviato. Ora capisco meglio alcuni dei messaggi di errore "criptici" che possono essere generati dalla convalida dello strumento, lasciandoti in perdita su quale parte del modello è rotta e ora posso ripararli in modo più efficace o prevenirli scrivendo il codice di convalida dello strumento corretto . Ciò è particolarmente utile quando si "integrano" toolbox / modelli non Python con script Python.

Un desiderio, sebbene lo sia ancora, e che renderebbe la vita con ModelBuilder moltopiù semplice, è se la convalida automatica degli strumenti evidenzia effettivamente gli strumenti e apre automaticamente i modelli, causando avvisi o errori relativi alle variabili. In alternativa, almeno, gli elenchi di errori e avvisi che compaiono dopo aver fatto clic su "OK" su un modello non valido, dovrebbero includere il nome esatto dello strumento e il nome del modello, in cui lo strumento risiede che non è valido. Se hai molti modelli nidificati, trovare lo strumento che ha causato un particolare errore di convalida, a volte può essere noioso con solo un elenco di errori che non include lo strumento o il (sotto) modello ma solo il nome della variabile non valido. In realtà non so perché ESRI non abbia incluso lo strumento e il nome del modello nell'elenco, sembra una soluzione semplice a questo problema.

Inoltre, sarebbe utile una sorta di funzionalità "Cerca", per trovare gli strumenti per nome come definito nei modelli.