Контроль версий - это незаменимый инструмент для разработки программного обеспечения, позволяющий надежно и аккуратно отступить во времени до того, как X в последний раз сделал свою работу совершенно правильно, или чтобы увидеть, что изменилось между тогда и сейчас - обычно используется при попытке выяснить, почему Х больше не работает точно.
Однако все инструменты, о которых я знаю для этой работы, работают только с простыми текстовыми файлами. Наборы инструментов (стандартные, а не наборы инструментов python, представленные в 10.1) и, следовательно, их модели, являются двоичными. У кого-нибудь есть работоспособный способ принести им версионность?
Примечание: управление версиями отличается от резервного копирования . Есть множество простых способов создания моментальных копий файлов для определенной даты / времени - резервное копирование для Windows, предыдущие версии , xcopy /s d:\foobar\ x:\foobar_%date%, zip stuff_%date%.zip stuff\*и так далее.
Применение такого инструмента, как git , fossil , mercurial , subversion или ..., к двоичному файлу на один шаг лучше, чем использование xcopy или zip, поскольку можно добавить сообщение фиксации: «Model foobar% date% теперь перезаписывает предыдущий результаты только в том случае, если Baz не существует " , но он все еще анемичен по сравнению с тем, что тот же набор инструментов может применять к текстовым файлам: например, покажите мне , что именно изменилось между прошлым годом и сегодняшним днем .
источник
В настоящее время у меня есть рабочий процесс ArcCatalog: открытие панели инструментов> выбор модели> редактирование> файл> экспорт> в python , переключиться на инструмент SCM > обновить изменения> зафиксировать изменения (введите комментарий журнала) .
Это громоздко, поэтому я не делаю это так много, и тем самым теряю многие из преимуществ управления версиями.
источник
ModelBuilder старый, неуклюжий и не получает каких-либо значительных обновлений с ArcGIS Pro, если этот твит есть какие-либо указания. Я никогда не был большим поклонником этого (хотя с неохотой все еще использую его, когда мне нужно), поэтому вы можете рассматривать этот ответ как обход вопроса и рекомендацию взглянуть на альтернативы .
FME является, пожалуй, наиболее очевидной альтернативой ModelBuilder, так как имеет похожий пользовательский интерфейс. Одним из важных преимуществ является то, что его документы представлены в текстовом формате, поэтому они могут различаться (хотя часто возникает много бессмысленных, автоматически сгенерированных ошибок, которые вы должны научиться игнорировать). Однако это коммерческое программное обеспечение, поэтому его стоимость может оказаться недоступной для некоторых.
Другие, с которыми я менее знаком, включают Orfeo Toolbox , Whitebox Geospatial Analysis Tools и графический редактор QGIS (основанный на SEXTANTE ). Это все среды моделирования с открытым исходным кодом с графическим интерфейсом.
Большой толчок, который я наблюдал на ГИС и конференциях по открытым данным в последние годы, направлен на идею «воспроизводимых исследований», то есть данных и процессов, которые могут быть легко переданы и воспроизведены другими. Это часто означает использование открытых форматов данных, программного обеспечения с открытым исходным кодом и общих репозиториев. Python и R очень популярны для этого.
Я думал, что презентация Дхархаса Потины о Python и GIS в начале этого года послужила хорошим аргументом для этого. Я полностью согласен с тем, что чрезмерная зависимость от GUI наносит ущерб воспроизводимости. С помощью кода, пока вы знакомы с языком, вы можете довольно быстро сканировать его и выяснять, что происходит, в то время как с графическим интерфейсом пользователя вам приходится щелкать и прокручивать множество различных окон, часто вложенных глубоко друг в друга. , чтобы получить значения и настройки.
Конечно, здесь есть компромисс, но, по моему мнению, любой, кто занимается какой-либо серьезной работой (научными исследованиями, разработкой политики и т. Д.), Должен использовать инструменты, которые способствуют воспроизводимости.
Извините, что это не отвечает на ваш вопрос напрямую (хотя я не верю, что есть простой ответ).
источник
Внедрение наборов инструментов Python в ArcGIS 10.1 for Desktop лишает законной силы ваше четырехлетнее заявление о том, что все :
Стандартные наборы инструментов являются двоичными, но наборы инструментов Python (* .pyt) являются текстовыми файлами.
Следовательно, я думаю, что наборы инструментов Python должны быть рассмотрены, если контроль версий исходного кода превосходит требования для GUI построения модели.
Вы знаете об этом из своего ответа на вопрос: Зачем изучать / использовать Python Toolboxes поверх Python Script Tools? но я подумал, что должен включить это в качестве ответа здесь, чтобы будущие читатели этих вопросов и ответов не упускали возможность использовать наборы инструментов Python (чтобы получить легкий доступ к управлению версиями), а не стандартные наборы инструментов.
источник
Во многих отношениях я действительно рад, что ESRI не пересмотрел весь Geoprocessing Framework и 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 не включил название инструмента и модели в список, это кажется легким решением этой проблемы.
Кроме того, была бы полезна своего рода функция «Поиск» для поиска инструментов по названию, как определено в моделях.
источник