ArcGIS ModelBuilder modellerine sürüm kontrolü uygulanıyor mu?

Sürüm kontrolü , yazılım geliştirme için vazgeçilmez bir araçtır ve X'in işini tam olarak doğru yaptığı zamana kadar güvenilir ve temiz bir şekilde geri adım atmasına veya o zaman ve şimdi arasında neyin değiştiğini görmeye izin verir - genellikle nedenini anlamaya çalışırken kullanılır X artık tam olarak doğru çalışmıyor.

Ancak bunun için bildiğim tüm araçlar sadece düz metin dosyalarında çalışır. Araç kutuları ( 10.1'de tanıtılan python araç kutuları değil standart olanlar ) ve dolayısıyla modelleri ikilidir. Herkes sürümleme getirmek için uygulanabilir bir yöntemi var mı?

Not: sürüm oluşturma , yedeklemeden farklıdır . Windows yedekleme, - Herhangi bir belirli tarih / zaman için dosyaların anlık oluşturmak için basit yöntemler vardır önceki sürümleri , xcopy /s d:\foobar\ x:\foobar_%date%, zip stuff_%date%.zip stuff\*, vb.

Git , fosil , mercurial , subversion veya ... gibi bir aracın ikili bir dosyaya uygulanması, bir taahhüt mesajı ekleyebileceği kadar xcopy veya zip kullanmaktan bir adım daha iyidir, "Model foobar% tarih% şimdi üzerine yazılıyor önceki sonuçlar yalnızca Baz mevcut değilse " , ancak aynı araç setinin metin dosyalarına uygulayabileceği şeye kıyasla hala anemiktir: örneğin , geçen yıl ile bugün arasında nelerin değiştiğini tam olarak göster .

SVN gibi merkezi ana sürüm kontrol yazılımı veya Git, Mercurial, Bazaar vb. Dağıtılmış çözümler gibi her ana sürüm kontrol yazılımı, ikili dosyaların depolanmasına izin verir. Hem performans açısından hem de işgal edilen alan açısından oldukça etkilidirler.

Bir dosyanın revizyonları / sürümleri arasındaki farkları incelemek elbette farklı bir hikaye. Gerçekten ikili olan ArcGIS modellerini karşılaştırmak istediğinizde yapabileceğiniz pek bir şey yok. Modeller için herhangi bir fark aracı bilmiyorum, çoğu insanın bu özel işlevselliğe ihtiyaç duymadığı için herhangi bir şey olacağından şüpheliyim.

Şu anda ArcCatalog'un iş akışına sahibim : açılış araç kutusu> model seçme> düzenleme> dosya> dışa aktarma> python'a , SCM aracına geç > değişiklikleri yenile> değişiklikleri kaydet (günlük yorumunu gir) .

Bu hantal değil, bu yüzden çok fazla yapmıyorum ve böylece versiyonlamanın birçok faydasını kaybediyorum.

ModelBuilder eski, hantal ve bu tweet herhangi bir gösterge ise ArcGIS Pro ile önemli bir güncelleme almıyor . Ben hiç büyük bir hayranı olmadım (gerektikçe yine de yapmak zorundayken kullanıyorum), bu yüzden bu cevabı sorunun yanısı ve alternatiflere bakmak için bir tavsiye olarak düşünebilirsiniz .

FME , benzer bir akış şeması kullanıcı arayüzüne sahip olduğu için tartışmasız en belirgin ModelBuilder alternatifidir. İlgili bir avantaj, belgelerinin düz metin biçiminde olmasıdır, böylece farklı olabilirler (genellikle görmezden gelmeyi öğrenmek zorunda olduğunuz anlamsız, otomatik olarak oluşturulmuş bir çok şey vardır). Ancak ticari bir yazılımdır, bu nedenle maliyeti bazıları için ulaşılamayabilir.

Daha az aşina olduğum diğerleri arasında Orfeo Toolbox , Whitebox Geospatial Analysis Tools ve QGIS'in grafiksel modelleyici ( SEXTANTE tabanlı ) yer alıyor. Bunların hepsi GUI'li açık kaynak modelleme ortamlarıdır.

CBS'de ve son yıllarda açık veri konferanslarında gözlemlediğim büyük bir baskı, "tekrarlanabilir araştırma" fikrine, yani başkalarıyla kolayca paylaşılabilen ve çoğaltılabilen veri ve süreçlere yöneliktir. Bu genellikle açık veri formatlarını, açık kaynaklı yazılımları ve paylaşılan depoları kullanmak anlamına gelir. Python ve R bunun için çok popüler.

Dharhas Pothina'nın bu yılın başlarında Python ve GIS ile ilgili sunumunun bunun için iyi bir argüman yaptığını düşündüm . Bir GUI'ye aşırı bağımlılığın tekrar üretilebilirlik için zararlı olduğuna oldukça katılıyorum. Kod ile, dili bildiğiniz sürece, oldukça hızlı bir şekilde tarayabilir ve neler olduğunu anlayabilirsiniz; GUI ile, genellikle birbirinin derinliklerinde iç içe yerleştirilmiş birçok farklı pencerede tıklamanız ve kaydırmanız gerekir. , değer ve ayarlara ulaşmak için.

Kesinlikle, burada bir ödünleşim var, ama bence, ciddi bir iş yapan herkes (bilimsel araştırma, politika oluşturma, vb.) Tekrarlanabilirliği kolaylaştıran araçlar kullanmalıdır.

Üzgünüm, bu soruya doğrudan cevap vermiyor (kolay bir cevap olduğuna inanmıyorum).

Python giriş Masaüstü için 10.1 Dört yaşındaki deyimi o geçersiz ArcGIS de araç kutularından tüm :

Araç kutuları ve dolayısıyla modelleri ikilidir.

Standart araç kutuları ikilidir ancak Python araç kutuları (* .pyt) metin dosyalarıdır.

Sonuç olarak, kaynak kodun sürüm kontrolü bir model oluşturma GUI gereksinimini aşarsa Python araç kutuları düşünülmelidir düşünüyorum.

Eğer bu farkındayız cevap üzerine Why / kullanımı Python Aksesuar kutuları Python Script üzerinde Araçları öğrenmek? ancak Standart cevap kutuları yerine Python araç kutularını (sürüm kontrolüne kolay erişim sağlamak için) kullanma seçeneğinin bu soru-cevap bölümünün gelecekteki okuyucuları tarafından göz ardı edilmemesi için buraya bir cevap olarak eklemem gerektiğini düşündüm.

Birçok yönden, ESRI'nin tüm Geoprocessing Framework ve Modelbuilder'ı ArcGIS Pro'ya geçişle elden geçirmediğine sevindim . ESRI uyumluluğunu bozsaydı, şüphesiz tam bir revizyona ihtiyaç duyacak dev özel modeller oluşturmaya büyük yatırım yapan birçok (araştırma) organizasyon var.

Arc / Info AML makrolarının arka planından Python / Geoprocessing'e geçişte olduğu gibi, bu şüphesiz dev bir etki ve kayıp olan birçok insan anlamına gelir. ArcGIS'in ilk yayınlanmasından 5-8 yıl sonra bile, zaman zaman, para nedeniyle veya diğer kısıtlamalar. Bu sadece kuşkusuz çok büyük olacak böyle bir geçişin potansiyel etkisini göstermektedir.

ModelBuilder'ın iyi bilmiyorsanız bazen "tıknaz" olabileceğini kabul ediyorum, ancak gerçekten Python öğrenmeye başladığım ve Araç Doğrulama programlamasını anlamaya başladığımdan beri ( http://resources.arcgis.com/tr/help/main /10.2/index.html#//00150000000v000000 ), "acı" nın çoğu serbest bırakıldı. Şimdi araç şifrelemenin bazı "şifreli" hata mesajlarını daha iyi anlıyorum ve modelin hangi kısmının bozulduğu konusunda sizi kayıpta bırakıyorum ve şimdi daha etkili bir şekilde düzeltebilir veya uygun araç doğrulama kodu yazarak bunları önleyebilirim . Bu, özellikle Python olmayan araç kutularını / modellerini Python betikleriyle "bütünleştirdiğinde" değerlidir.

Bir dileğim hala var olsa da, bu ModelBuilder ile hayatı çok fazladaha kolay, otomatik araç doğrulamanın araçları gerçekten vurgulaması ve değişkenlerle ilgili uyarılara veya hatalara neden olan modelleri otomatik olarak açmasıdır. Alternatif olarak, geçersiz bir modelde "Tamam" ı tıkladıktan sonra açılan hata ve uyarı listeleri, tam araç adını ve aracın geçersiz olduğu modelin adını içermelidir. Çok sayıda iç içe geçmiş modeliniz varsa, belirli bir doğrulama hatasına neden olan aracı bulmak, yalnızca aracı veya (alt) model adını içermeyen hataların bir listesiyle değil, yalnızca geçersiz değişken adıyla sıkıcı olabilir. Aslında ESRI neden araç ve model adını listeye dahil etmediği için kayboldum, bu sorun için kolay bir düzeltme gibi görünüyor.

Ayrıca, modellerde tanımlandığı gibi araçları ada göre bulmak için bir tür "Arama" işlevi de kullanışlı olacaktır.