¿Utiliza un flujo de trabajo probado para editar y documentar modelos de ArcGIS ModelBuilder?

¿Tiene alguna referencia a ejemplos de mejores prácticas, o puede compartir su experiencia sobre cómo realizar un seguimiento de las ediciones a los modelos ModelBuilder, realizar un seguimiento de los cambios entre las versiones del modelo / herramienta y mantener la estabilidad, robustez y función del modelo?

Soy consciente de la guía de ESRI para administrar, copiar y nombrar modelos aquí .

Me interesaría si alguien tiene prácticas establecidas o experiencia específica en el uso del seguimiento de versiones, el archivo y la edición de las herramientas de ModelBuilder que utilizan con éxito para rastrear el desarrollo y la verificación de modelos y para mantener los modelos en una condición estable.

Actualmente, solo guardamos cajas de herramientas en un servidor de archivos de Windows y retrocedemos utilizando la funcionalidad " Versiones anteriores " si algo se rompe.

Estoy buscando almacenar cajas de herramientas en Git (usando TortoiseGit y GitHub Enterprise ), que ya usamos para scripts Python y espacios de trabajo FME . Dado que las cajas de herramientas normales son binarias, no puede diferenciarlas y fusionarlas interactivamente como lo haría con archivos de texto sin formato, pero aún puede obtener mensajes de confirmación / historial, etiquetas, ramas y fusionar archivos binarios completos (todo o nada).

Lo mejor que creo que podría hacer sería pasar completamente a Python y usar cajas de herramientas de Python y complementos de Python en lugar de ModelBuilder. Además, si tiene FME, puede hacer casi cualquier cosa que pueda hacer con ModelBuilder y, por lo general, es mucho más eficiente y fácil, y es más autodocumentado, con marcadores, anotaciones, descripciones del espacio de trabajo, etc.

Con GitHub puede usar sus funciones Wiki o Páginas para obtener una documentación más extensa.

Un método más de baja tecnología pero aún efectivo es simplemente incluir un archivo de texto Léame con información sobre el propósito, uso e historial de la caja de herramientas / modelo.

No creo que haya una forma de rastrear el cambio en un modelo a medida que lo construyes y no estoy seguro de por qué querrías hacerlo de todos modos.

Lo importante es explicar a otros el razonamiento detrás de su modelo. Por ejemplo, ¿por qué sus entradas deben estar en una geodatabase de archivos, por qué creó un campo y dividió un valor por algún otro número?

Este tipo de información importante es crítica para los usuarios y el desarrollador que tiene que recogerla cuando "te atropella un autobús". :)

Hay dos lugares donde documentaría un modelo, como etiquetas en el generador de modelos (estos serían dirigidos a los desarrolladores) y dentro de la descripción del elemento (metadatos) de la herramienta. Realmente puedes ir a la ciudad agregando información útil que guíe a un usuario.

Desafortunadamente, la mayoría de las personas que desarrollan modelos hacen un mal trabajo al agregar información a los parámetros, lo que hace que el modelo sea difícil de entender si regresa a él meses después. Sé esto ... ¡Lo hice!

Unos minutos dedicados a agregar algunas descripciones a un parámetro de modelo pueden convertir un modelo útil en una gran herramienta que una organización adopta rápidamente, de lo contrario, ¡es solo otro modelo medio analizado que desaparece rápidamente en su unidad de red!

Además de lo que ya se ha dicho, sugeriría intentar almacenar su caja de herramientas en una base de datos ArcSDE. Realmente puede ayudar para la edición concurrente y el acceso. También hago una copia de seguridad de esta base de datos para poder retroceder en caso de algún problema.

Para más detalles, eche un vistazo a otra de mis respuestas .

En la parte de "documentación", utilice los metadatos, también conocido como Editor de descripción de elementos , consulte Un recorrido rápido por las herramientas y cajas de herramientas de documentación .

El cuadro del editor de texto enriquecido es funcional pero limitado. Guarde y verifique los resultados a menudo tanto en la vista previa de la Descripción del elemento como en el cuadro de diálogo de la herramienta, ya que algunos formatos se pueden mezclar o no, especialmente los elementos de la lista. Puede pegar desde Word, Onenote, Dream Weaver, etc. para comenzar rápidamente, pero a menos que el formato sea realmente simple, se desordenará rápidamente.

(Una advertencia: la forma anterior era utilizar el cuadro de diálogo "Modelo >> Editar >> Propiedades del modelo" y pegar el código html en el campo "Descripción". Si lo hace o lo ha hecho, cuando el editor de Descripción del elemento acceda al contenido se copia, lo cual es genial. Sin embargo, las ediciones que realice no se volverán a copiar, por lo tanto, elimine la versión de propiedades del modelo para evitar confusiones).

El control de versiones es posible saliendo un poco de la caja: cuando vea la Descripción del elemento, abra el menú contextual r-clic >> Ver código fuente y luego guarde el html en su carpeta de control de código fuente / documentos . Las imágenes se omiten, pero si desea agregar un poco más de trabajo, puede examinar el html y buscarlas %temp%.

Puede obtener un mayor grado de control haciendo referencia a un archivo de ayuda compilado (CHM) . El lugar para comenzar parece ser Microsoft HTML Help 1.4 .