对于包含GIS数据的文件和文件夹，什么是良好的分类法或命名约定？[关闭]

在过去的8年中，我的公司收集了大约30 TB的GIS数据，我总是发问以下问题：

1. 对于给定的地理区域，我们拥有什么类型的数据？
2. 关于该数据的详细信息是什么（例如，以米/像素为单位的分辨率）？
3. 数据在硬盘驱动器上的什么位置可以实际使用？
4. 我们是否已经处理过数据，还是源中未更改的形式？

到目前为止（包括现在），我试图通过设计适当的文件夹和文件分类法/层次结构来解决这些问题。是否有人对使用文件和文件夹来组织GIS数据的一些可理解的，甚至是标准的方法有任何想法/建议？

我也愿意学习更多有关使用数据库如何使我的公司受益的信息；我们是软件开发人员，而不是GIS专家，因此我怀疑我们在如何最好地解决为方便使用而存储/组织GIS数据的问题上还处于落后状态。我确实看到了管理地理空间数据的最佳做法问题，但是由于我对地理数据库非常陌生，因此只能从答案中吸取少量使用。

更新：最近一周，我花了很多时间阅读有关GIS数据库的信息，并开始熟悉PostGIS。从长远来看，我认为我们将最终转向使用JasonBirch在“管理地理空间数据的最佳做法”中建议的数据库加元数据服务器。

如果您实际上是在尝试编辑数据或开发地图，则需要将正在使用的数据与开始使用的数据分开。当我开始一个项目时，我创建一个SourceData文件夹，其子目录由数据类型（DEM，Orthophoto，Hydrology等）命名。这将保存我仅用作参考的所有层。我正在处理的所有数据都将复制到另一个名为Working的文件夹中。工作文件夹中包含数据，MXD和我在子目录中修改或创建的其他任何东西，这些子目录通常与项目的某个阶段相关（MXD，RoadEdits，Delivery等）

除了实际的GIS数据，您还应该创建一个Communications或Specification文件夹，以保存来自客户/内部客户/教授的所有文档。当您稍后再回到项目时，它可以用作元数据，还可以创建一个集中的位置，其他任何人都可以看到应该发生的事情。

在我看来，您需要一组元数据来存储此信息，并且需要一个使用元数据的检索系统，以使您可以根据该信息提取数据。

我认为您想要一个支持OGC目录服务的解决方案，以实现最大的互操作性。我见过同事使用Deegree-当然，您还应该检查其他解决方案。

这是一个示例，说明了我们如何将Deegree绑定到我们的软件中（实时演示现已停止维护-您不知道！-但下周应进行备份）

至于文件命名，如果您具有目录服务和传送机制，那么文件的名称和位置就没有什么问题了。否则，我认为这取决于您如何查找数据。首先要缩小地理区域或数据类型吗？这将确定层次结构是否首先将数据拆分为图块，然后再将每个图块的数据类型划分为；或将其拆分为数据类型，每个数据类型都有一组图块。

当然，对于空间数据库，在将数据划分为图块时不会遇到相同的问题，因此这通常是一种优先选择的方法-提供最终用途应用程序支持使用该类型的数据。

我会选择SpatiaLite，它是一个文件数据库，您可以在其中插入所有shapefile，栅格和表格。然后，作为关系型SQL数据库，您可以使用SQL查询的功能来执行属性和文件之间的所有必要操作（联接，选择，合并，联合，拆分等）。

还可以从Python等编程语言访问SpatiaLite，以实现更高程度的自动化。天空才是极限。

SpatiaLite文档和教程

我发现创建标题为“地图名称或主题-Metadata comments.doc”的Word文档很有用。为每个地图和/或数据集主题按时间顺序（YYYY-MM-DD）记录主要编辑和工作流程。如果您需要弄清楚数据集的历史记录：i）包括相关文件的修改日期/创建日期，这些文件可用作历史参考或潜在的源文件。包括每个文件内容的简短摘要（图层名称，记录数），同时注意一般的相似点或不同点（例如，地图或数据集的每个版本中的新增内容）。将“-元数据注释”文件与地图或数据集的最新版本保存在同一工作文件夹中。将较旧版本的地图或数据放置在“存档”子文件夹中。这三步过程非常适合软件开发，数据库开发和文件管理：1）开发（和文档）；2）测试（＆文件）；3）发布（包括元数据）。1）工作文件夹；2）存档子文件夹；3）发布版本。