Організація проектів ГІС? [зачинено]

Я досить довго боюся за те, щоб організувати файли моїх проектів.

Які ваші поради щодо організації своїх наборів даних, зображень, форм-файлів тощо?

Примітка. Ця мітка буде оновлена, як я піду

Я не є комп’ютером або ArcGIS pro будь-якими способами, але ось що я роблю:

Базові файли / DBS

• Це файли, які є "сирими" за своєю природою і складають основу всього мого аналізу
• Ці файли, бази даних та дані розміщуються за межами моєї projectsпапки та розміщуються на моєму інтернет-сервері, локальному комп’ютері та папці. Я завжди маю доступ до них, і вони дуже організовані, розподілені та об'єднані. Ви витратите багато часу на їх організацію.
• Я розміщую їх у базах даних, будь то в Arc чи PostGIS.
• До кожної таблиці я додаю 3 поля у самій таблиці або метадані: DATE_OBTAINED, DATA_DATE, SOURCE_NOTES
• Також базові файли можуть бути запитами декількох інших таблиць. Наприклад, таблиця може об'єднати всі отримані мною кількості трафіку в один великий запит / таблицю.
• Я також розміщую тут усі інші дані, які я вважаю, що чистять в Інтернеті.
• Я НІКОЛИ НЕ РОБУЮ ПРЯМОГО АНАЛІЗУ НА ЯКІЙ ФАЙЛІ В ОСНОВНИХ ФАЙЛАХ

Файли проекту

• Усі мої файли проекту зберігаються в my_projectsпапці. Він містить усе, що стосується цього проекту, як у, якщо я скопіюю та вставте цю папку десь в іншому місці, вона буде містити все.
• Зазвичай у мене є така структура:
  • my_project /
    • адміністратор /
    • спілкування /
    • необроблені дані/
    • проаналізовані_дані /
    • вихідні дані /
    • from_client /
    • ФІНАЛ /
    • код /
    • some_document_date_time.doc
    • ЧИТАЙТЕ
• Повільно я переїжджаю в місцевий GIT. (можна навіть розмістити його локально або на власному сервері). Причиною того, що я не ставлю це на GitHub, є те, що github має ліміт 1,2 гбіт, який є марним для аналізу ГІС
• Для своїх проектів я зазвичай копіюю всі таблиці GIS, які мені потрібні для мого аналізу, у новий db: project_wever.
• 9 разів з 10, я працюю тільки в SHP - файлів , і я зберегти всі мої ГІС (зображення, Excel, координати і т.д.) на мій projects/my_project/raw_data, projects/my_projects/analyzed_dataі projects/my_projects/output_data.
• Коли проект буде завершено, я вкладаю остаточну подану копію my_projects/FINAL/date_submitted
• Щодо мого MXD, я зазвичай зберігаю на новому MXD кожні 2 або 3 години, my_proj_dec_22_11__13_20.mxdнаприклад
• Для документів Ms Word, ілюстрацій та в основному для редагування документів вони зберігаються в папці my_projects, такі як RFP_TENDER_Dec_22_11__11_15.docі draft_ver5_Dec_31_11__12_30.doc. Знову всі мої остаточні результати містяться у папці FINAL
• Щодо коду R, Python та деяких C #, це стає трохи хитро, оскільки я розміщую його поза проектом, але з робочою копією в my_projects/codeпапку. Я роблю це, оскільки більшість кодів python є багаторазовими. Якщо ви поставите весь ваш пітон-код, крім проектів, ви забудете про них. Крім того, весь мій код python працює на github.
• Для мене файли проектів включають будь-які типи файлів, включаючи відстеження часу, комунікації (я зберігаю всі свої електронні листи як .msg файли), я реєструю всі наші словесні комунікації у текстовому файлі, і я вкладаю всі ці файли my_project / communication
• У ArcGIS використовуйте Моделі, LYR та "збережіть вибір як новий шар shp". Ці інструменти дозволять легко зберігати файли у менших форматах, повторно використовувати файли та з моделями, мати можливість використовувати щось в іншому місці.

Кінцевий результат

• Кожен проект, коли його завершують, застібкується та надівається на зовнішній жорсткий диск.
• Всі кінцеві продукти перетворюються у файли з таблиць та у PDF з усіх інших форматів.
• Кожен проект, який я роблю, друкується для резервного копіювання на папері

Суть

• Кожна людина використовує численні та різні програми та інструменти. Дуже багато людей, яких я знаю, організовуються за допомогою basecamp , Harvest або будь-якого іншого набору інструментів. Також люди мають різні робочі звички та схильність до ОКР. Я досить одержимий тим, як організувати речі, можливо, трохи більше, ніж інші. Тому розробляйте систему, яка спричиняє вам найменший стрес, гарантуючи, що ви будете послідовними у застосуванні та оновленнях
• Створіть резервну копію та повторіть все
• Не працюйте безпосередньо над своїми вихідними / базовими даними
• Для своїх проектів завжди використовуйте реплікаційний файл, оскільки дані змінюються з часом, і ви не хочете, щоб його намагалися знайти base_layer_2006.shp.
• у кожній папці my_projects повинен бути текстовий файл README, який ви редагуєте, поки ви робите проекти, щоб дати основну інформацію, яку ви знаєте, що забудете пізніше, коли відвідаєте проект через 2 роки вниз

Ви не заявляли, що працюєте лише з програмним забезпеченням GIS для робочого столу, тому я поділюсь деяким досвідом роботи з орієнтацією на програмування. Дозвольте спочатку сказати, що я згоден з тим, що говорить @dassouki. Я думаю, що найголовніше - це не те, як ти організуєш, а те, що ти робиш це.

Але продовжувати працювати. Мені подобається використовувати мову програмування (R в моєму випадку) - це те, що сценарій, який я пишу, документи всі кроки, які я вживаю. Це на відміну від використання ArcGIS, де я думаю, що важче зрозуміти, як користувач перейшов від необроблених вхідних даних до того, що можна побачити у файлі mxd. Звичайно, ви можете вести журнал усіх кроків, які ви робите в графічному інтерфейсі, але я думаю, що мова програмування набагато краще піддається збереженню точного робочого процесу, який ви здійснили. Це може бути особливо важливим, коли клієнт / керівник запитує, як ви щось зробили або що саме ви зробили, щоб виготовити певний продукт.

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

• Експерименти, тут я зберігаю всі експерименти, які я виконую, наприклад, пробуючи певний аналіз на певному масиві даних. У кожного експерименту є своя директорія. Я також зберігаю отримані таблиці та подібні тут. Всі мої сценарії R знаходяться в цьому каталозі.
• Набори даних, усі мої набори даних зберігаються окремо від
• інструменти, у мене є окремий каталог, де я зберігаю код, який я узагальнив для повторного використання в іншому проекті.
• Документи, моя робота обертається навколо написання наукових праць. Для кожного паперу я маю окремий директор, де зберігаю свої файли Latex. Ці файли читають ілюстрації та таблиці з каталогу експериментів. Папір може містити кілька ілюстрацій.
• програмне забезпечення, в окремому режимі я зберігаю програмне забезпечення, в основному R-пакети, які я написав, і якийсь фортран-код, який я компілюю для запуску моделей.

Деякі основні ідеї, які я використовую:

• Окремі (відносно) статичні форми динамічного матеріалу: наприклад, збереження узагальнених сценаріїв десь інше, ніж там, де ви зберігаєте короткострокові проекти. Або відокремте нераціональні дані від своїх аналізів на них.
• Використовуйте програмне забезпечення для управління версіями, де можна. Мені подобаються меркурій і git.
• АВТОМАТИЗИРУЙТЕ ВАШІ РЕКЛАМИ !!!! Ти ніколи не думаєш про них, коли робиш їх вручну, і тоді твій жорсткий диск виходить з ладу. Під Linux це автоматизація легко. Я не впевнений, як це в Windows / Mac.

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

Я просто хотів би додати до наведеної відповіді - 2 речі.

1. Мені подобається мати папки в каталозі необроблених даних про імпорт - папки щоразу, коли отримує набір даних - тобто від_іменника-2011dec23. Таким чином я можу простежити, коли я отримав кожен фрагмент даних, використаний у проекті.

2. Мені також подобається, що у документі згортається документ-документ, який я згортаю - я можу створити тут слово word або простий файл TXT, щоб я міг записати, що я робив у проекті, даті та хто просив його. Таким чином я можу повернутися назад і прикрити себе - це хтось питання, чому я щось зробив. Це може здатися нудним для невеликих запитів, але це може врятувати вас врешті-решт.