Menerapkan kontrol versi ke model ArcGIS ModelBuilder?

Kontrol versi adalah alat yang sangat diperlukan untuk pengembangan perangkat lunak, yang memungkinkan seseorang untuk mundur dengan andal dan bersih ke masa lalu hingga X terakhir kali melakukan pekerjaannya dengan benar, atau untuk melihat apa yang berubah antara dulu dan sekarang - biasanya digunakan ketika mencoba mencari tahu mengapa X tidak lagi berfungsi dengan benar.

Namun semua alat yang saya tahu tentang ini hanya berfungsi pada file teks biasa. Kotak alat (kotak standar, bukan kotak alat python yang diperkenalkan pada 10.1), dan dengan demikian modelnya, adalah biner. Apakah ada yang punya metode yang bisa diterapkan untuk membawa versi ke mereka?

Catatan: versi berbeda dari cadangan . Ada sejumlah metode sederhana untuk membuat snapshot dari file untuk tanggal tertentu / waktu - cadangan Windows, versi sebelumnya , xcopy /s d:\foobar\ x:\foobar_%date%, zip stuff_%date%.zip stuff\*, dan sebagainya.

Menerapkan alat seperti git , fosil , lincah , subversi , atau ... ke file biner adalah satu langkah lebih baik daripada menggunakan xcopy atau zip sehingga banyak orang dapat menambahkan pesan komit, "Model foobar% date% sekarang menimpa sebelumnya hasil hanya jika Baz tidak ada " , tetapi masih anemia dibandingkan dengan apa yang dapat dilakukan oleh set alat yang sama untuk file teks: misalnya tunjukkan dengan tepat apa yang diubah antara tahun lalu dan hari ini .

Setiap perangkat lunak kontrol versi utama, baik itu kontrol versi pusat pusat seperti SVN atau solusi terdistribusi seperti Git, Mercurial, Bazaar dll. Memungkinkan penyimpanan file biner. Mereka semua cukup efektif baik dari segi kinerja dan juga dalam hal ruang yang ditempati.

Memeriksa perbedaan antara revisi / versi file tentu berbeda ceritanya. Tidak banyak yang dapat Anda lakukan ketika Anda ingin membandingkan model ArcGIS, yang memang biner. Saya tidak tahu ada alat diff untuk model, saya ragu akan ada karena kebanyakan orang tidak memerlukan fungsi khusus ini.

Saat ini saya memiliki alur kerja ArcCatalog: membuka toolbox> memilih model> mengedit> file> ekspor> ke python , beralih ke alat SCM > menyegarkan perubahan> melakukan perubahan (masukkan komentar log) .

Ini rumit, jadi saya tidak begitu sering melakukannya, dan dengan demikian kehilangan banyak manfaat dari versi.

ModelBuilder sudah tua, kikuk, dan tidak mendapatkan pembaruan signifikan dengan ArcGIS Pro, jika tweet ini merupakan indikasi. Saya tidak pernah menjadi penggemar beratnya (walaupun dengan enggan masih menggunakannya ketika saya harus), jadi Anda mungkin menganggap jawaban ini sebagai menghindari pertanyaan dan rekomendasi untuk melihat alternatif .

FME bisa dibilang alternatif ModelBuilder yang paling jelas, karena memiliki diagram alir yang serupa. Satu keuntungan yang relevan adalah bahwa dokumen-dokumennya berada dalam format teks biasa, sehingga dokumen-dokumen itu dapat berbeda (walaupun seringkali ada banyak kesalahan, pengerjaan otomatis yang harus Anda abaikan). Namun, ini adalah perangkat lunak komersial, sehingga biayanya mungkin tidak terjangkau oleh sebagian orang.

Yang lain yang kurang saya kenal adalah Orfeo Toolbox , Alat Analisis Geospasial Whitebox , dan pemodel grafis QGIS (berdasarkan SEXTANTE ). Ini semua adalah lingkungan pemodelan sumber terbuka dengan GUI.

Dorongan besar yang saya amati di GIS dan konferensi data terbuka dalam beberapa tahun terakhir adalah menuju gagasan "penelitian yang dapat direproduksi", yaitu, data dan proses yang dapat dengan mudah dibagikan dan direproduksi oleh orang lain. Itu sering berarti menggunakan format data terbuka, perangkat lunak sumber terbuka, dan repositori bersama. Python dan R sangat populer untuk ini.

Saya pikir presentasi Dharhas Pothina tentang Python dan GIS awal tahun ini membuat argumen yang bagus untuk ini. Saya setuju sangat kuat bahwa terlalu mengandalkan GUI akan merusak reproduktifitas. Dengan kode, selama Anda terbiasa dengan bahasa tersebut, Anda dapat memindai dengan cepat dan mencari tahu apa yang terjadi, sedangkan dengan GUI Anda harus mengklik dan menggulir banyak jendela yang berbeda, sering bersarang jauh di dalam satu sama lain , untuk mendapatkan nilai dan pengaturan.

Tentu saja, ada pengorbanan di sini, tetapi menurut saya, siapa pun yang melakukan pekerjaan serius (penelitian ilmiah, pembuatan kebijakan, dll.) Harus menggunakan alat yang memfasilitasi reproduksibilitas.

Maaf karena ini tidak menjawab pertanyaan Anda secara langsung (meskipun saya tidak percaya ada jawaban yang mudah).

Pengenalan kotak alat Python di ArcGIS 10.1 untuk Desktop membatalkan pernyataan empat tahun Anda bahwa semua :

Kotak alat, dan dengan demikian modelnya, adalah biner.

Kotak alat standar adalah biner tetapi kotak alat Python (* .pyt) adalah file teks.

Akibatnya, saya pikir kotak alat Python harus dipertimbangkan jika kontrol versi kode sumber mengalahkan persyaratan untuk membangun model GUI.

Anda mengetahui hal ini dari jawaban Anda pada Mengapa mempelajari / menggunakan Python Toolbox di atas Python Script Tools? tapi saya pikir saya harus memasukkan ini sebagai jawaban di sini sehingga opsi untuk menggunakan kotak alat Python (untuk mendapatkan akses mudah ke kontrol versi) daripada kotak alat Standar tidak diabaikan oleh pembaca Q&A masa depan ini.

Dalam banyak hal, saya benar-benar senang ESRI tidak merombak seluruh Kerangka Geoprocessing dan Modelbuilder dengan transisi ke ArcGIS Pro. Ada banyak (penelitian) organisasi yang berinvestasi besar-besaran dalam membangun model kustom raksasa yang pasti akan membutuhkan perombakan total jika ESRI telah melanggar kompatibilitas.

Seperti dengan transisi ke Python / Geoprocessing dari latar belakang Arc / Info AML makro, ini tidak diragukan lagi akan berarti dampak raksasa dan banyak orang yang bingung. Bahkan sekitar 5 - 8 tahun setelah ArcGIS dirilis pertama kali, masih ada peneliti dan organisasi pemerintah yang kadang-kadang merujuk pada model AML di forum-forum seperti ini, yang belum dapat mereka konversi ke Python, karena waktu, uang atau kendala lainnya. Ini hanya menggambarkan dampak potensial dari transisi semacam itu, yang tidak diragukan lagi akan sangat besar.

Saya setuju ModelBuilder bisa "kikuk" di kali jika Anda tidak mengetahuinya dengan baik, tetapi karena saya benar-benar mulai belajar Python, dan mulai memahami pemrograman Validasi Alat ( http://resources.arcgis.com/en/help/main /10.2/index.html#//00150000000v000000 ), banyak dari "rasa sakit" telah dirilis. Saya sekarang jauh lebih memahami beberapa kesalahan "cryptic" toolvalidation pesan pesan dapat muntah, dan membuat Anda bingung bagian mana dari model yang rusak, dan saya sekarang dapat lebih efektif memperbaikinya atau mencegah mereka dengan menulis kode validasi alat yang tepat . Ini sangat berharga ketika "mengintegrasikan" toolbox / model non-Python dengan skrip Python.

Satu harapan meskipun saya masih punya, dan itu akan membuat hidup dengan ModelBuilder jauhlebih mudah, adalah jika validasi alat otomatis benar-benar menyorot alat, dan secara otomatis membuka model, yang menyebabkan peringatan atau kesalahan terkait dengan variabel. Sebagai alternatif, minimal, daftar kesalahan dan peringatan yang muncul setelah Anda mengklik "OK" pada model yang tidak valid, harus menyertakan nama alat yang tepat, dan nama model, di mana alat berada yang tidak valid. Jika Anda memiliki banyak model bersarang, menemukan alat yang menyebabkan kesalahan validasi tertentu, kadang-kadang bisa membosankan hanya dengan daftar kesalahan yang tidak menyertakan alat atau (sub-) nama model tetapi hanya nama variabel yang tidak valid. Saya benar-benar bingung mengapa ESRI tidak memasukkan alat dan nama model dalam daftar, sepertinya perbaikan yang mudah untuk masalah ini.

Juga, semacam fungsionalitas "Pencarian", untuk menemukan alat dengan nama seperti yang didefinisikan dalam model, akan berguna.