Aplicando controle de versão aos modelos do ArcGIS ModelBuilder?

O controle de versão é uma ferramenta indispensável para o desenvolvimento de software, permitindo retroceder de forma confiável e limpa no tempo até a última vez em que X fez seu trabalho exatamente certo, ou para ver o que mudou entre então e agora - normalmente usado ao tentar descobrir por que X não está mais funcionando exatamente certo.

No entanto, todas as ferramentas que conheço para este trabalho apenas em arquivos de texto sem formatação. Caixas de ferramentas (caixas padrão, não as caixas de ferramentas python introduzidas na 10.1) e, portanto, seus modelos, são binários. Alguém tem um método viável para trazer versões para eles?

Nota: o controle de versão é diferente do backup . Há um sem número de métodos simples para criar instantâneos de arquivos para uma determinada data / hora - de backup do Windows, versões anteriores , xcopy /s d:\foobar\ x:\foobar_%date%, zip stuff_%date%.zip stuff\*, e assim por diante.

A aplicação de uma ferramenta como git , fossil , mercurial , subversion ou ... a um arquivo binário é um passo melhor do que usar xcopy ou zip, pois é possível adicionar uma mensagem de confirmação: "Model foobar% date% agora substitui anterior resulta apenas se o Baz não existir " , mas ainda é anêmico comparado ao que esse mesmo conjunto de ferramentas pode fazer aplicado aos arquivos de texto: por exemplo, mostre-me exatamente o que foi alterado entre o ano passado e hoje .

Todo software de controle de versão convencional, seja o controle central de versão central como SVN ou soluções distribuídas como Git, Mercurial, Bazaar etc., permite o armazenamento de arquivos binários. Todos eles são bastante eficazes tanto em termos de desempenho quanto em termos de espaço ocupado.

Inspecionar diferenças entre revisões / versões de um arquivo é obviamente uma história diferente. Não há muito o que fazer quando você deseja comparar os modelos ArcGIS, que de fato são binários. Não conheço nenhuma ferramenta diff para modelos, duvido que exista, já que a maioria das pessoas não precisa dessa funcionalidade específica.

Atualmente, tenho o fluxo de trabalho do ArcCatalog: abrindo a caixa de ferramentas> selecionando modelo> edição> arquivo> exportar> para python , alterne para a ferramenta SCM > atualize as alterações> confirme as alterações (insira o comentário do log) .

É complicado, então eu não faço muito e, assim, perco muitos dos benefícios do controle de versão.

O ModelBuilder é antigo, desajeitado e não está recebendo atualizações significativas no ArcGIS Pro, se este tweet for alguma indicação. Eu nunca fui um grande fã dele (apesar de relutantemente ainda usá-lo quando preciso), então você pode considerar essa resposta como um desvio da pergunta e uma recomendação para procurar alternativas .

O FME é sem dúvida a alternativa mais óbvia do ModelBuilder, pois possui uma interface do usuário de diagrama de fluxo semelhante. Uma vantagem relevante é que seus documentos estão no formato de texto sem formatação, para que possam diferir (embora muitas vezes exista um monte de itens gerados automaticamente sem sentido que você precise aprender a ignorar). Porém, como é um software comercial, seu custo pode estar fora do alcance de alguns.

Outros com os quais estou menos familiarizado incluem o Orfeo Toolbox , o Whitebox Geospatial Analysis Tools e o modelador gráfico do QGIS (baseado no SEXTANTE ). Todos esses são ambientes de modelagem de código aberto com GUIs.

Um grande impulso que observei no GIS e nas conferências de dados abertos nos últimos anos é a idéia de "pesquisa reproduzível", isto é, dados e processos que podem ser facilmente compartilhados e reproduzidos por outros. Isso geralmente significa usar formatos de dados abertos, software de código aberto e repositórios compartilhados. Python e R são muito populares para isso.

Eu pensei que a apresentação de Dharhas Pothina sobre Python e GIS no início deste ano fez um bom argumento para isso. Concordo plenamente que o excesso de confiança em uma GUI é prejudicial à reprodutibilidade. Com o código, desde que você esteja familiarizado com o idioma, você pode digitalizá-lo rapidamente e descobrir o que está acontecendo, enquanto que com uma GUI, é necessário clicar e rolar por várias janelas diferentes, geralmente aninhadas uma na outra , para obter valores e configurações.

Certamente, existe uma troca aqui, mas, na minha opinião, qualquer pessoa que esteja realizando um trabalho sério (pesquisa científica, formulação de políticas etc.) deve usar ferramentas que facilitem a reprodutibilidade.

Lamentamos, mas isso não responde diretamente à sua pergunta (embora eu não acredite que exista uma resposta fácil).

A introdução de Python caixas de ferramentas no ArcGIS 10.1 for Desktop invalida a sua declaração de quatro anos que tudo :

As caixas de ferramentas e, portanto, seus modelos, são binários.

As caixas de ferramentas padrão são binárias, mas as caixas de ferramentas Python (* .pyt) são arquivos de texto.

Consequentemente, acho que as caixas de ferramentas Python devem ser consideradas se o controle de versão do código-fonte superar o requisito de uma GUI de criação de modelo.

Você está ciente disso com a sua resposta em Por que aprender / usar as Caixas de Ferramentas Python em vez das Ferramentas de Script Python? mas achei que deveria incluir isso como resposta aqui, para que a opção de usar as caixas de ferramentas Python (para obter fácil acesso ao controle de versão) em vez das caixas de ferramentas Padrão não seja ignorada pelos futuros leitores dessas perguntas e respostas.

De muitas maneiras, estou realmente satisfeito por a ESRI não ter revisado todo o Geoprocessing Framework e Modelbuilder com a transição para o ArcGIS Pro. Existem muitas organizações (de pesquisa) que investiram pesadamente na construção de modelos personalizados gigantes que, sem dúvida, precisariam de uma revisão completa se a ESRI tivesse quebrado a compatibilidade.

Assim como na transição para o Python / Geoprocessamento do plano de fundo das macros Arc / Info AML, isso sem dúvida significaria um impacto gigante e muitas pessoas perdidas. Mesmo entre 5 e 8 anos após o primeiro lançamento do ArcGIS, ainda havia pesquisadores e organizações governamentais ocasionalmente se referindo a modelos de LBC em fóruns como este, que ainda não haviam sido capazes de converter para Python, devido a tempo, dinheiro ou dinheiro. outras restrições. Isso apenas ilustra o impacto potencial dessa transição, que sem dúvida seria enorme.

Concordo que o ModelBuilder pode ser "desajeitado" às vezes, se você não o conhece bem, mas desde que eu realmente comecei a aprender Python e comecei a entender a programação de Validação de Ferramenta ( http://resources.arcgis.com/en/help/main /10.2/index.html#//00150000000v000000 ), grande parte da "dor" foi revivida. Agora, entendo muito melhor algumas das mensagens de erro "enigmáticas" que a validação pode exibir e deixo você sem saber qual parte do modelo está quebrada, e agora posso corrigi-las ou evitá-las com mais eficiência, escrevendo o código de validação de ferramenta adequado . Isso é especialmente valioso ao "integrar" modelos / caixas de ferramentas não-Python com scripts Python.

Um desejo que eu ainda tenho, e que tornaria a vida com o ModelBuilder muitomais fácil, é se a validação automática de fato destacou as ferramentas e abriu automaticamente os modelos, que causam os avisos ou erros relacionados às variáveis. Como alternativa, no mínimo, as listagens de erro e aviso que aparecem quando você clica em "OK" em um modelo inválido devem incluir o nome exato da ferramenta e o nome do modelo, onde reside a ferramenta inválida. Se você possui muitos modelos aninhados, encontrar a ferramenta que causou um erro de validação específico pode ser entediante às vezes com apenas uma lista de erros que não incluem a ferramenta ou o (sub) nome do modelo, mas apenas o nome da variável inválida. Na verdade, não sei por que a ESRI não incluiu o nome da ferramenta e do modelo na listagem, parece uma solução fácil para esse problema.

Além disso, um tipo de funcionalidade "Pesquisar", para encontrar ferramentas por nome, conforme definido nos modelos, seria útil.