设想一支小型调查团队正在交接一季的采样点数据。点位已显示在地图上，接收方还要关联实验室结果、辨读地名，并区分测量值缺失与记录值为零的情况。用 GDAL 的 ogr2ogr 将这份档案从 Shapefile 迁入 GeoPackage，只有保全这些关联，迁移才有实际价值。转换命令处在整个工作的中段，团队首先要对每条记录的含义达成共识。

GeoPackage 是一个实用的迁移目标。按照开放地理空间联盟（OGC）的定义，它是基于 SQLite 的开放格式，规定了空间要素、属性及其他地理空间内容的存储方式。多个图层可以随同一个数据库文件交付。对外业团队而言，它的好处很直接：交付文件可以把数据表与空间参考信息放在一起。[1]

已有机构实践印证了这种用途。2021 年 12 月，美国地质调查局（USGS）宣布以 GeoPackage 格式分发水文数据产品，所列理由包括开放格式要求，以及可在商业软件和开源软件中使用。该公告也记录了交付数据的变化，其中包括增设列来解释编码值。这个历史案例为迁移提供了一条有用的原则：数据便于流转，也包括让下一位使用者读懂其中的含义。[2]

改进之前，先保留比对基准

以这份示例调查为例，第一步是完整保留原始交付文件。一个 Shapefile 图层通常包括 .shp、.shx 和 .dbf 文件；随附的 .prj 和 .cpg 文件可分别提供坐标系与编码信息。GDAL 解析数据时会读取这些配套文件。[4]

先留存一份副本，再检查工作副本：

ogrinfo -ro -al -so -mdd SHAPEFILE survey_points.shp

这里的 -ro 以只读方式打开源数据，-al 选择全部图层，-so 输出概要信息，包括字段结构、要素数量、空间范围和坐标参考系。命令中请求的元数据会显示 Shapefile 驱动如何判读源数据的编码。[4][5]

将这份输出与交接说明一同保存。转换后，团队便有了比截图更精确的比对依据。还应从外业记录中选取几条含义已知的记录：名称含重音符号的测点、以零开头的标识符、数值异常大的测量结果，以及存在数据缺失的观测。这些是建议选取的验收样例，具体调查是否包含这些情况，要以实际数据为准。

导出前应先核对编码。GDAL 会先尝试读取 .cpg 中的声明，再读取 DBF 的代码页标记；声明有误会带来文本解码出错的风险。实际编码确定后，可以用打开选项 ENCODING 覆盖驱动的判读结果。难以辨认的名称即使换了存储容器，其原本含义仍有待查明。[4]

让一次转换的过程清楚可查

假定源数据是一个简单的点图层，坐标系已经核验，属性也已正确解码。为目标文件使用一个新的文件名：

ogr2ogr -f GPKG survey_delivery.gpkg survey_points.shp \
  -nln survey_points

ogrinfo -ro -al -so survey_delivery.gpkg

ogr2ogr 的参数顺序是目标在前、源数据在后；-nln 指定输出图层的名称。这个示例只更换存储容器，坐标投影保持原样。命令也省去了 -skipfailures；启用该选项后，转换会跳过处理失败的要素并继续执行。[6]

GDAL 的 GeoPackage 驱动默认创建空间索引。输出格式的版本还取决于 GDAL 的版本：文档记载，从 GDAL 3.11 开始，默认 GeoPackage 版本由 1.2 改为 1.4。在统一导出流程之前，应记录工具版本，并检查接收方应用支持的格式版本。[7]

第一轮转换应限定在较小范围内。若同时重命名字段、修正观测记录并变换坐标，出现差异后就更难查明原因。基础迁移通过验收后，再另做一次修订，采用更清楚的名称或修正后的数值，并留下明确的变更记录。

标签改了，坐标数值仍然照旧

导出对话框中的两项操作看起来相近，GDAL 对它们作了明确区分。-a_srs 为输出数据指定空间参考，保留坐标数值原样。-t_srs 则把坐标变换到指定的参考系，变换时采用源数据的参考系定义，或采用 -s_srs 显式指定的替代定义。[6]

例如，给投影坐标标注一个经纬度参考系，原有数值仍会保留。此时元数据发生了变化，位置的描述却出了错。若源数据的参考系未知，应先从调查文档中查明，再决定输出采用哪个参考系。文件扩展名本身无法回答这个问题。

对于保持坐标数值原样的迁移，应比对报告中的空间范围，并依据独立且可信的参考资料检查已知测点。比对一致可以作为迁移结果可靠的证据；至于测量精度，仍应保留原始调查所记载的不确定性。

将观测标识与数据行分开

采样点标识应在文件重新打开、编辑或关联其他表格之后依然有效。Shapefile 的内部要素标识符（FID）用作替代时，可靠性有限：GDAL 文档指出，重新打包 Shapefile 会重新编排 FID。[4] GeoPackage 有一个整数主键，GDAL 输出中通常命名为 fid，但团队的采样编号规则仍需另行定义。[7]

对这个示例，我建议单独设置一个经过核验的 site_id 属性。验收交付数据之前，应检查标识的唯一性、缺失情况，以及它与实验室结果的关联。还要明确记录回访的方式：同一地点标识可以出现在多条观测记录中，而每条观测记录又各自需要唯一键。这项约定应写入数据字典。

源数据已经缺失的信息，也超出了存储容器所能还原的范围。DBF 字段名有十个字符的长度限制；若要展开名称，应依据有文档记录的定义，缩写的含义也须据此查明。[9]

实际走一遍接收方的下一步工作

在接收方的应用中打开交付图层，检查选定的记录，并实际关联实验室数据。将要素数量和字段结构与基准比对，再检查未匹配的标识和意料之外的重复项。要素数量一致时，表间关联仍有出错的风险。ogrinfo 能给出有用的概要信息；几何有效性和 GeoPackage 规范符合性则需要另行检验。[5]

美国国会图书馆对该格式的独立评估，特别提到它在网络连接受限的移动设备上的用途。[10] 对于一支有明确数据管理责任人的小团队，GeoPackage 因而适合用作本地工作和交付格式。应保留一份已确认可靠的源数据、一份转换过程记录，以及一份通过验收的导出文件。这套流程还需要相应的日常管理，让团队能够辨明哪份副本是权威版本。

多人并发编辑时，选择就有所不同。对于每个数据库文件，SQLite 同一时刻只允许一个写入者，各写入者可以轮流操作。SQLite 自身的指南建议：若多个写入者无法排队等待，应采用客户端／服务器存储；指南也提醒，应避免经由网络文件系统同时直接访问数据库。[8] 有这类协作需求的团队，应评估服务器数据库，同时保留 GeoPackage 作为便携交付格式。

当另一个人能够找到测点、读懂属性，并复现表间关联，迁移的价值才算兑现。这些实际操作，让数量减少的文件成为一份值得信赖的交付成果。

参考来源

1. 开放地理空间联盟（OGC），《OGC GeoPackage》——格式范围、SQLite 容器、可移植性与支持的内容。
2. USGS 国家水文项目，《Geopackage Format Coming Soon!》，2021 年 12 月 23 日——独立的机构采用背景，以及所分发数据属性的变化。
3. USGS，《Using GPS in the Field》，2007 年 3 月 1 日——照片、调查背景、机构署名与公有领域标示。
4. GDAL，《ESRI Shapefile / DBF》——配套文件、编码元数据，以及重新打包时的 FID 重编号。
5. GDAL，《ogrinfo》——只读检查、图层概要、元数据域，以及报告中的字段结构、数量、空间范围和坐标系。
6. GDAL，《ogr2ogr》——转换语法、图层命名、跳过失败要素，以及坐标参考系的赋值与坐标变换之别。
7. GDAL，《GPKG—GeoPackage vector》——默认格式版本、主键命名与空间索引创建。
8. SQLite，《Appropriate Uses For SQLite》——写入并发，以及适合采用客户端／服务器存储的条件。
9. Esri，《Geoprocessing considerations for shapefile output》——DBF 属性限制，包括字段名最多十个字符的限制。
10. 美国国会图书馆，《GeoPackage Encoding Standard (OGC) Format Family》，更新于 2024 年 5 月 6 日——独立的保存格式评估，涉及互操作性与网络连接受限时的使用。