버전 관리 는 소프트웨어 개발에 없어서는 안될 도구로 X가 정확히 일했던 마지막 시점까지 확실하고 깨끗하게 시간을 거슬러 올라갈 수있게 해줍니다. 또는 그 당시에 무엇이 바뀌 었는지 확인할 수 있습니다. 일반적으로 이유를 알아낼 때 사용됩니다 X는 더 이상 정확하게 작동하지 않습니다.
그러나 내가 아는 모든 도구는 일반 텍스트 파일에서만 작동합니다. 도구 상자 ( 10.1에 도입 된 파이썬 도구 상자가 아닌 표준 도구 상자 )와 그 모델은 이진입니다. 누구든지 그들에게 버전을 가져올 수있는 실용적인 방법이 있습니까?
참고 : 버전 관리 는 백업 과 다릅니다 . 특정 날짜 / 시간 (Windows 백업, 이전 버전 , xcopy /s d:\foobar\ x:\foobar_%date%등 zip stuff_%date%.zip stuff\*)에 대한 파일 스냅 샷을 만드는 간단한 방법에는 여러 가지가 있습니다 .
같은 도구를 적용 자식 , 화석 , 수은 , 전복 , 또는 … 이진 파일에 대한 것은 한 단계 더 XCOPY를 사용하는 것보다 나 하나가 커밋 메시지에 추가 할 수 있습니다로 너무 많은에 지퍼 “모델는 foobar %의 날짜 %는 이제 이전 덮어 Baz가 존재하지 않는 경우에만 결과가 발생 하지만 “ 같은 툴셋이 텍스트 파일에 적용 할 수있는 것과 비교할 때 여전히 빈혈입니다. 예를 들어 작년과 오늘 사이에 무엇이 바뀌 었는지 정확히 보여줍니다 .
답변
SVN과 같은 중앙 중앙 버전 제어 또는 Git, Mercurial, Bazaar와 같은 분산 솔루션 등 모든 주류 버전 제어 소프트웨어는 이진 파일을 저장할 수 있습니다. 그것들은 성능면에서나 점유 공간 측면에서 매우 효과적입니다.
파일의 개정 / 버전 사이의 차이점을 검사하는 것은 물론 다른 이야기입니다. 실제로 바이너리 인 ArcGIS 모델을 비교할 때 할 수있는 일은 많지 않습니다. 나는 모델을위한 diff 도구를 모른다. 대부분의 사람들 이이 특정 기능을 필요로하지 않기 때문에 의심 할 여지가 없다.
답변
현재 ArcCatalog 의 워크 플로우가 있습니다 : 도구 상자 열기> 모델 선택> 편집> 파일> 내보내기> python으로 , SCM 도구로 전환 > 변경 사항 새로 고침> 변경 사항 커밋 (로그 주석 입력) .
번거롭기 때문에 그렇게하지 않으므로 버전 관리의 많은 이점을 잃어 버립니다.
답변
모델 빌더 오래된, 투박하고, 경우는 ArcGIS 프로와 어떤 중요한 업데이트를 받고되지 않은 이 트윗이 어떤 표시입니다. 나는 그것을 좋아하지 않았지만 (필요할 때도 여전히 그것을 사용하지만), 당신은이 대답을 질문의 대안으로 생각 하고 대안 을 보라고 권고 할 수 있습니다.
FME 는 유사한 흐름 다이어그램 UI를 가지고 있기 때문에 가장 확실한 ModelBuilder 대안입니다. 관련 이점 중 하나는 문서가 일반 텍스트 형식이므로 문서를 흩뿌 릴 수 있다는 것입니다 (무시해야 할 의미가없고 자동 생성 된 크래프트가 많이 있지만 무시해야합니다). 그러나 상용 소프트웨어이므로 일부 비용이 들지 않을 수 있습니다.
내가 익숙하지 않은 다른 것들 로는 Orfeo Toolbox , Whitebox Geospatial Analysis Tools 및 QGIS의 그래픽 모델러 ( SEXTANTE 기반 )가 있습니다. 이들은 모두 GUI가있는 오픈 소스 모델링 환경입니다.
최근 몇 년간 GIS 및 공개 데이터 컨퍼런스에서 관찰 한 큰 추진은 “재연 가능한 연구”, 즉 다른 사람들과 쉽게 공유하고 재생할 수있는 데이터 및 프로세스라는 아이디어에 대한 것입니다. 이는 종종 공개 데이터 형식, 공개 소스 소프트웨어 및 공유 저장소를 사용하는 것을 의미합니다. 파이썬과 R은 이것에 매우 인기가 있습니다.
올해 초 Dharhas Pothina의 Python 및 GIS 프레젠테이션 이 이에 대한 좋은 주장 이라고 생각 했습니다. 나는 GUI에 대한 의존이 재현성에 해롭다는 것에 상당히 동의합니다. 코드를 사용하면 언어에 익숙한 한 빠르게 언어를 스캔하고 진행 상황을 파악할 수 있지만 GUI를 사용하면 서로 다른 여러 창을 클릭하고 스크롤해야합니다. 종종 서로 깊은 곳에 중첩되어 있습니다. , 값과 설정을 가져옵니다.
확실히 여기에는 절충점이 있지만, 제 생각에, 심각한 연구 (과학 연구, 정책 결정 등)를하는 사람은 누구나 재현성을 촉진하는 도구를 사용해야합니다.
이것이 귀하의 질문에 직접 답변하지는 않습니다 (쉽게 답변이 있다고 생각하지는 않지만).
답변
ArcGIS 10.1 for Desktop에 Python 툴박스를 도입하면 4 년 전의 진술이 무효화 됩니다 .
도구 상자 및 해당 모델은 이진입니다.
표준 툴박스는 바이너리이지만 Python 툴박스 (* .pyt)는 텍스트 파일입니다.
따라서 소스 코드의 버전 제어가 모델 구축 GUI의 요구 사항보다 우선하면 Python 도구 상자를 고려해야한다고 생각합니다.
왜 Python Script Tools를 통해 Python Toolbox를 배우고 사용합니까?에 대한 답변 에서 이것을 알고 있습니다. 그러나이 Q & A의 독자는 표준 도구 상자 대신 Python 도구 상자 (버전 제어에 쉽게 액세스 할 수 있도록)를 사용하는 옵션을 간과하지 않도록 이것을 여기에 대답으로 포함시켜야한다고 생각했습니다.
답변
여러면에서 ESRI가 ArcGIS Pro 로의 전환으로 전체 Geoprocessing Framework 및 Modelbuilder를 점검하지 않았기 때문에 실제로 기쁩니다 . ESRI가 호환성을 잃었을 경우 완전한 정밀 검사가 필요한 거대한 맞춤형 모델을 구축하는 데 많은 투자를 한 많은 (연구) 조직이 있습니다.
Arc / Info AML 매크로의 배경에서 Python / 지오 프로세싱으로 전환 한 것과 마찬가지로, 이는 큰 영향을 미쳤으며 많은 사람들이 손실을 입었을 것입니다. ArcGIS가 처음 릴리스 된 후 약 5 ~ 8 년이 지났지 만 여전히 연구원과 정부 기관은 때때로 이와 같은 포럼에서 AML 모델을 언급하면서 시간, 돈 또는 다른 제약들. 이것은 단지 그러한 전환의 잠재적 영향을 보여줍니다.
ModelBuilder를 잘 모르는 경우 ModelBuilder가 때때로 “클럭 키”할 수 있다는 데 동의하지만, 실제로 Python을 배우기 시작하고 Tool Validation 프로그래밍 ( http://resources.arcgis.com/en/help/main)을 이해하기 시작한 이후 /10.2/index.html#//00150000000v000000 ), 많은 “고통”이 해제되었습니다. 이제 도구 유효성 검사에서 발생할 수있는 일부 “암호적인”오류 메시지를 더 잘 이해하고 모델의 어느 부분이 손상되었는지 알 수 없게되었으므로 적절한 도구 유효성 검사 코드를 작성하여보다 효과적으로 수정하거나 방지 할 수 있습니다. . 이것은 비 Python 도구 상자 / 모델을 Python 스크립트와 “통합”할 때 특히 유용합니다.
그래도 한 가지 희망은 ModelBuilder로 많은 삶을 살 수 있습니다.자동 공구 검증이 실제로 공구를 강조 표시하고 모델을 자동으로 열어 변수와 관련된 경고 또는 오류를 발생시키는 것이 더 쉽습니다. 또는, 유효하지 않은 모델에서 “확인”을 클릭하면 팝업되는 오류 및 경고 목록에는 정확한 도구 이름과 도구가 상주하는 모델 이름이 포함되어야합니다. 중첩 된 모델이 많은 경우 특정 유효성 검사 오류를 일으킨 도구를 찾는 것은 도구 또는 (하위) 모델 이름이 아닌 잘못된 변수 이름 만 포함 된 오류 목록으로 인해 지루할 수 있습니다. ESRI가 목록에 도구 및 모델 이름을 포함하지 않은 이유에 대해서는 실제로 손실되었습니다.이 문제를 쉽게 해결할 수있는 것처럼 보입니다.
또한 모델에 정의 된 이름으로 도구를 찾기위한 일종의 “검색”기능이 유용합니다.