Що таке хороша систематика або умова іменування для файлів і папок, що містять дані ГІС? [зачинено]

Моя компанія зібрала близько 30 ТБ даних ГІС за останні 8 років, і мені завжди виникають такі питання:

1. Який тип даних ми маємо для даної географічної області?
2. Які дані про ці дані (наприклад, роздільна здатність у метрах на піксель)?
3. Де дані існують на жорсткому диску, щоб я міг їх фактично використовувати?
4. Ми вже обробляли дані чи це в незмінному вигляді з джерела?

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

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

ОНОВЛЕННЯ: Цього минулого тижня я витратив досить багато часу на читання баз даних ГІС, і почав знайомитися з PostGIS. В довгостроковій перспективі, я думаю, ми закінчимо рух до використання бази даних плюс сервер метаданих, як рекомендує JasonBirch в кращих практиках управління геопросторовими даними .

Якщо ви насправді намагаєтесь редагувати дані або розробляти карту, вам потрібно буде тримати дані, над якими ви активно працюєте, окремо від даних, з яких ви почали. Коли я запускаю проект, я створюю папку SourceData з підкаталогами, названими за типом даних (DEM, Orthophoto, Hydrology тощо). Це вмістить усі шари, які я просто використовую для посилання. Будь-які дані, над якими я працюю, будуть скопійовані в іншу папку під назвою Робоча. У робочій папці містяться дані, MXD та все інше, що я змінюю або створюю у підкаталогах, які зазвичай співвідносяться з фазою проекту (MXD, RoadEdits, Delivery тощо)

На додаток до фактичних даних GIS, ви повинні створити папку Communications або Specifications для зберігання будь-яких документів від вашого клієнта / внутрішнього клієнта / професора. Це може слугувати метаданими, коли ви пізніше повернетесь до проекту, а також створити централізоване місце, де хто-небудь ще може побачити, що має відбуватися.

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

Думаю, ви хочете отримати рішення, яке підтримує службу каталогу OGC, для максимальної сумісності. Я бачив, як колеги використовують Deegree - хоча, звичайно, є й інші рішення, які слід перевірити.

Ось приклад того, як ми ввімкнули Deegree у наше програмне забезпечення (демонстрація в реальному часі зараз працює на технічному обслуговуванні - чи не знаєте ви! - але слід створити резервну копію наступного тижня)

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

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

Я вибрав би SpatiaLite, який є однофайловою базою даних, куди ви можете вставити всі свої файли форм , растри та таблиці. Тоді, як реляційна база даних SQL, у вас є сила запитів SQL, щоб виконувати всі необхідні дії (об'єднати, вибрати, об'єднати, об'єднати, розділити тощо) між атрибутами та файлами.

SpatiaLite також доступний з мов програмування, таких як Python, для більшої ступеня автоматизації. Небо - це межа.

Документація та підручники SpatiaLite

Мені корисно створювати документи Word під назвою "Назва карти чи тема - Метадані коментарі.doc". Документуйте основні зміни та робочі процеси в хронологічному порядку (РРРР-ММ-ДД) для кожної теми карти та / або набору даних. Якщо вам потрібно розібратися з історією набору даних: i) Включіть змінену дату / дату, створену із пов’язаних файлів, корисних як історичні посилання або потенційні файли джерела. Додайте короткий підсумок вмісту кожного файлу (назви шарів, # записів), при цьому звертайте увагу на загальні подібності чи відмінності (тобто, що нового у кожній версії карти чи набору даних). Зберігайте файл "- коментарі до метаданих" у тій самій робочій папці, що і остання версія карти чи набору даних. Розмістіть старіші версії карти чи даних у підпапці Архів. Три кроковий процес добре працює для розробки програмного забезпечення, розробка бази даних та управління файлами: 1) розробка (& документ); 2) Тест (& документ); 3) Опублікувати (включаючи метадані). 1) Робоча папка; 2) Підпапка архіву; 3) Опублікована версія.