COG影像格式有什么用?云原生GIS怎么搞?

wowwwai GIS研习社 · 工具流程与项目排障

《COG影像格式有什么用?云原生GIS怎么搞?》这篇文章面向正在处理大体量遥感影像、WebGIS底图、在线栅格服务和云端空间数据的 GIS 读者，重点讲清楚 COG 影像格式到底解决什么问题，以及云原生 GIS 在实际项目里应该怎么落地。

如果你遇到过这些情况：一张 GeoTIFF 有几十 GB，下载很慢；WebGIS 加载遥感影像卡顿；影像服务部署复杂；对象存储里有很多栅格数据但无法高效按需读取，那么 COG 很可能就是你需要了解的关键格式。

引言：COG影像格式解决的核心问题

COG 是 Cloud Optimized GeoTIFF 的缩写，中文通常称为云优化 GeoTIFF。它本质上仍然是 GeoTIFF，但文件内部组织方式更适合在 HTTP、对象存储和云环境中被按需读取。

传统 GeoTIFF 在本地磁盘上使用没有问题，但放到云端之后，常见问题会变得明显：

• 影像文件很大，客户端下载整幅数据成本高。
• WebGIS 只需要当前视图范围，却不得不读取大量无关数据。
• 缺少金字塔层级时，小比例尺浏览非常慢。
• 影像服务依赖专门服务器，部署和扩展成本较高。
• 对象存储中虽然有影像文件，但无法像瓦片服务一样高效访问。

COG影像格式的价值就在于：让一个 GeoTIFF 文件在云端也能像“可随机访问的数据源”一样工作。客户端或服务端工具可以只请求当前视图所需的影像块，而不是把整幅影像下载下来。

背景：为什么云原生GIS需要COG

云原生 GIS 不是简单地把 GIS 软件安装到云服务器上，而是尽量利用对象存储、HTTP 访问、容器化服务、弹性计算和按需读取机制来组织空间数据和服务。

在矢量数据中，常见的云原生思路包括 FlatGeobuf、GeoParquet、PostGIS 云数据库和矢量瓦片。对于栅格数据，COG 是最常见、最实用的云原生影像格式之一。

以遥感影像发布为例，传统流程可能是：

1. 将 GeoTIFF 上传到服务器磁盘。
2. 用 GeoServer、ArcGIS Server 或其他影像服务软件发布。
3. 前端通过 WMS、WMTS 或自定义接口访问。
4. 服务器负责读取、裁剪、重采样和输出图片。

这种模式可控性强，但服务器压力较大。COG 的思路是把影像文件本身组织好，放在对象存储或静态文件服务中，再由支持 COG 的工具按需读取。这样可以减少中间服务层，提升可扩展性。

原理：COG影像格式为什么能按需读取

理解 COG 不需要一开始就看规范细节，先记住三个关键点：内部瓦片、影像金字塔、HTTP Range 请求。

1. 内部瓦片

普通 GeoTIFF 可能按条带组织数据，也可能按块组织数据。COG 通常要求使用内部瓦片结构，也就是把大影像切成许多固定大小的块，例如 256×256 或 512×512 像素。

当地图只显示某个小区域时，工具只需要读取覆盖该区域的几个瓦片块，而不是扫描整幅影像。

2. 影像金字塔

影像金字塔也叫 overview，是同一影像的多级降采样版本。例如原始分辨率是 0.5 米，可以生成 1 米、2 米、4 米、8 米等层级。

在小比例尺浏览时，WebGIS 不需要读取最高分辨率影像，只读取较低分辨率的金字塔层级即可。这样可以明显减少数据读取量和渲染压力。

3. HTTP Range 请求

HTTP Range 请求允许客户端只请求文件的一部分字节范围。COG 文件把关键索引、瓦片块和金字塔组织得足够友好，使 GDAL、Rasterio、QGIS、TiTiler 等工具能够通过网络只读取需要的字节片段。

这就是 COG 适合云原生 GIS 的根本原因：数据可以放在对象存储里，访问端只取需要的部分。

步骤：如何制作和使用COG影像格式

下面给出一个可落地的 COG 工作流，适合 QGIS、GDAL、Python GIS 和 WebGIS 项目使用。

步骤1：准备源影像

源数据可以是普通 GeoTIFF、遥感正射影像、DEM、分类栅格或多波段影像。制作 COG 前先检查这些内容：

• 影像是否有正确坐标系。
• NoData 值是否设置正确。
• 像元类型是否合理，例如 Byte、UInt16、Float32。
• 是否需要重投影到 WebGIS 常用坐标系。
• 是否需要裁剪到项目范围。

如果是 WebGIS 在线浏览，常见坐标系是 EPSG:3857；如果是分析业务，通常保留原始投影或项目指定投影更合适。

步骤2：用GDAL转换为COG

GDAL 从较新版本开始已经内置 COG 驱动，可以直接使用 gdal_translate 生成 COG。

gdal_translate input.tif output_cog.tif -of COG -co COMPRESS=DEFLATE -co BLOCKSIZE=512

常用参数说明：

• -of COG：指定输出为 Cloud Optimized GeoTIFF。
• COMPRESS=DEFLATE：使用无损压缩，适合多数连续影像和 DEM。
• BLOCKSIZE=512：设置内部瓦片大小，512 是常见选择。

如果是 RGB 影像，也可以考虑 JPEG 压缩，但要注意 JPEG 是有损压缩，不适合需要精确像元值分析的 DEM、分类图或指数栅格。

gdal_translate input_rgb.tif output_rgb_cog.tif -of COG -co COMPRESS=JPEG -co QUALITY=85 -co BLOCKSIZE=512

步骤3：验证COG是否合格

制作完成后，不要只看文件能不能打开，还要验证它是否真正符合 COG 访问要求。可以使用 GDAL 的信息检查：

gdalinfo output_cog.tif

重点查看：

• 是否存在 Overviews。
• 是否为 tiled block 结构。
• 坐标系和范围是否正确。
• NoData 值是否保留。
• 波段数量和数据类型是否符合预期。

也可以使用专门的 COG 校验工具，例如 rio cogeo validate：

rio cogeo validate output_cog.tif

步骤4：上传到对象存储或静态文件服务

COG 常见部署位置包括：

• Amazon S3、Google Cloud Storage、Azure Blob Storage。
• MinIO 等自建对象存储。
• 支持 Range 请求的 Nginx 静态文件服务。
• 企业内部 HTTP 文件服务。

这里有一个关键检查点：你的存储或 Web 服务必须支持 HTTP Range 请求。否则 COG 的按需读取优势会大打折扣。

步骤5：在QGIS中直接读取远程COG

QGIS 底层依赖 GDAL，因此可以读取远程 COG。常见方式是添加栅格图层并填写 HTTP 地址，或者通过 GDAL 虚拟文件系统访问。

/vsicurl/https://example.com/data/output_cog.tif

如果访问速度慢，优先检查：

• 远程服务器是否支持 Range 请求。
• COG 是否有内部金字塔。
• 影像是否被错误地重投影到不合适坐标系。
• 网络跨区域访问是否延迟过高。
• 文件是否使用了不合适的压缩方式。

步骤6：在WebGIS中发布COG

浏览器本身通常不会直接把 COG 当成普通瓦片服务使用。实际项目中常见做法是使用中间服务把 COG 动态转换为 XYZ 瓦片或图片切片。

常用方案包括：

• TiTiler：基于 Python、FastAPI 和 Rasterio，适合动态读取 COG 并输出瓦片。
• GeoServer：可结合 ImageMosaic 或相关扩展管理栅格数据，但配置复杂度更高。
• 自研服务：使用 Rasterio、rio-tiler 或 GDAL 按请求读取 COG 并返回图像。
• 预切片方案：将影像切成 XYZ/WMTS 瓦片，适合固定底图和超高并发场景。

对于 Leaflet、OpenLayers、MapLibre GL JS 等前端库，通常接入的是瓦片 URL，而不是直接接入 COG 文件本身。例如：

https://example.com/tiles/{z}/{x}/{y}.png?url=https://example.com/data/output_cog.tif

这个 URL 背后可以由 TiTiler 或其他服务负责读取 COG 并返回当前瓦片。

常见坑：COG影像格式使用时最容易出错的地方

1. 只是改了文件扩展名，并不是真正的COG

COG 不是把 .tif 改个名字，也不是普通 GeoTIFF 直接上传云端。它需要符合内部瓦片、金字塔、目录结构和可范围读取等要求。

2. 没有生成影像金字塔

没有 overview 的大影像在小比例尺浏览时会非常吃力。用户只是想看全国或全市范围，系统却读取最高分辨率数据，速度自然会慢。

3. 压缩方式选错

RGB 可视化影像可以考虑 JPEG 压缩，但 DEM、温度、降水、NDVI、分类栅格等分析型数据不建议使用有损压缩。否则像元值可能发生变化，影响后续分析。

4. 坐标系不适合前端显示

如果目标是 WebGIS 在线浏览，而影像坐标系与地图底图差异很大，服务端可能需要频繁重投影，影响瓦片响应速度。对于纯展示型影像，可考虑提前重投影到 EPSG:3857。

5. 对象存储权限和跨域配置错误

COG 放在对象存储后，经常遇到访问失败、403、跨域报错或 Range 请求无效。需要检查：

• 文件是否公开可读，或是否正确配置签名 URL。
• CORS 是否允许前端域名访问。
• 是否允许 Range 请求头。
• 返回头中是否包含 Accept-Ranges。

6. 把COG当成万能影像服务

COG 能减少很多服务端压力，但它不是所有场景的唯一答案。超高并发公开底图、复杂实时渲染、多源镶嵌、权限精细控制等场景，仍然可能需要专门的影像服务或预切片方案。

方法比较：COG、普通GeoTIFF、WMTS和影像服务怎么选

方案	适合场景	优点	限制
普通 GeoTIFF	本地分析、桌面 GIS 制图、小范围数据交换	兼容性好，使用简单	云端按需读取能力弱，大文件在线浏览慢
COG影像格式	云端存储、按需读取、遥感影像在线浏览、轻量级云原生 GIS	可放对象存储，支持 Range 请求，适合动态瓦片服务	需要正确制作和验证，前端通常仍需瓦片服务中转
WMTS/XYZ 预切片	固定底图、高并发访问、公开地图服务	访问速度快，前端接入简单	切片数量大，更新成本高，不适合频繁变化数据
GeoServer/ArcGIS Server 影像服务	企业级发布、权限管理、复杂服务能力	功能完整，可管理多种服务类型	部署维护成本较高，服务器资源压力更明显
TiTiler + COG	Python GIS 团队、云原生影像发布、动态瓦片 API	轻量、接口友好，适合对象存储中的 COG	需要一定后端部署和缓存设计

简单判断可以这样做：如果你主要做本地分析，用普通 GeoTIFF 就够；如果影像要放到云端并被按需读取，优先考虑 COG；如果是固定公共底图且访问量很大，预切片通常更稳；如果需要复杂权限、目录管理和企业平台集成，则考虑专业影像服务。

检查清单：云原生GIS中落地COG前要确认什么

• 数据目标：是用于在线浏览，还是用于像元级分析？
• 坐标系：是否需要保留原始投影，还是重投影到 EPSG:3857？
• 金字塔：是否已经生成 overview，并能被 gdalinfo 查看？
• 内部瓦片：是否为 tiled GeoTIFF，而不是条带式组织？
• 压缩方式：是否区分 RGB 展示影像和分析型栅格？
• NoData：是否正确设置透明区域或无效值？
• 对象存储：是否支持 HTTP Range 请求？
• CORS：前端访问是否存在跨域问题？
• 服务层：是否需要 TiTiler、GeoServer 或自研瓦片服务？
• 缓存：热点区域是否需要 CDN 或瓦片缓存？
• 验证：是否使用 gdalinfo 或 rio cogeo validate 检查过文件？

实践建议：不要一开始就把所有影像批量转换。先选一张典型影像，完成 COG 制作、上传、验证、QGIS 读取、WebGIS 发布和性能观察，再固化为批处理流程。

FAQ：关于COG影像格式和云原生GIS的常见问题

1. COG影像格式和普通GeoTIFF有什么区别？

COG 仍然是 GeoTIFF，但它按照云端按需读取的方式组织内部结构。普通 GeoTIFF 更适合本地完整读取，COG 更适合通过 HTTP Range 请求读取局部数据。

2. COG能不能直接在浏览器里显示？

一般不建议让浏览器直接解析 COG。实际 WebGIS 项目通常使用 TiTiler、GeoServer、自研服务或其他中间层，把 COG 转成前端可加载的 XYZ 瓦片或图片接口。

3. QGIS可以打开远程COG吗？

可以。QGIS 依赖 GDAL，通常可以通过 HTTP 地址或 /vsicurl/ 方式读取远程 COG。但前提是服务器支持 Range 请求，并且 COG 文件本身制作正确。

4. COG适合DEM和分类栅格吗？

适合，但要注意压缩方式。DEM、分类栅格、指数栅格等需要保留像元值的数据，应优先使用无损压缩，不要随意使用 JPEG 这类有损压缩。

5. COG和瓦片服务哪个更快？

固定预切片的 WMTS 或 XYZ 服务通常前端访问最快，尤其适合高并发公共底图。COG 的优势是存储简单、更新方便、可按需读取，适合云端影像管理和动态瓦片生成。两者并不冲突，很多项目会用 COG 做源数据，再用服务层输出瓦片。

6. 云原生GIS是不是必须使用COG？

不是。COG 主要解决栅格影像云端读取问题。云原生 GIS 还可能涉及 GeoParquet、PostGIS、矢量瓦片、STAC、对象存储、容器化服务和弹性计算。是否使用 COG，要看你的数据类型和访问模式。

7. 批量制作COG应该用什么工具？

常见选择是 GDAL 命令行、Python 调用 GDAL、Rasterio 或 rio-cogeo。对于生产流程，建议把转换、校验、上传和日志记录写成脚本，避免人工逐个处理。

结论：COG是云原生GIS处理大影像的基础能力

COG影像格式的核心作用，是让 GeoTIFF 在云端也能被高效、局部、按需地读取。它通过内部瓦片、影像金字塔和 HTTP Range 请求，把大体量遥感影像从“必须整幅下载”变成“需要哪里读哪里”。

对于 GIS 学生、遥感工程师、WebGIS 开发者和空间数据平台建设者来说，掌握 COG 不只是学一个新格式，而是理解云原生 GIS 栅格数据组织方式的入口。

实际项目中可以按照这个路线落地：先用 GDAL 制作合格 COG，再上传到支持 Range 请求的对象存储，然后用 QGIS 验证读取，最后根据业务选择 TiTiler、GeoServer、自研服务或预切片方案发布到 WebGIS。

记住一句话：COG 不是万能影像服务，但它是云原生 GIS 中管理和发布大影像数据非常重要的基础格式。