Застосовуєте керування версіями до моделей ArcGIS ModelBuilder?

Контроль версій - це незамінний інструмент розробки програмного забезпечення, що дозволяє надійно і чисто відійти назад у минулий раз, коли останній раз X зробив свою роботу точно правильно, або побачити, що змінилося між тим часом і зараз - зазвичай використовується, коли намагаються з'ясувати, чому X більше не працює абсолютно правильно.

Однак усі інструменти, про які я знаю для цього, працюють лише в текстових файлах. Панелі інструментів (стандартні, а не пітонні скриньки інструментів, представлені в 10.1), і, таким чином, їх моделі, є двійковими. Хто-небудь має працездатний метод залучення версій до них?

Примітка: версія відрізняється від резервного копіювання . Є безліч простих способів створення моментальних копій файлів для певної дати / часу - резервне копіювання для Windows, попередні версії , xcopy /s d:\foobar\ x:\foobar_%date%, zip stuff_%date%.zip stuff\*і так далі.

Застосування такого інструменту, як git , копалини , mercurial , subversion або ... до двійкового файлу є на один крок краще, ніж використання xcopy або zip настільки, наскільки можна додати повідомлення про фіксацію, "Модель foobar% date% тепер замінює попередній результати, лише якщо Baz не існує " , але все ще є анемічним порівняно з тим, що той самий набір інструментів може застосовуватися до текстових файлів: наприклад, покажіть мені , що саме було змінено між минулим роком та сьогодні .

Кожне програмне забезпечення для управління версіями версій, будь то центральний центральний контроль версій, наприклад SVN, або розроблені рішення, такі як Git, Mercurial, Bazaar тощо, дозволяють зберігати бінарні файли. Всі вони є досить ефективними як у продуктивності, так і з точки зору займаного простору.

Перевірка відмінностей між версіями / версіями файлу - це, звичайно, інша історія. Не можна багато зробити, коли хочеш порівняти моделі ArcGIS, які справді є бінарними. Я не знаю жодних різних інструментів для моделей, я сумніваюся, що вони знайдуться, оскільки більшості людей не потрібна ця специфічна функціональність.

В даний час у мене є робочий процес ArcCatalog: відкриття панелі інструментів> вибір моделі> редагування> файл> експорт> на python , перехід на інструмент SCM > оновлення змін> внесення змін (введіть коментар журналу) .

Це громіздко, тому я цього не роблю так сильно, і тим самим втрачаю багато переваг версій.

ModelBuilder старий, незграбний і не отримує суттєвих оновлень з ArcGIS Pro, якщо цей твіт є будь-якою ознакою. Я ніколи не був великим прихильником цього (хоча нахабно все-таки користуюсь ним, коли мені доведеться), тому ви можете розглянути цю відповідь як пробіг у питанні та рекомендацію переглянути альтернативи .

FME , мабуть, є найбільш очевидною альтернативою ModelBuilder, оскільки має подібний інтерфейс діаграми потоку. Однією з релевантних переваг є те, що його документи є у простому текстовому форматі, тому вони можуть відрізнятися (хоча часто є безліч безглуздих, автоматично створених сутрів, які вам доведеться навчитися ігнорувати). Однак це комерційне програмне забезпечення, тому його вартість для деяких може бути недосяжною.

Інші, з якими я менш знайомий, - це Orfeo Toolbox , інструменти геопросторового аналізу Whitebox та графічний моделер QGIS (заснований на SEXTANTE ). Це все середовища моделювання з відкритим кодом з графічним інтерфейсом.

Великий поштовх, який я спостерігав на ГІС та відкритих конференціях даних в останні роки, спрямований на ідею "відтворюваних досліджень", тобто даних і процесів, з якими можна легко поділитися та відтворити іншими. Це часто означає використання відкритих форматів даних, програмного забезпечення з відкритим кодом та спільних сховищ. Python та R дуже популярні для цього.

Я вважав, що презентація Дхархаса Потіна на Python та GIS на початку цього року стала хорошим аргументом для цього. Я погоджуюся досить сильно, що надмірна залежність від GUI шкодить відтворюваності. За допомогою коду, якщо ви знайомі з мовою, ви можете досить швидко просканувати її і зрозуміти, що відбувається, тоді як з графічним інтерфейсом потрібно клацати і прокручувати безліч різних вікон, часто вкладених глибоко один в одного , щоб отримати значення та налаштування.

Звичайно, тут є компроміс, але, на мою думку, кожен, хто робить якусь серйозну роботу (наукові дослідження, розробка політики тощо), повинен використовувати засоби, які сприяють відтворюваності.

Вибачте, що це не відповідає на ваше запитання безпосередньо (хоча я не вірю, що є проста відповідь).

Представлення наборів інструментів Python на ArcGIS 10.1 для Desktop скасовує вашу чотирирічну заяву про те, що всі :

Панелі інструментів, а отже, і їх моделі, є двійковими.

Стандартні скриньки інструментів є двійковими, але панелі інструментів Python (* .pyt) - це текстові файли.

Отже, я думаю, що ящики інструментів Python слід враховувати, якщо контроль над версіями вихідного коду перемагає вимогу для побудови графічного інтерфейсу для побудови моделі.

Вам це відомо з вашої відповіді на тему " Навіщо вивчати / використовувати панелі інструментів Python для інструментів сценаріїв Python?" але я подумав, що я повинен включити це як відповідь, щоб можливість використовувати панелі інструментів Python (щоб отримати простий доступ до контролю версій), а не стандартні скриньки інструментів, майбутніми читачами цього питання запитань не оминають уваги.

Багато в чому я радий, що ESRI не здійснив капітальний ремонт усієї системи геопроцесорів та Modelbuilder з переходом на ArcGIS Pro. Є багато (дослідницьких) організацій, які інвестували значні кошти у створення гігантських замовлених моделей, які, безсумнівно, потребували б повного капітального ремонту, якби ESRI порушив сумісність.

Як і у випадку переходу на Python / Geoprocessing з фонових макросів Arc / Info AML, це, безсумнівно, означатиме гігантський вплив та багато людей втрачається. Навіть через 5 - 8 років після першого випуску ArcGIS, все ж дослідники та урядові організації періодично посилалися на моделі AML на таких форумах, що вони ще не змогли перейти на Python через час, гроші або інші обмеження. Це якраз ілюструє потенційний вплив такого переходу, який, безперечно, був би величезним.

Я погоджуюся, що ModelBuilder часом може бути "незграбним", якщо ви цього не знаєте добре, але, оскільки я справді почав вивчати Python, і почав розуміти програму перевірки інструментів ( http://resources.arcgis.com/en/help/main /10.2/index.html#//00150000000v000000 ) значна частина "болю" була знята. Тепер я краще зрозумію, що деякі "криптичні" повідомлення про помилки можуть підтверджувати, що валідація інструментів може виявити, яка частина моделі порушена, і я можу тепер ефективніше їх виправити чи запобігти, написавши належний код перевірки інструменту . Це особливо цінно при "інтеграції" неінструментальних скриньок / моделей не-Python із сценаріями Python.

Одне бажання , хоча я до сих пір, і це зробило б життя з ModelBuilder багатопростіше, якщо автоматична перевірка інструментів фактично виділила інструменти та автоматично відкрила моделі, що викликає попередження чи помилки, пов’язані зі змінними. Крім того, як мінімум, списки помилок та попереджень, що з’являються після натискання кнопки «ОК» на недійсній моделі, повинні містити точну назву інструмента та назву моделі, де інструмент знаходиться недійсним. Якщо у вас є багато вкладених моделей, пошук інструменту, який спричинив певну помилку перевірки, часом може бути стомлюючим лише переліком помилок, що не включає назву інструмента чи (під) моделі, а лише недійсне ім’я змінної. Я насправді втрачаю те, чому ESRI не включив назву інструменту та моделі до списку, це здається простим вирішенням цієї проблеми.

Також було б корисно своєрідна функція "Пошук", щоб знайти інструменти за назвою, як визначено в моделях.