GDAL COG 怎么制作：分块压缩、概览金字塔与云端读取验证
一张十几 GB 的遥感影像放到对象存储后，用户只看一个县域却仍要等待整文件下载，问题不是“云端慢”，而是影像内部组织不支持按范围读取。Cloud Optimized GeoTIFF（COG）将分块、概览和索引放在适合 HTTP Range 请求的位置。本文说明如何制作，更强调怎样验证它真的可按需读取。
GDAL COG 制作：先把问题拆成可验证的环节
GIS 工具往往能在几秒内给出一个结果，但“工具成功运行”并不等于结果可用。处理前先固定 数据版本、CRS、几何类型、字段语义和容差/尺度；处理后再核对数量、范围、面积或统计量。把这两组检查写进流程，问题才不会在交付阶段才暴露。
COG 是文件布局，不只是 TIFF 后缀
普通 GeoTIFF 即使压缩后很小，也可能把目录和概览放在不利于远程访问的位置。COG 的关键是内部瓦片、概览层和目录顺序，使客户端能先定位再读局部块。
分块大小要服务访问模式
过小的 block 增加索引和请求数量，过大则会把无关像元一并传输。浏览与 Web 地图常从 256 或 512 像素块开始试验，最终应由数据波段、压缩比和典型视窗决定。
概览影响缩小浏览的体验
没有 overviews 时，缩小到全国尺度仍可能读取原始分辨率块。概览层应覆盖常见缩放层级，重采样算法还要区分连续影像与分类栅格。
可执行实操流程
- 用 gdalinfo 检查原始数据的 CRS、NoData、波段类型、像元大小和是否已有概览；这些元信息在转换前后必须保持可解释。
- 连续型影像使用合适压缩与块大小，分类栅格避免有损压缩或错误插值；先转换一个代表性样本。
- 用 COG 驱动输出，并为缩小显示建立概览；将结果上传到支持 Range 请求的对象存储或 HTTP 服务。
- 从远程 URL 执行 gdalinfo –config GDAL_DISABLE_READDIR_ON_OPEN EMPTY_DIR，观察能否读取元数据。
- 分别读取小 bbox、全图缩略图和高倍率窗口，记录请求范围、耗时、文件大小与视觉质量。
gdal_translate source.tif output_cog.tif -of COG \n -co COMPRESS=DEFLATE -co BLOCKSIZE=512 \n -co OVERVIEWS=AUTO项目避坑与质量检查
只在本地双击打开 COG 没有验证价值。一次项目中，文件本身符合 COG 结构，但对象存储未正确返回 Accept-Ranges，浏览器仍退化为全量下载。验收必须从远程 URL 读取，并在网络面板或服务日志确认实际 Range 请求。
| 检查项 | 合格信号 | 异常时优先排查 |
|---|---|---|
| 输入一致性 | 范围、CRS、字段含义可解释 | 数据源、坐标定义、空值 |
| 处理结果 | 数量与关键统计量符合预期 | 参数、分组条件、单位 |
| 空间抽检 | 边界与典型位置无明显异常 | 容差、精度、几何有效性 |
建议把“处理前后要比什么”写入项目 README。 这比保存一串截图更能让同事复跑，也能在数据更新时迅速判断差异究竟来自源数据还是算法。
FAQ
所有 TIFF 都适合转 COG 吗？
大多数可行，但先确认 CRS、NoData、数据类型与金字塔策略；分类栅格和科学数据尤其要防止重采样改变含义。
COG 是否一定比普通 TIFF 小？
不一定。它优先优化远程局部读取，文件大小取决于压缩、概览和数据纹理。
如何确认服务端支持 COG？
用远程 URL 做窗口读取，并检查响应是否支持字节范围请求；仅能打开文件不足以说明问题。
总结
COG 的交付标准不是“转换命令跑完”，而是目标环境能按视窗、按层级读取所需像元。真正可靠的 GIS 成果不是某一次按钮点击后的图层，而是一套知道输入边界、参数理由和复核证据的可复现流程。