Что такое хорошая таксономия или соглашение об именах для файлов и папок, содержащих данные ГИС? [закрыто]

Моя компания собрала около 30 ТБ данных ГИС за последние 8 лет, и я всегда задаю себе следующие вопросы:

1. Какой тип данных у нас есть для данного географического района?
2. Каковы подробности об этих данных (например, разрешение в метрах на пиксель)?
3. Где хранятся данные на жестком диске, чтобы я мог их использовать?
4. Мы уже обработали данные или они в неизмененном виде из источника?

До сих пор я пытался ответить на эти вопросы, разработав соответствующую папку и файл таксономии / иерархии. Есть ли у кого-нибудь идеи / предложения по некоторым понятным, возможно, даже стандартным способам организации данных ГИС с использованием файлов и папок?

Я также готов узнать больше о том, как использование базы данных может принести пользу моей компании; мы являемся разработчиками программного обеспечения, а не экспертами по ГИС, поэтому я подозреваю, что мы немного отстали от того, как лучше всего подойти к проблеме хранения / организации данных ГИС для простоты использования. Я видел вопрос « Лучшие практики для управления геопространственными данными», но смог извлечь из ответов лишь незначительное использование, потому что я так незнаком с базами геоданных.

ОБНОВЛЕНИЕ: На прошлой неделе я потратил немало времени на чтение баз данных ГИС и начал знакомство с PostGIS. В долгосрочной перспективе я думаю, что в конечном итоге мы перейдем к использованию сервера базы данных и метаданных, как это рекомендовано JasonBirch в разделе « Лучшие практики для управления геопространственными данными» .

Если вы на самом деле пытаетесь редактировать данные или разрабатывать карту, вам нужно будет хранить данные, над которыми вы активно работаете, отдельно от данных, с которыми вы начали. Когда я запускаю проект, я создаю папку SourceData с подкаталогами, названными по типу данных (ЦМР, Ортофото, Гидрология и т. Д.). В нем будут храниться все слои, которые я просто использую для справки. Любые данные, над которыми я работаю, будут скопированы в другую папку с именем Working. Рабочая папка содержит данные, MXD и все остальное, что я изменяю или создаю в подкаталогах, которые обычно связаны с фазой проекта (MXD, RoadEdits, Delivery и т. Д.).

В дополнение к фактическим данным ГИС вы должны создать папку «Связь» или «Спецификации» для хранения любых документов от вашего клиента / внутреннего клиента / профессора. Это может послужить метаданными, когда вы вернетесь в проект позднее, а также создать централизованное местоположение, где каждый сможет увидеть, что должно происходить.

Мне кажется, что вам нужен набор метаданных для хранения этой информации, и поисковая система, которая использует метаданные, чтобы позволить вам извлекать данные на основе этой информации.

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

Вот пример того, как мы привязали Deegree к нашему программному обеспечению (живая демонстрация сейчас недоступна для обслуживания - разве вы не знаете! - но должна вернуться на следующей неделе)

Что касается именования файлов, если у вас есть служба каталогов и механизм доставки, тогда меньше проблем с тем, как называются файлы и где они находятся. В противном случае я думаю, что это зависит от того, как вы смотрите на данные. Вы сначала начинаете с сужения географической области или типа данных? Это будет определять, начинается ли иерархия, разделяя данные на листы, а затем типы данных на лист; или разделив его на типы данных, каждый из которых имеет набор плиток.

Конечно, с пространственной базой данных у вас нет таких проблем с разделением данных на тайлы, так что это часто является предпочтительным методом - при условии, что приложение конечного использования поддерживает использование данных такого типа.

Я бы выбрал SpatiaLite, которая представляет собой однофайловую базу данных, куда вы можете вставить все свои шейп-файлы, растры и таблицы. Тогда, как реляционная база данных SQL, вы имеете возможность SQL-запросов в вашем распоряжении для выполнения всех необходимых действий (объединение, выбор, объединение, объединение, разделение и т. Д.) Между атрибутами и файлами.

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

SpatiaLite Документация и учебные пособия

Я считаю полезным создавать документы Word под названием «Название карты или тема - Метаданные comments.doc». Документируйте основные изменения и рабочие процессы в хронологическом порядке (ГГГГ-ММ-ДД) для каждой карты и / или темы набора данных. Если вам необходимо выяснить историю набора данных: i) Включите дату изменения / дату создания связанных файлов, которые полезны в качестве исторических ссылок или потенциальных исходных файлов. Включите краткое резюме содержимого каждого файла (имена слоев, количество записей), обращая внимание на общие сходства или различия (т. Е. Что нового в каждой версии карты или набора данных). Храните файл «- Комментарии к метаданным» в той же рабочей папке, что и самая последняя версия карты или набора данных. Поместите старые версии карты или данных в подпапку «Архив». Трехступенчатый процесс хорошо работает для разработки программного обеспечения, разработка баз данных и управление файлами: 1) Разработка (и документ); 2) Тест (и документ); 3) Публикация (включая метаданные). 1) рабочая папка; 2) подпапка архива; 3) Опубликованная версия.