map_tutorial

第 5 章：在线底图与天地图生态

——站在巨人的肩膀上：切片原理、国家标准与坐标系迷局

1. 开篇段落

在第 1 至 4 章中，我们主要处理的是存储在本地硬盘上的“死数据”。无论是几百兆的 TIFF 影像还是几个 G 的 Shapefile，它们都是静态且有限的。然而，当我们试图构建一个“全球”级别的地图应用时，数据量将激增至 PB（Petabyte）级别。无论是存储成本还是网络带宽，都无法支撑将全量数据一次性传输给用户。

本章将带你进入在线地图服务（Online Map Services）的世界。我们将从底层的瓦片金字塔（Tile Pyramid）原理讲起，揭示 Google Maps、OpenStreetMap 和天地图是如何让全球地图在浏览器中“秒开”的。我们将重点剖析中国官方的天地（Tianditu）生态，深入解读其特殊的“底图+注记”分层架构、双重坐标体系（_c 与 _w 的爱恨情仇），以及如何在工程实践中解决最令人头疼的“火星坐标”偏移问题。

---

2. 核心论述：切片地图的物理原理

2.1 瓦片金字塔模型 (The Tile Pyramid)

在线地图的核心思想是“分而治之”和“预渲染”。服务器不是实时画图，而是预先将地球按照不同的比例尺切成数以亿计的小图片（瓦片，Tile），存在服务器硬盘里。

逻辑结构

想象一个金字塔结构：

• Level 0 (顶层)：用 1 张（或几张）图片覆盖整个地球。用户看到的是全球概览。
• Level 1：将 Level 0 的每一张图片呈“田”字形切分为 4 张。
• Level $z$：每一张图片继续一分为四。

%% ASCII 示意图：四叉树结构
       [Level 0]                  1 Tile (256x256 px)
           |
     +-----+-----+
     |           |
  [Level 1]   [Level 1] ...       4 Tiles
     |
  +--+--+
  |     |
[L2]   [L2] ...                   16 Tiles

数学规律

假设瓦片大小为标准的 $256 \times 256$ 像素，对于 Web 墨卡托投影：

1. 瓦片数量：第 $z$ 级的瓦片总数为 $N = 4^z$（或者是 $(2^z)^2$）。
2. 空间分辨率： 在赤道处，地球周长约为 $C \approx 40,075,017$ 米。第 $z$ 级的像素分辨率（米/像素）近似公式为： \(R_z = \frac{C}{256 \times 2^z}\) 由此可见，每增加一级，分辨率数值减半（即清晰度提高一倍）。

Rule of Thumb (尺度直觉)：

• Level 0-2：看大洲轮廓。
• Level 10-12：看城市路网结构。
• Level 15：约为 4.7米/像素，能分清街区。
• Level 18：约为 0.6米/像素，能看清房屋轮廓。这是绝大多数民用卫星影像的极限。
• Level 20+：需要无人机或航空影像支持，能看清车辆、斑马线。

---

2.2 三服务协议：WMS, WMTS 与 XYZ

在调用地图时，你实际上是在和服务器“对话”。根据对话方式不同，分为三种流派：

协议	全称	性质	描述
WMS	Web Map Service	动态裁切	OGC 标准。客户端发给服务器一个经纬度框 (BBOX)，服务器现场画一张图传回来。优点：灵活、实时；缺点：慢，服务器负载高，无法缓存。
WMTS	Web Map Tile Service	静态切片	OGC 标准。客户端请求特定的行(Row)、列(Col)、级(Level)。服务器直接返回预存的图片。优点：标准化、支持多种投影；缺点：配置 XML 极其复杂。
XYZ	(Slippy Map)	事实标准	互联网非官方标准（Google/OSM 推广）。直接通过 URL 模板访问文件路径。优点：极简、极快、缓存友好。

XYZ 的 URL 模板： 这是本章最重要的公式之一。几乎所有 Web 前端库都通过这个模板加地图： \(\texttt{https://domain.com/}\{z\}/\{x\}/\{y\}\texttt{.png}\) 其中 $z$ 是缩放等级，$x$ 是列号（经度方向），$y$ 是行号（纬度方向）。

---

2.3 天地图生态详解

天地图（Map World） 是国家地理信息公共服务平台。与商业地图（高德、百度）不同，它具有官方性（国界线绘制标准）、数据分层性和坐标纯净性。

A. “三明治”分层策略

天地图不提供“一张画好所有东西的图”，而是提供积木。你需要像做三明治一样叠加图层：

1. 底层：底图 (Base Layer)
   • 影像底图 (img)：卫星遥感影像，那是地球的真面目。
   • 矢量底图 (vec)：只有背景色、水系、绿地和浅色道路，没有文字。
   • 地形底图 (ter)：带有山体阴影（Hillshade）的晕渲图。
2. 顶层：注记 (Annotation Layer)
   • 影像注记 (cia)：透明背景，上面印着白色的地名、名。
   • 矢量注记 (cva)：透明背景，印着黑色的地名。
   • 地形注记 (cta)：配合地形图的注记。

常见错误：初学者常犯的错误是只加载了 vec，结果发现地图上光秃秃的一个字都没有；或者只加载了 cva，结果看到全是悬浮在空中的文字。必须成对加载。

B. 两个平行宇宙：投影体系

天地图同时提供两套切片矩阵，通过 URL 中的后缀区分。选错后缀是导致地图变形、无法叠加的根源。

1. 经纬度投影 (LatLon, EPSG:4490 / EPSG:4326)
   • 标识：URL 中包含 _c (代表 China 或 Cartesian)。
   • 切片形状：矩形（非正方形）。因为在地理坐标系中，经度和纬度的度数虽然相等，但实际距离随纬度变化。
   • 适用场景：政府项目、GIS 专业分析、需要与北斗/CGCS2000 矢量严格套合的场景。
   • 兼容性：Web 前端库（如 Leaflet/Mapbox默认不支持，需额外插件或配置自定义 CRS。
2. 球面墨卡托投影 (Web Mercator, EPSG:3857)
   • 标识：URL 中包含 _w (代表 Web)。
   • 切片形状：正方形 (256x256)。
   • 适用场景：互联网大众应用。
   • 兼容性：与 Google Maps、OSM、Bing Maps 完全一致，现有 Web 库开箱即用。

C. URL 构造解剖

一个典型的天地图 XYZ 请求链接如下： http://t0.tianditu.gov.cn/img_w/wmts?SERVICE=WMTS&REQUEST=GetTile&VERSION=1.0.0&LAYER=img&STYLE=default&TILEMATRIXSET=w&FORMAT=tiles&TILEMATRIX={z}&TILEROW={y}&TILECOL={x}&tk=你的密钥

• Subdomain (t0 - t7)：为了突破浏览器对同一域名并发请求数的限制，通常随机轮询 t0 到 t7。
• Layer (img)：指定数据类型。
• MatrixSet (w)：指定投影体系（这里是 Web 墨卡托）。
• TileMatrix/Row/Col：对应的 XYZ 变量。
• tk (Token)：必填的访问密钥。

---

3. 常见陷阱与错误 (Gotchas)

本章的陷阱主要集中在坐标系和权限配置上。

陷阱 1：坐标系的“巴别塔” (WGS84 vs. GCJ-02 vs. BD-09)

这是在中国做地图开发最大的坑，没有之一。

• WGS84 / CGCS2000：
  • 谁在用：天地图、GPS 芯片原始读数、OSM、Google Maps (卫星图部分)。
  • 关系：CGCS2000 是中国国家坐标系，与 WGS84 差异极小（厘米级），在 Web 地图中通常视为同一个。
• GCJ-02 (火星坐标)：
  • 谁在用：高德、腾讯、Google Maps (中国区矢量街道部分)。
  • 特征：国家规定的加密偏移，为了安全，随机偏离真实位置几百米。
• BD-09：
  • 谁在用：百度地图。
  • 特征：在 GCJ-02 基础上再次加密。

致命错误场景： 你手头有一份从高德地图抓取的 POI 数据（GCJ-02），然后你把它叠加到了天地图（CGCS2000）上。 结果：所有的餐馆“漂移”到了马路对面或者河里。

解决方案：同系才能叠加。

1. 要么把 POI 数据反向纠偏转回 WGS84/CGCS2000。
2. 要么把天地图（如果可能）进行偏移（不推荐，底图很难偏）。
3. Rule of Thumb：做专业 GIS / 遥感 / 科学数据分析，坚决使用 WGS84/CGCS2000，远离火星坐标。

陷阱 2：混合使用 _c 和 _w

• 现象：在 Web 地图库（如 Cesium 或 Leaflet）中加载天地图，发现地图被压扁了，或者位置完全不对。
• 原因：你的地图容器（Map View）定义的是 EPSG:3857（墨卡托），但你请求的 URL 却是 img_c（经纬度投影）。
• 调试：检查 URL。如果是 Web 项目，99% 的情况你应该使用 _w 系列。

陷阱 3：Key (Token) 的限制

• 现象：本地开发（localhost）时地图正常，一部署到公司服务器，地图就变白或报错 403。
• 原因：天地图的 Key 分为“浏览器端”和“服务器端”。浏览器端 Key 通常会绑定 Referer 白名单（即只允许特定的域名访问）。
• 调试：去天地图控制台检查 Key 的类型和白名单设置。如果是桌面 GIS（QGIS），通常使用“服务器端”类型的 Key 或者不限制 Referer 的浏览器 Key。

---

4. 本章小结

1. 切片原理：Web 地图通过 瓦片金字塔 ($4^z$) 结构，利用预渲染的小图片实现全球数据的快速加载。
2. 数据分层：天地图不提供“整图”，而是将 底图 (img/vec/ter) 与 注记 (cia/cva/cta) 分离，开发者必须像叠三明治一样组合使用。
3. 投影二元论：
   • _w (Web Mercator, EPSG:3857)：方形瓦片，适合 Web 公众应用，兼容 Google/OSM。
   • _c (LatLon, EPSG:4490)：矩形瓦片，适合专业 GIS 与国家标准数据对接。
4. 坐标系铁律：天地图使用 CGCS2000 (≈WGS84)。严禁直接叠加高德/腾讯 (GCJ-02) 或百度 (BD-09) 的数据，必须先进行纠偏转换。

---

下一章：吉林一号影像与“全国一张图 / 全球一张图”