Áp dụng kiểm soát phiên bản cho các mô hình ArcGIS ModelBuilder?

Kiểm soát phiên bản là một công cụ không thể thiếu để phát triển phần mềm, cho phép người ta quay ngược thời gian một cách đáng tin cậy và lần trước X đã làm đúng công việc của mình, hoặc để xem điều gì đã thay đổi giữa lúc đó và bây giờ - thường được sử dụng khi cố gắng tìm hiểu tại sao X không còn hoạt động chính xác nữa.

Tuy nhiên, tất cả các công cụ tôi biết về công việc này chỉ có trên các tệp văn bản thuần túy. Các hộp công cụ (tiêu chuẩn, không phải hộp công cụ python được giới thiệu trong 10.1), và do đó mô hình của chúng là nhị phân. Có ai có một phương pháp khả thi để mang phiên bản cho họ?

Lưu ý: phiên bản khác với sao lưu . Có bất kỳ số phương pháp đơn giản để tạo ảnh chụp nhanh các tập tin cho một ngày / thời gian cụ thể - Windows sao lưu, các phiên bản trước , xcopy /s d:\foobar\ x:\foobar_%date%, zip stuff_%date%.zip stuff\*, và vân vân.

Áp dụng một công cụ như git , hóa thạch , đồng bóng , lật đổ hoặc ... vào tệp nhị phân tốt hơn một bước so với sử dụng xcopy hoặc zip trong nhiều thứ để người ta có thể thêm thông điệp cam kết, "Mô hình foobar% ngày% ghi đè trước đó chỉ có kết quả nếu Baz không tồn tại " , nhưng vẫn thiếu máu so với những gì bộ công cụ tương tự có thể áp dụng cho các tệp văn bản: ví dụ: cho tôi biết chính xác những gì đã thay đổi giữa năm ngoái và hôm nay .

Mọi phần mềm kiểm soát phiên bản chính, có thể là điều khiển phiên bản trung tâm như SVN hoặc các giải pháp phân tán như Git, Mercurial, Bazaar, vv cho phép lưu trữ các tệp nhị phân. Tất cả đều khá hiệu quả cả về hiệu suất và cả về không gian chiếm dụng.

Kiểm tra sự khác biệt giữa các phiên bản / phiên bản của một tập tin tất nhiên là khác nhau. Bạn không thể làm gì nhiều khi muốn so sánh các mô hình ArcGIS, đây thực sự là hệ nhị phân. Tôi không biết bất kỳ công cụ khác cho các mô hình, tôi nghi ngờ sẽ có bất kỳ công cụ nào vì hầu hết mọi người không cần chức năng cụ thể này.

Hiện tại tôi có quy trình làm việc của ArcCatalog: mở hộp công cụ> chọn mô hình> chỉnh sửa> tệp> xuất> sang python , chuyển sang công cụ SCM > làm mới thay đổi> cam kết thay đổi (nhập nhận xét nhật ký) .

Nó cồng kềnh vì vậy tôi không làm điều đó quá nhiều, và do đó mất đi nhiều lợi ích của việc tạo phiên bản.

ModelBuilder đã cũ, cồng kềnh và không nhận được bất kỳ cập nhật quan trọng nào với ArcGIS Pro, nếu tweet này là bất kỳ dấu hiệu nào. Tôi chưa bao giờ là một fan hâm mộ lớn của nó (mặc dù vẫn sử dụng nó một cách bừa bãi), vì vậy bạn có thể coi câu trả lời này như là một câu hỏi phụ và đề nghị xem xét các lựa chọn thay thế .

FME được cho là sự thay thế ModelBuilder rõ ràng nhất, vì nó có giao diện người dùng sơ đồ tương tự. Một lợi thế có liên quan là các tài liệu của nó ở định dạng văn bản thuần túy, vì vậy chúng có thể khác nhau (mặc dù thường có rất nhiều hành trình tự động, vô nghĩa mà bạn phải học cách bỏ qua). Đây là phần mềm thương mại, tuy nhiên, vì vậy chi phí của nó có thể nằm ngoài tầm với của một số người.

Những thứ khác mà tôi ít quen thuộc bao gồm Hộp công cụ Orfeo , Công cụ phân tích không gian địa lý Whitebox và nhà tạo mô hình đồ họa của QGIS (dựa trên SEXTANTE ). Đây là tất cả các môi trường mô hình hóa nguồn mở với GUI.

Một nỗ lực lớn mà tôi đã quan sát được tại GIS và các hội nghị dữ liệu mở trong những năm gần đây là hướng tới ý tưởng "nghiên cứu có thể tái tạo", đó là dữ liệu và quy trình có thể dễ dàng chia sẻ và sao chép bởi những người khác. Điều đó thường có nghĩa là sử dụng các định dạng dữ liệu mở, phần mềm nguồn mở và các kho lưu trữ được chia sẻ. Python và R rất phổ biến cho việc này.

Tôi nghĩ rằng bài thuyết trình của Dharhas Pothina về Python và GIS hồi đầu năm nay đã đưa ra một lập luận tốt cho vấn đề này. Tôi đồng ý khá mạnh mẽ rằng việc phụ thuộc quá nhiều vào GUI là bất lợi cho khả năng tái tạo. Với mã, miễn là bạn quen thuộc với ngôn ngữ, bạn có thể quét qua nó khá nhanh và tìm hiểu điều gì đang xảy ra, trong khi với GUI, bạn phải nhấp và cuộn qua nhiều cửa sổ khác nhau, thường được lồng sâu vào nhau , để có được các giá trị và cài đặt.

Chắc chắn, có một sự đánh đổi ở đây, nhưng theo tôi, bất kỳ ai làm bất kỳ công việc nghiêm túc nào (nghiên cứu khoa học, hoạch định chính sách, v.v.) đều nên sử dụng các công cụ tạo thuận lợi cho khả năng tái tạo.

Xin lỗi vì điều này không trả lời trực tiếp câu hỏi của bạn (mặc dù tôi không tin rằng có một câu trả lời dễ dàng).

Sự ra đời của Python toolboxes tại ArcGIS 10.1 cho Desktop làm mất hiệu lực tuyên bố bốn tuổi của bạn mà tất cả :

Các hộp công cụ, và do đó mô hình của chúng, là nhị phân.

Các hộp công cụ tiêu chuẩn là nhị phân nhưng các hộp công cụ Python (* .pyt) là các tệp văn bản.

Do đó, tôi nghĩ rằng các hộp công cụ Python nên được xem xét nếu kiểm soát phiên bản mã nguồn vượt qua yêu cầu đối với GUI xây dựng mô hình.

Bạn nhận thức được điều này từ câu trả lời của bạn về Tại sao tìm hiểu / sử dụng Hộp công cụ Python trên Công cụ tập lệnh Python? nhưng tôi nghĩ tôi nên đưa nó vào đây như một câu trả lời ở đây để tùy chọn sử dụng các hộp công cụ Python (để có quyền truy cập dễ dàng vào kiểm soát phiên bản) thay vì các hộp công cụ Standard không bị bỏ qua bởi các độc giả tương lai của Hỏi & Đáp này.

Theo nhiều cách, tôi thực sự vui mừng vì ESRI đã không đại tu toàn bộ Khung công tác địa lý và Người xây dựng mô hình với việc chuyển đổi sang ArcGIS Pro. Có nhiều tổ chức (nghiên cứu) đã đầu tư rất nhiều vào việc xây dựng các mô hình tùy chỉnh khổng lồ chắc chắn sẽ cần một cuộc đại tu hoàn chỉnh nếu ESRI bị hỏng khả năng tương thích.

Như với quá trình chuyển đổi sang Python / Geoprocessing từ nền tảng của macro Arc / Info AML, điều này chắc chắn sẽ có nghĩa là một tác động lớn và nhiều người bị mất. Thậm chí khoảng 5 - 8 năm sau khi phát hành ArcGIS đầu tiên, vẫn có những nhà nghiên cứu và tổ chức chính phủ thỉnh thoảng đề cập đến các mô hình AML trên các diễn đàn như thế này, rằng họ chưa thể chuyển đổi sang Python, do thời gian, tiền bạc hoặc các ràng buộc khác. Điều này chỉ minh họa tác động tiềm năng của một quá trình chuyển đổi như vậy, chắc chắn sẽ rất lớn.

Tôi đồng ý ModelBuilder đôi khi có thể "cục mịch" nếu bạn không biết rõ về nó, nhưng vì tôi thực sự bắt đầu học Python và bắt đầu hiểu về lập trình Xác thực Công cụ ( http://resource.arcgis.com/en/help/main /10.2/index.html#//00150000000v000000 ), phần lớn "nỗi đau" đã được giải tỏa. Bây giờ tôi hiểu rõ hơn một số công cụ xác định thông báo lỗi "khó hiểu" có thể gây ra và khiến bạn mất mát khi phần nào của mô hình bị hỏng và bây giờ tôi có thể sửa chúng hoặc ngăn chặn chúng một cách hiệu quả hơn bằng cách viết mã xác thực công cụ thích hợp . Điều này đặc biệt có giá trị khi "tích hợp" các hộp công cụ / mô hình không phải Python với các tập lệnh Python.

Một điều ước mặc dù tôi vẫn có, và điều đó sẽ khiến cuộc sống với ModelBuilder trở nên nhiềudễ dàng hơn, là nếu việc định giá công cụ tự động thực sự làm nổi bật các công cụ và tự động mở các mô hình, điều đó gây ra các cảnh báo hoặc lỗi liên quan đến các biến. Ngoài ra, ở mức tối thiểu, danh sách lỗi và cảnh báo bật lên khi bạn nhấp vào "OK" trên một mô hình không hợp lệ, phải bao gồm tên công cụ chính xác và tên của mô hình, nơi công cụ cư trú không hợp lệ. Nếu bạn có nhiều mô hình lồng nhau, việc tìm kiếm công cụ gây ra lỗi xác thực cụ thể, đôi khi có thể tẻ nhạt chỉ với một danh sách các lỗi không bao gồm công cụ hoặc tên mô hình (phụ) mà chỉ là tên biến không hợp lệ. Tôi thực sự không biết tại sao ESRI không bao gồm công cụ và tên mô hình trong danh sách, nó có vẻ như là một sửa chữa dễ dàng cho vấn đề này.

Ngoài ra, một loại chức năng "Tìm kiếm", để tìm các công cụ theo tên như được xác định trong các mô hình, sẽ rất tiện lợi.