¿Aplica el control de versiones a los modelos de ArcGIS ModelBuilder?

El control de versiones es una herramienta indispensable para el desarrollo de software, ya que permite retroceder de manera confiable y limpia en el tiempo hasta la última vez que X hizo su trabajo exactamente bien, o para ver qué cambió entre entonces y ahora, generalmente utilizado al tratar de averiguar por qué X ya no funciona exactamente bien.

Sin embargo, todas las herramientas que conozco para este trabajo solo funcionan en archivos de texto sin formato. Las cajas de herramientas (estándar, no las cajas de herramientas de Python introducidas en 10.1) y, por lo tanto, sus modelos, son binarias. ¿Alguien tiene un método viable para llevar versiones a ellos?

Nota: el control de versiones es diferente de la copia de seguridad . Hay un gran número de métodos simples para crear instantáneas de archivos para una fecha / hora determinada - Copia de seguridad de Windows, versiones anteriores , xcopy /s d:\foobar\ x:\foobar_%date%, zip stuff_%date%.zip stuff\*, y así sucesivamente.

Aplicar una herramienta como git , fósil , mercurial , subversión o ... a un archivo binario es un paso mejor que usar xcopy o zip para poder agregar un mensaje de confirmación, "El modelo foobar% date% ahora sobrescribe el anterior resultados solo si Baz no existe " , pero sigue siendo anémico en comparación con lo que ese mismo conjunto de herramientas puede hacer aplicado a los archivos de texto: por ejemplo, muéstrame exactamente lo que se cambió entre el año pasado y hoy .

Cada software de control de versiones convencional, ya sea el control de versiones central y central como SVN o soluciones distribuidas como Git, Mercurial, Bazaar, etc., permite el almacenamiento de archivos binarios. Todos son bastante efectivos tanto en términos de rendimiento como también en términos de espacio ocupado.

Inspeccionar las diferencias entre las revisiones / versiones de un archivo es, por supuesto, una historia diferente. No hay mucho que pueda hacer cuando quiera comparar los modelos de ArcGIS, que de hecho son binarios. No conozco ninguna herramienta de diferencias para los modelos, dudo que haya alguna, ya que la mayoría de las personas no necesitan esta funcionalidad específica.

Actualmente tengo el flujo de trabajo de ArcCatalog: abrir caja de herramientas> seleccionar modelo> editar> archivo> exportar> a python , cambiar a herramienta SCM > actualizar cambios> confirmar cambios (ingresar comentario de registro) .

Es engorroso, así que no lo hago tanto y, por lo tanto, pierdo muchos de los beneficios del versionado.

ModelBuilder es antiguo, torpe y no recibe actualizaciones significativas con ArcGIS Pro, si este tweet es una indicación. Nunca he sido un gran admirador de él (aunque de mala gana todavía lo uso cuando tengo que hacerlo), por lo que podría considerar esta respuesta como un paso al margen de la pregunta y una recomendación para buscar alternativas .

FME es posiblemente la alternativa más obvia de ModelBuilder, ya que tiene una interfaz de usuario de diagrama de flujo similar. Una ventaja relevante es que sus documentos están en formato de texto plano, por lo que pueden diferir (aunque a menudo hay una gran cantidad de información sin sentido y generada automáticamente que debe aprender a ignorar). Sin embargo, es un software comercial, por lo que su costo puede estar fuera del alcance de algunos.

Otros con los que estoy menos familiarizado incluyen Orfeo Toolbox , Whitebox Geospatial Analysis Tools y el modelador gráfico de QGIS (basado en SEXTANTE ). Todos estos son entornos de modelado de código abierto con GUI.

Un gran impulso que he observado en SIG y conferencias de datos abiertos en los últimos años es hacia la idea de "investigación reproducible", es decir, datos y procesos que otros puedan compartir y reproducir fácilmente. Eso a menudo significa usar formatos de datos abiertos, software de código abierto y repositorios compartidos. Python y R son muy populares para esto.

Pensé que la presentación de Dharhas Pothina sobre Python y GIS a principios de este año era un buen argumento para esto. Estoy totalmente de acuerdo en que la dependencia excesiva de una GUI es perjudicial para la reproducibilidad. Con el código, siempre y cuando esté familiarizado con el idioma, puede escanearlo con bastante rapidez y descubrir qué está sucediendo, mientras que con una GUI debe hacer clic y desplazarse por muchas ventanas diferentes, a menudo anidadas entre sí. , para obtener valores y configuraciones.

Ciertamente, hay una compensación aquí, pero en mi opinión, cualquiera que haga un trabajo serio (investigación científica, formulación de políticas, etc.) debería usar herramientas que faciliten la reproducibilidad.

Lamento que esto no responda su pregunta directamente (aunque no creo que haya una respuesta fácil).

La introducción de las cajas de herramientas de Python en ArcGIS 10.1 for Desktop invalida su declaración de cuatro años de que todos :

Las cajas de herramientas, y por lo tanto sus modelos, son binarias.

Las cajas de herramientas estándar son binarias, pero las cajas de herramientas de Python (* .pyt) son archivos de texto.

En consecuencia, creo que las cajas de herramientas de Python deberían considerarse si el control de versión del código fuente supera el requisito de una GUI de construcción de modelos.

Usted es consciente de esto por su respuesta en ¿Por qué aprender / usar Python Toolboxes sobre Python Script Tools? pero pensé que debería incluir esto como respuesta aquí para que los futuros lectores de estas preguntas y respuestas no pasen por alto la opción de usar las cajas de herramientas de Python (para obtener un fácil acceso al control de versiones) en lugar de las cajas de herramientas estándar.

En muchos sentidos, me alegro de que ESRI no haya revisado todo el Framework de Geoprocesamiento y Modelbuilder con la transición a ArcGIS Pro. Hay muchas organizaciones (de investigación) que invirtieron mucho en la construcción de modelos personalizados gigantes que sin duda necesitarían una revisión completa si ESRI hubiera roto la compatibilidad.

Al igual que con la transición a Python / Geoprocesamiento desde el fondo de las macros Arc / Info AML, esto sin duda significaría un impacto gigante y muchas personas en pérdida. Incluso unos 5 a 8 años después del primer lanzamiento de ArcGIS, todavía había investigadores y organizaciones gubernamentales que ocasionalmente se referían a modelos AML en foros como este, que aún no habían podido convertir a Python, debido al tiempo, dinero o Otras limitaciones. Esto solo ilustra el impacto potencial de tal transición, que sin duda sería enorme.

Estoy de acuerdo en que ModelBuilder puede ser "torpe" a veces si no lo conoce bien, pero como realmente comencé a aprender Python y comencé a comprender la programación de Validación de herramientas ( http://resources.arcgis.com/en/help/main /10.2/index.html#//00150000000v000000 ), gran parte del "dolor" ha sido liberado. Ahora entiendo mejor algunos de los mensajes de error "crípticos" que la validación de herramientas puede generar, y lo deja perdido en cuanto a qué parte del modelo está rota, y ahora puedo corregirlos o prevenirlos de manera más efectiva escribiendo el código de validación de herramienta adecuado . Esto es especialmente valioso cuando se "integran" cajas de herramientas / modelos que no son de Python con scripts de Python.

Un deseo todavía tengo, y que haría la vida con ModelBuilder muchoes más fácil si la validación automática de herramientas resalta las herramientas y abre automáticamente los modelos, que causan las advertencias o errores relacionados con las variables. Alternativamente, como mínimo, los listados de error y advertencia que aparecen una vez que hace clic en "Aceptar" en un modelo no válido, deben incluir el nombre exacto de la herramienta y el nombre del modelo, donde reside la herramienta que no es válida. Si tiene muchos modelos anidados, encontrar la herramienta que causó un error de validación particular puede ser tedioso a veces con solo una lista de errores que no incluye la herramienta o el nombre del (sub) modelo, sino solo el nombre de la variable no válida. De hecho, no sé por qué ESRI no incluyó la herramienta y el nombre del modelo en la lista, parece una solución fácil para este problema.

Además, sería útil un tipo de funcionalidad "Buscar", para encontrar herramientas por nombre como se define en los modelos.