搞 WebGIS 的同行最近群里被问得最多的问题之一就是“TMS 和 WMTS 到底啥区别项目里到底该用哪个”。这俩名字看着像兄弟实际出身、行为习惯、接口细节差别挺大。直接给结论TMS 是社区里的“土办法”WMTS 是 OGC 的“正规军”。但如果只记住这一句话落地时还是会在瓦片地址上栽跟头。这篇文章我会把这两个服务从原理、差异、应用场景到天地图 WMTS 的接入实操、常见白屏和上下颠倒问题一次性讲清楚希望能帮到正在选型或者被地图服务折磨的你。1. 为什么地图要切瓦片TMS 和 WMTS 到底解决了什么问题1.1 在地图上画格子瓦片是怎么来的先回到最底层。浏览器里打开一张在线地图并不是从服务器拉一张全世界的高清图像那样一张图可能几个 G谁也扛不住。行业里通行的做法是把地图按照缩放级别切成无数个正方形小格子每个格子大小通常固定为 256×256 像素。缩放级别 z 每加 1地图被多切一刀z 级别下横向和纵向各有 2^z 个格子格子一多用户看到哪里就只加载哪里速度快还不费流量。这里就有个很关键的问题服务器把这些切片放在磁盘上必须有一套统一的“编号方式”不然前端拿着坐标找瓦片服务器也不知道你在要哪一块。于是出现了各种瓦片寻址方案。TMS 和 WMTS 本质上都是在回答同一件事给你一个格子横坐标 x、纵坐标 y、缩放级 z我应该去哪条 URL 上把它拿回来。只不过TMS 的答案比较简单粗暴WMTS 的答案则写了一大本规范。1.2 同一个想法两个不同出处OSGeo 与 OGCTMS 的全称是 Tile Map Service瓦片地图服务最早由 OpenStreetMap 社区推动后来归到 OSGeo 下面维护。它的设计初衷非常朴素为预渲染的地图瓦片提供一个简单的访问规则路径通常长这样/{版本号}/{图层名}/{z}/{x}/{y}.png因为整个地址就是一条静态文件路径很多静态文件服务器甚至不用写后端逻辑直接把目录映射出去就能用。好处是极度轻量坏处是没有统一的服务发现机制服务端也基本不告诉你这个图层有什么投影、什么格式全靠调用方心里有数。WMTS 的全称是 Web Map Tile ServiceWeb 地图瓦片服务注意前面多了个 Web但这不是普通的网页瓦片而是 OGC开放地理空间联盟Open Geospatial Consortium制定的正式标准版本号常见的是 1.0.0。OGC 这个组织在 GIS 圈子里地位很高WMS、WFS、WCS 这些服务标准都出自它。WMTS 想解决的核心问题是“互操作”不同厂商的 GIS 平台、桌面软件、Web 端只要都支持 WMTS就能通过一套标准流程拿到服务能力描述再自动生成请求地址。打个比方TMS 像是小区里大家口头约定“快递放东边柜子第三层”好用但只对熟人有效WMTS 则是物业张贴的正式规则规定了柜子编号、层高、开门方式任何一个新来的快递员照着规则都能找到地方。1.3 一句话给初学者先建立印象初学者可以先记住这么几个锚点TMS 跟 XYZ 瓦片长得非常像区别主要在 y 轴取数方向WMTS 比 TMS 多了一个“能力文档”客户端可以通过它自动发现图层天地图这类公共底图平台对外提供的基本都是 WMTS 服务但你在 Leaflet 里直接用 XYZ 方式去调也能跑通。先有这个概念后面的细节就顺理成章了。2. 挖出 TMS 和 WMTS 的本质区别坐标原点、元数据与接口风格2.1 最容易被忽略的硬伤y 轴方向正好相反把 TMS 和 WMTS 同时摆在你面前URL 乍一看几乎一样最难防的坑就在 y 轴上。我们平时接触最多的 XYZ 瓦片地址也就是 Google Maps 带火的方案它的 y 坐标是从地图顶部开始数的最上面一行是第 0 行越往下 y 值越大。TMS 恰恰相反它把 y 坐标定义为从地图底部开始数最下面一行才是第 0 行。一个从北往南数一个从南往北数两者之间差了一个翻转。在某个缩放级别 z 下一张地图一共有 2^z 行瓦片所以换算公式是y_xyz (2^z - 1) - y_tms y_tms (2^z - 1) - y_xyz举个例子z2 时地图共有 4 行。如果 XYZ 方案中你想定位第 2 行、第 3 列那块瓦片对应的 TMS 行号就是 4-1-21。如果你拿着 XYZ 的行号直接去 TMS 服务器里取会取回来一块完全不相干的瓦片。视觉上的表现是地图上下颠倒、瓦片错位、甚至可以拼出一个镜像的诡异地图。这个问题在 Leaflet 里尤其经典。Leaflet 默认的L.tileLayer按 XYZ 格式拼接 URL加载 TMS 服务时必须显式加一个tms: true参数它才会在发送请求前自动翻转 y 坐标。而 QGIS 里加载 TMS 时也会在“高级”设置里让你选是否使用 TMS 规则。实际操作中很多同学接到同事给的一个瓦片地址没问来源直接往 Leaflet 里一贴出现乱图后第一反应是“服务器挂了”其实八成只是 y 轴规则不对。2.2 WMTS 有“说明书”TMS 往往是“裸地址”TMS 和 WMTS 的第二个大差异在于服务能不能“自解释”。WMTS 要求服务器提供一个GetCapabilities操作你只要在服务地址后面加上参数就能拿到一份 XML 格式的能力说明书。在这份文档里客户端可以查到这个服务一共提供了哪些图层每个图层可用哪些样式、哪些图片格式服务使用了哪几套瓦片矩阵集合TileMatrixSet也就是用的什么坐标系每一层瓦片矩阵的左上角原点坐标、瓦片数量、比例尺分母支持 RESTful 风格地址还是 KVP 风格地址。所以GIS 软件拿到一个 WMTS 地址后可以自动列出图层用户不需要记住图层名也不需要手写 TILEROW、TILECOL 这些参数。这就是标准的力量。TMS 也有一个光秃秃的元数据扩展路径通常是/1.0.0/{图层名}能返回 JSON 或 XML 描述但它是可选的很多轻量级 TMS 服务根本不做。大多数 TMS 就是一条裸 URL图层名、投影、格式全靠人工约定。你在 QGIS 里添加 TMS 服务时经常被要求手动填写图层名、坐标参考系、瓦片最小级别原因就在这。2.3 接口风格KVP 与 RESTful 的差别WMTS 规范里提到两种常见的接口绑定方式。第一种叫 KVP就是直接在 URL 上挂一堆查询参数https://example.com/wmts?SERVICEWMTSREQUESTGetTileVERSION1.0.0LAYERroadsSTYLEdefaultTILEMATRIXSETWebMercatorTILEMATRIX10TILEROW512TILECOL768FORMATimage/png这种写法对网关、防火墙、缓存服务器都比较友好因为你不需要设计复杂的路径映射规则只要让后端能解析 query string 就行。第二种叫 RESTful参数直接放在路径里https://example.com/wmts/roads/default/WebMercator/10/512/768.png因为路径有固定层级CDN 缓存起来非常方便很多公共服务更愿意用这种方式。TMS 路线本质上也是一种 RESTful 风格但它没有能力文档和完整参数体系所以只能说“形似 REST但没进标准体系”。新手容易把 WMTS 等同于 XYZ 瓦片在 Console 里看到一堆TILEMATRIX、TILEROW就蒙了。其实你只需要知道在 3857 标准 Web 墨卡托瓦片矩阵下TILEMATRIX对应缩放级别 zTILECOL对应 xTILEROW对应 y。把 WMTS 的请求参数翻译过来仍然是“z/x/y”那一套只是披了一件更正式的“外套”。2.4 TMS 与 WMTS 核心差异对照表对比项TMSWMTS全称Tile Map ServiceWeb Map Tile Service标准组织OSGeo 社区规范OGC 正式标准发布背景OSM 生态早期实践面向企业级互操作瓦片 y 轴方向从南往北底部为 0常用实现从北往南顶部为 0能力文档可选简单 XML/JSON强制提供 GetCapabilities请求风格文件路径式同时支持 KVP 与 RESTful图层自动发现基本不支持客户端可自动列图层坐标系常用 Web 墨卡托也可私有约定可在 TileMatrixSet 中声明多套产品生态GeoWebCache、MapProxy、Tilestache 等QGIS、ArcGIS、OpenLayers、GeoServer 等学习成本低略高参数名称多这里要强调一点TMS 不代表比 WMTS 低级。TMS 的轻量特性让它在内网快速搭建、小规模切片发布时非常有优势。WMTS 更像一个“管理系统”适合需要多人协作、跨系统交互的场景。3. 应用场景怎么选从轻量瓦片缓存到企业级地图分发3.1 选择 TMS 的典型场景先说要选 TMS 的四种情况。第一种是自建轻量瓦片服务。比如你有一批绘制好的历史地图、施工图或者内部专题图切成了瓦片只想丢到内网服务器上给几个人看。用 TMS 就很简单目录结构放对用 Nginx 指向目录Leaflet 加tms: true5 分钟就能跑起来。这时候引入 WMTS 反而麻烦因为你需要生成正式的 Capabilities 文档还要维护图层元数据。第二种是底层切片缓存工具之间的兼容。GeoWebCache、MapProxy 这些中间件既能输出 TMS也能输出 WMTS。但有些老的缓存目录直接就是按 TMS 结构存的没必要为了“用标准”再转换一遍直接用 TMS 公开给前端就行。第三种是某些老牌客户端只认 TMS。比如一部分移动端离线地图 SDK、桌面 GIS 插件内部写死了/z/x/y或/z/x/y.png的路径你给它 WMTS 地址它反而不认识这种情况就继续延用 TMS。第四种是你自己维护一套切片目录想避开复杂的请求参数解析。TMS 的最大好处是它连服务端程序都可以省略静态文件目录即服务。对需求简单的小团队来说省下来的运维成本非常可观。3.2 选择 WMTS 的典型场景如果项目踩到下面几条就该坚定选 WMTS。跨平台、跨部门共享地图时WMTS 的自动发现能力能帮你省掉大量沟通成本。对接方只要拿到一个根地址通过 GetCapabilities 就能看到图层列表、坐标系、投影信息不需要你写一页文档解释“第 3 层注记图层叫什么名字、格式是 png、瓦片原点在哪”。GIS 平台型项目比如省级地理信息公共服务平台、智慧城市基础底图、自然资源“一张图”通常要求服务符合行业标准WMTS 这种 OGC 标准接口更容易通过合规性审查。天地图及其各省级节点几乎都对外提供了 WMTS 服务这就是最典型的应用样本。还有一类场景是客户端种类很多要用一个接口兼容 QGIS、ArcGIS、OpenLayers、Mapbox、超图等不同产品。WMTS 的元数据机制让这些软件都能自动识别不需要为每个软件单独配置不同的 URL 模板。3.3 给项目做技术选型时的判断顺序我的习惯是按下面这 4 个问题顺序过一遍服务范围是公网跨组织共享还是内网小范围使用公网或跨组织优先 WMTS内网且调用方固定TMS 够用。需要对接方自动获取图层信息吗需要就 WMTS所有参数自己可控TMS 也行。是否有合规或验收要求比如要求符合 OGC 标准有WMTS。前后端团队更熟悉哪种模式如果团队只写过L.tileLayer对 WMTS 参数不熟可以先确认服务端是否支持 TMS有时候 TMS 反而更能保证项目进度。这个顺序不是拍脑袋定的而是从交付和售后成本考虑。协议越标准后面换人维护、对接新系统越省心协议越轻量前期开发越快。两者本质是稳定性和效率的权衡不存在哪个“更好”。4. 天地图 WMTS 地址申请与 QGIS、Leaflet 接入实操4.1 第一步拿到天地图开发者 Key用天地图 WMTS 服务第一件事是申请tk参数也就是开发者密钥。流程不复杂在天地图官网注册账号进入“控制台”创建一个应用选择服务类型时会看到“浏览器端”和“服务端”等选项提交后系统会生成一串 key。实际操作中我建议把 key 放到服务端配置文件里不要硬编码在前端页面。如果只是个人测试直接放前端问题也不大但一旦被他人盗用额度会被耗光生产环境还是老实点。申请时还有一个常见纠结选择“浏览器端”还是“服务端”简单说纯前端展示、无后端中转就选浏览器端有后端转发或服务端生成瓦片就选服务端。这个选择不仅影响配额也影响部分接口能否调用尤其 QGIS 这类桌面软件调用时有些版本对 key 类型很挑剔。如果你在 QGIS 里反复提示“无效的 key”不妨重新建一个服务端密钥试试。4.2 第二步读懂 GetCapabilities 返回的 XML拿到 key 后先在浏览器里直接打开 WMTS 能力文档https://t0.tianditu.gov.cn/mapservice/swmts?servicewmtsrequestGetCapabilitiesversion1.0.0tk你的Key正常返回时你会看到一大段 XML。不要被吓到重点看三块。第一块是图层名称也就是Layer节点里的名字。天地图常见的有vec矢量底图、img影像底图、cva矢量注记、cia影像注记。你在 QGIS 里看到的图层列表就是从这堆名字里读出来的。第二块是TileMatrixSet节点。比如MatrixWidth、MatrixHeight、ScaleDenominator、TopLeftCorner。这里面有个很关键的信息是原点坐标。Web 墨卡托矩阵集的原点通常写的是20037508.342789244也就是 EPSG:3857 范围的上边界y 轴向下增长。这个坐标系下的瓦片和 OSM、Google 的瓦片是完全对齐的。第三块是Format节点。天地图的影像格式有的写image/png有的写tiles。某些客户端对tiles这种自定义 MIME 类型识别不了最终加载出来空白一片。遇到这种情况建议手动把 FORMAT 参数改成image/png再试。4.3 第三步拼出一条可用的 GetTile 地址看懂元数据文档后拼 GetTile 地址就很简单了。以天地图影像底图为例常见的一种 RESTful 风格地址如下https://t0.tianditu.gov.cn/img_w/wmts?SERVICEWMTSREQUESTGetTileVERSION1.0.0LAYERimgSTYLEdefaultTILEMATRIXSETwFORMATtilesTILEMATRIX{z}TILEROW{y}TILECOL{x}tk你的Key其中TILEMATRIXSETw表示 Web 墨卡托投影矩阵{z}、{x}、{y}是前端渲染时替换的动态参数tk就是你申请到的 key。如果换成vec、cva、cia只需修改 LAYER 参数即可。这里提醒一点天地图的注记层cva、cia在单独叠加时背景是透明的适合覆盖在底图之上。如果你把注记层单独当底图用会看到全是字、没有图看起来像“花屏”那不是服务坏了是图层叠加逻辑错了。如果不想用这种带 query string 的 WMTS 地址还可以用纯路径式地址。但它对路径层级有强要求而且在不同节点上可能会有差异我用下来觉得最常见的还是上面这种带参数的写法通用性更好。4.4 QGIS 和 Leaflet 里怎么接QGIS 里的接入路径是“数据源管理器”里的“瓦片服务WMTS”。新建一个连接把上一节的 GetCapabilities 地址带着tk参数完整填进去点击连接后 QGIS 会自动解析 XML并在左下角列出所有图层。把影像和注记拖进画布就会看到天地图底图正常加载。如果在 QGIS 里直接添加“XYZ 瓦片”也能用类似地址https://t0.tianditu.gov.cn/img_w/wmts?SERVICEWMTSREQUESTGetTileVERSION1.0.0LAYERimgSTYLEdefaultTILEMATRIXSETwFORMATtilesTILEMATRIX{z}TILEROW{y}TILECOL{x}tk你的Key但这里要注意XYZ 瓦片源的 y 坐标是从北到南天地图w矩阵集也是从北到南所以不需要额外翻转直接能用。如果你在 Leaflet 里写L.tileLayer代码大概是这样L.tileLayer( https://t{s}.tianditu.gov.cn/img_w/wmts?SERVICEWMTSREQUESTGetTileVERSION1.0.0LAYERimgSTYLEdefaultTILEMATRIXSETwFORMATtilesTILEMATRIX{z}TILEROW{y}TILECOL{x}tk你的Key, { subdomains: [0, 1, 2, 3, 4, 5, 6, 7] } ).addTo(map);这行代码里唯一要注意的是subdomains数组因为天地图的服务地址写的是t0到t7如果你只填t{0-7}这种写法需要对应配置好子域。我习惯显式写数组不容易出错。4.5 界面里“没有自定义参数栏”的解决办法搜索“天地图 WMTS 没有自定义参数栏”的人不少我一开始也在这上面卡过几次。这个“自定义参数栏”通常是 QGIS 等客户端里设置 WMTS 连接时用来额外传递tk、style、version等参数的表格区域。但不同版本、不同安装包这个栏目的入口位置差别很大。如果你在 QGIS 的 WMTS 连接对话框里找不到“自定义参数”区域最简单的办法是把tk参数直接放进连接 URL 里不要设为空连接再单独填 key。也就是把带着tk你的Key的完整 GetCapabilities 地址粘贴到“服务 URL”框中QGIS 发起 GetCapabilities 请求时自然会携带这个参数后续获取瓦片也会沿用。还有一个办法是给当前图层设置“汇报参数”不同版本的叫法不一样有的在“高级”折叠菜单里有的在“图层选项卡”右侧。如果实在是找不到就别纠结 UI 了直接走 XYZ 瓦片方式接入。你只需要把{z}、{x}、{y}三个占位符放进 URLtk作为固定参数写死前端地图库都能正常解析。这个方法绕过了 WMTS 客户端里所有复杂的参数栏是最“笨”但也最不依赖插件版本的做法。5. 实战中常见的 4 个坑与排查心得5.1 瓦片上下颠倒、地图乱跳出现这种现象第一个想到的就是 y 轴方向。曾经有个项目前端整个页面是黑的打开浏览器开发者工具一看瓦片请求 404 一堆。后来发现项目拿到的是 TMS 地址前端却按 XYZ 加载y 坐标没有翻转。这个问题最好排查直接把 URL 里的 y 值和基准地图同位置瓦片的行号对比如果一个是另一个的镜像关系就是翻转没跑。另一个容易被误判的场景是地图看起来局部正常缩放几级后开始错位。这通常是瓦片矩阵级别和缓存的经纬度范围不匹配服务端切片的最小级或最大级设置错了。你把缩放范围限制到服务端实际支持的层级症状就会消失。5.2 白屏、灰块、图层列表空白天地图接入中图层列表空白最常见原因是 GetCapabilities 请求没把tk传过去。很多桌面软件连接 WMTS 时会先请求能力文档如果你只在“图层参数”里写了 key能力文档请求并没有带上服务端直接返回错误。解决办法如前面所说把 key 拼到连接地址里。还有一种白屏是因为 FORMAT 参数的问题。天地图的影像底图在 Capabilities 里声明的格式可能是tiles但某些 Web 端根本不会渲染这种 MIME 类型。手动把FORMATtiles改成FORMATimage/png刷新就能看到图。类似的坑在 ArcGIS 的影像服务里也有服务端说支持的格式是一套客户端能渲染的是另一套两个集合求交集才是最终能用的格式。5.3 坐标参考系对不上你叠加的业务数据如果是经纬度坐标而瓦片底图选了 EPSG:3857 的w矩阵集两者不在一个投影下底图要么飞走要么变形。很多人觉得地图“怎么歪了”其实不是网络慢是投影没对齐。天地图提供了两套矩阵集一套是 Web 墨卡托一套是经纬度直投。如果你想跟 OSM、Google 风格对齐用 Web 墨卡托如果业务图层本身是 4326、且你不想做投影转换可以找对应的经纬度矩阵集。判断方法仍然是看 GetCapabilities 里的TopLeftCorner如果原点 x 是 -180.0多半是经纬度矩阵如果是-20037508.34左右就是 Web 墨卡托。项目里如果混用最好在建图层时就强制约定一套坐标系不要想当然。5.4 配额、缓存和服务可用性的取舍公共底图服务不是无限免费刷的。天地图的 key 有调用配额生产环境高并发时非常容易被限流表现是瓦片加载到一半突然大量 404 或 429。建议加一层本地瓦片缓存把访问过的瓦片缓存到本地磁盘或对象存储里。Nginx 的缓存配置就能实现简单缓存不需要引入太重的东西。另外公共服务的可用性是“尽力而为”不会为你的业务数据背 SLA。对项目稳定性要求高的场景内部应该用 GeoWebCache、MapProxy 这类软件再发一层缓存切片服务让前端永远只访问你自己可控的服务。我自己在正式项目里的一般做法是测试阶段直连天地图验证效果上线前通过本地缓存中间件把高频瓦片预热好前端始终指向本地域名。这样既保底图新鲜又降低公共服务的压力。说到排查工具我习惯先在浏览器里直接打开 GetCapabilities 和一张 GetTile 地址。如果这两条地址在浏览器里都能正常返回内容那么 99% 的接入问题都出在客户端参数拼写上而不是服务端。先用最简单的方式验证服务本身再回头看自己写的 URL 模板别一开始就怀疑“天地图挂掉了”这个习惯能帮你省下不少时间。最后再分享一个小经验拿到任何陌生瓦片服务时不要急着写代码先花 10 分钟看它的能力文档或元数据。确认三件事瓦片行号从哪边开始数、支持的坐标系是什么、图片格式是什么。这三件事确认完TMS 还是 WMTS 的区别对你来说就只是 URL 拼写的差别了。地图瓦片这东西协议永远在变但“先读说明书再动手”这条原则是真的不会过时。