使用地理包进行结构化的 GNSS 土地调查档案
在便携式包装中组织土地调查层、参考元数据和观测关系，同时保持清晰的释放和备份过程。
定义包在项目中的作用
GeoPackage 是一个基于标准的 SQLite 容器 地理空间信息。 它可用于在一个便携式文件中组织多个相关层，但仅文件格式并不能创建完整的土地调查档案。 决定包是工作数据库、可接受的位置交付还是长期交换快照。 每个角色都需要明确的更新和发布规则。
列出项目所需的几何图层、非空间表和支持文件。 必要时以适当的原始格式保留原始 GNSS 观测和专业设备日志。 地理包可以索引或引用该证据，而不会假装更换它。 档案馆应保留空间产品和了解它们是如何生产所需的信息。
围绕物理意义的设计层
独立的大地测量参考点、观测、资产、显示地形坡度和衍生产品的线条。 使用稳定的标识符和显式关系，而不是依赖层次序或匹配坐标。 一种资产可能有多个观测记录，控制标记可能具有可接受的坐标释放的历史记录。 模式应该支持这些区别。
每个图层的文档几何类型和所需属性。 避免将不相关的对象仅存储在通用点表中，因为它们共享几何类型。 清除层语义使验证和以后的更新更容易。 收件人应该能够分辨出哪些记录是直接观察、接受的立场或解释，而不要求原作者解释每一个表格。
保留参考定义和出处
为每个空间层存储适当的CRS，并提供解释所需的更广泛的土地调查元数据。 包括基准实现、坐标时期、本地网格参数和相关的垂直参考。 标准 CRS 标识符可能无法捕获在土地调查处理期间应用的每个操作。 在项目元数据中记录转换和大地水准面模型版本。
坐标变换时保留源观测或可追溯的源标识符。 在交付转换期间，不要覆盖唯一的原始坐标记录。 如果不同的层使用不同的引用，说明为什么并测试它们的关系。 单个容器可以容纳多个层，但这种便利性不应隐藏不兼容的空间或高度定义。
故意使用属性和关系
定义字段类型、单位、编码值和未知状态。 需要时将标识符保留为文本，以保留前导零或长代码。 将特征同一性与观察身份分开。 使用所选软件支持的功能并验证重要的关系是否能在转移中存活。 在一个应用程序中工作的数据库设计可能依赖于另一个工具不理解的扩展。
测试约束并与具有代表性的记录连接，包括重访和被取代的观察结果。 保留审查状态和更正原因。 避免在接受新坐标时需要删除旧证据的模式。 档案应允许以后的审稿人了解当前位置是如何选择的以及在其之前的观察结果。
明确处理附件和外部证据
决定照片和文件是通过支持的机制嵌入的，还是在外部存储有稳定的参考资料。 记录选定的约定并在接收工作流中进行测试。 当目录结构被保留时，相对路径可以是可移植的，而绝对的个人路径通常会在另一台计算机上中断。 不要假设数据库文件会自动包含每个链接的图像。
为保留在包外的原始文件、报告和其他证据创建清单。 通过稳定的特征或观察标识符链接它们。 从其最终目录中测试交付的副本。 收件人应该能够找到支持证据，而无需猜测哪个文件夹名称或相机文件名对应于特定点。
保护工作数据和发布快照
使用适合工具和文件状态的清晰备份流程。 避免盲目复制主动更改的数据库，并假设结果是一个连贯的版本。 按照软件支持的方法完成编辑和创建可转移的快照。 保持工作和发布的版本可区分，因此收件人不会在不知情的情况下使用未完成的文件。
记录封装版本、观测覆盖和有效发布日期。 发布更新时保留早期版本。 如果有几个人需要同时编辑，评估基于文件的工作流是否适合项目，或者其他托管数据库安排是否更适合。 可移植性很有价值，但它并没有消除对协调所有权和更新规则的需求。
验证包裹及其内容
使用合适的工具检查标准的一致性，然后分别验证土地调查的含义。 查看图层计数、几何类型、CRS 定义、标识符、属性和关系。 将代表性坐标和记录与来源进行比较。 技术上有效的地理包仍然可能包含错误分配的引用或链接到错误资产的点。
在预定的接收应用程序中打开包并测试重要的工作流程。 确认图层、字段值和附件参考可用。 检查未知值、日期和长标识符。 如果从包中创建了一个简化的导出，则独立验证导出，而不是假设它继承了源容器的每个质量属性。
用可移植文件提供文档
提供数据字典、图层指南、参考定义、源清单、查看状态规则和未解决的问题。 说明哪些层对发布具有权威性，哪些层是派生的。 解释应该如何添加后来的观察结果以及如何修改接受的职位。 当另一个团队可以在不对其模式进行反向工程的情况下进行维护时，便携式文件是最有用的。
将已发布的包裹及其支持证据和验证结果存档。 保留用于创建它的过程。 GeoPackage 可以使项目结果的 GNSS 土地调查更容易组织，但可靠的档案价值来自记录在案的数据模型和可追溯的观测历史。 容器支持这项工作； 它不会自动执行它。
在第二个工作站上测试一个包
在发布之前，将预定的交付结构复制到一个单独的测试位置并打开它，而不访问作者的工作文件夹。 检查图层、连接、照片和元数据。 这揭示了原始计算机的路径或应用程序状态所隐藏的依赖关系。 在测试中包括重访和被取代的观察结果，以便行使历史关系，而不仅仅是当前的位置。
通过包设计或清单来记录和解决缺失的依赖关系。 如果接收工具无法解释非标准扩展，请在保留完整存档的同时提供商定的互操作视图。 校正后仅重复受影响的支票。 这种实用的可移植性测试使项目结果的交付可审查，并减少组织良好的文件在离开创作工作站后立即成为不完整档案的机会。
在验证说明中包含测试位置和接收应用程序版本。 测试应该证明项目结果工作流程的预期交付，而不是仅仅证明文件在某处打开。 如果外部证据仍保留在包装外，请在复制后验证其清单和相对路径。 便携式容器和便携式存档是相关的，但取得了不同的成就。 当收件人能够找到所需的证据并了解权威层而无需访问作者的私人工作空间时，完整的交付就可以了。
实用检查清单
- 定义权威层和观察关系。
- 文档外部文件和测试附件的可移植性。
- 创建并验证受控发布快照。
