简介面向地图服务开发与地理信息系统集成场景的技术参考文档系统整理了谷歌地图、搜搜地图和天地图三类瓦片服务的核心参数。文档重点对比各自的切片原点、全图范围、地图投影、坐标轴方向与显示级别并列出从低到高各缩放级别的比例尺集合帮助开发者准确理解不同瓦片服务的坐标体系差异避免在地图切片拼接、接口对接和坐标转换时出现错位或越界问题。资源以docx文档形式提供共1个文件压缩包仅15KB内容精炼、便于查阅适合作为日常开发备忘或团队培训材料。文档中对切片原点数值、全图边界、比例尺序列等关键字段均给出了明确记录方便在不同地图服务之间做数据对齐或参数校验。目前已有100人学习下载适合初入地图服务领域或需要接入多源瓦片地图的工程师快速掌握参数配置要点。1. 瓦片地图服务参数三张几乎一模一样的参数表为什么拼出的世界完全不一样三份地图服务的参数表放在一起看起来像同一个模子刻出来的全图范围都落在 20037508.34 附近投影都写着“WGS84 Web Mercator”比例尺集合里全是相隔两倍的浮点数。可真把它们的瓦片拿进同一个工程叠加错位肉眼可见有的上下颠倒有的东移几十个像素找不到北。这些参数表的玄学之处在于真正决定地图能不能拼上的不是那个巨大的范围数字而是三个容易被忽略的细节——切片原点放在左上角还是左下角、Y 轴正方向朝哪边、显示级别从第几级开始。这三个细节组合起来就是一套瓦片编号规则规则不同同一经纬度对应的瓦片行列号就不同缓存对不上、拼接对不上、跨平台接入也必然翻车。这篇内容把三套参数逐一拆开从 Web Mercator 为什么把原点放在 20037508 附近到 XYZ 与 TMS 两种瓦片方向的由来再到比例尺集合里每条数值的推导方式最后落到混用时的排查顺序。搞清楚这套机制比记住三个服务的参数值值钱得多——下次拿到任何新地图服务的参数文档你都能直接判断它会在哪一层、哪个方向出错。2. Web Mercator 网格数学切片原点为什么偏偏落在 20037508 附近2.1 从经纬度到瓦片坐标一个原点、四象限、一整套世界划分Web Mercator 的核心是把地球套进一个球半径 R6378137 米的球体然后做墨卡托投影。X 方向公式是经度直接乘以 RY 方向是对纬度做对数映射。当纬度和经度都取最大范围时X 的跨度是 2πR约等于 40075016.68557849 米左右各一半就是 ±20037508.342789244。这里的关键点来了世界范围左右对称但瓦片地图的“原点”并不放在世界中心 (0,0)而是放在边界上。谷歌地图的参数表格里切片原点写的是 (-20037508.342789199, 20037508.342789199)Y 轴正方向向下所以原点在左上角。这意味着第 0 级只有一张瓦片时它的范围就是整张世界地图瓦片编号 (0,0) 覆盖的是从原点开始向下的整个方块。随着级别增加每级把世界一切为二第 1 级是 2×2 张瓦片、第 2 级是 4×4、第 z 级是 2^z×2^z。原点不动网格越切越细这就是所谓的“瓦片金字塔”。实现层面另一个更容易被忽略的细节是浮点常数。表格中搜搜地图的原点是 (-20037508.342789244, 20037508.342789091)而谷歌是 (-20037508.342789199, 20037508.342789199)。前者比 2πR 精确到更多小数位。这两个值相差约 4.5×10^-8 米在瓦片坐标里可以忽略不计但如果你在代码里用“精确相等”去判断两个服务是否共用同一套原点和全图范围就会得到错误的结论。更稳的做法是把全图范围当作带少量冗余的边界而不是精确数学常量。2.2 正 Y 向下还是向上XYZ 与 TMS 两个派系的分水岭同一个 Web Mercator 世界瓦片编号却有两种互不相容的约定。谷歌地图的 Y 轴正方向向下这是 XYZ 约定瓦片行号从左上角开始向下递增跟屏幕像素的扫描顺序一致。搜搜地图的参数表则写的是“Y 轴正方向向上”这是 TMSTile Map Service约定瓦片行号从下往上递增更接近数学坐标系里的习惯。这两种约定直接导致瓦片 y 坐标的换算公式。假设级别 z那么全球共有 2^z 行XYZ 约定里第 y 行对应 TMS 约定里的 2^z-1-y 行。反之亦然。看起来只是减一下再反个向实际后果却非常严重如果某个图层服务用 XYZ 编号生成了瓦片而你用 TMS 规则去请求得到的是另一行的内容地图会在垂直方向错开整行严重的直接上下颠倒。搜搜这个 TMS 取向并非孤例很多非浏览器的瓦片服务和地图数据库都默认 TMS因为“行号从南到北递增”更符合地理数据的存储习惯。明白这两点之后三张参数表各自的差异就都有了原因投影决定 X 方向数值跨度原点位置决定瓦片 (0,0) 对应的地理位置Y 轴方向决定行号增长方向级别范围决定金字塔在哪些层开放。这些不是随随便便的参数而是一套完整的地图切分协议。3. 三套参数横向拆解谷歌、搜搜、天地图各自藏了什么3.1 谷歌左上角原点、0 到 17 级、Y 向下谷歌这套参数的完整语义是全图范围 (-20037508.342789199, -20037508.342789199) 到 (20037508.342789199, 20037508.342789199)也就是一个以原点为左上角、宽高约 40075016 米的正方形。X 向右增大Y 向下增大所以瓦片 (0,0) 覆盖左上角那个方块。显示级别是 0 到 17共 18 级。比例尺集合以 1.6901635716026553E-9 开头逐级乘 2到 17 级是 2.2153311965710323E-4。这个 0 级起点是很多其他服务没有的。第 0 级一张瓦片覆盖整个地球视觉上看就是一大块模糊的色块实际业务意义不大。恰恰是这种“从无到有”的完整金字塔结构让谷歌这套参数成为众多开源地图库的默认基准。很多坐标系转换工具内部都以这套参数为基准把其他服务的未知级别换算回去所以它的值是三份里最容易被引用的“锚点”。3.2 搜搜左下角原点、4 到 18 级、Y 向上搜搜地图的参数第一眼会觉得“抄谷歌”因为全图范围的 X 跨度几乎相同投影也一样是 WGS84 Web Mercator。但注意两个硬差异。第一切片原点是 (-20037508.342789244, 20037508.342789091)而且 Y 轴正方向向上所以原点在左下角不在左上角第二显示级别是 4 到 18 级而不是 0 到 17 级。4 到 18 级意味着什么把搜搜的比例尺集合第一项 2.7042617145642484E-8 和谷歌的第 4 级比例尺 2.7042617145642484E-8 对照就会发现完全一致最后一项 4.4306623931420646E-4 也恰好是谷歌第 18 级会出现的值。也就是说搜搜覆盖的是谷歌金字塔的第 4 到 18 层把 0 到 3 这四级粗比例尺砍掉了。这是很多国内在线地图服务的常见选择反正低级别瓦片一眼望去只有国界和海岸线可读性差还浪费存储不如直接从能看清城市的级别开始。搜搜与谷歌的 Y 轴方向不一致这一点决定了它不能和谷歌瓦片直接互换。叠加时若不把 TMS 行号换算回 XYZ 约定地图拼起来会上下颠簸错位。好在这个换算只是一行代码的事后面的避坑章节会给出具体公式。3.3 天地图CGCS2000 下用经纬度范围切分世界天地图是三份里唯一没有走 Web Mercator 路线的。它的切片原点是 (-180, 90)全图范围是从 (-180,-90) 到 (180,90)投影写的是“China Geodetic Coordinate System 2000”也就是 CGCS2000 坐标系。这里的 X 轴正方向向右、Y 轴向下原点位于整个经纬度矩形的左上角。注意全图范围是经纬度值不是米值。这意味着它的瓦片本质上是在经纬度平面上等间隔切割而不是在投影后的米制平面上。天地图的级别从 1 到 18 级比例尺集合从 3.3803271432053105E-9 开始这个值正好等于谷歌第 1 级的比例尺说明它的“第 1 级”对应谷歌金字塔第 1 层也就是全球切成 2×2 张瓦片而不是谷歌第 0 级那种单张瓦片。用经纬度直接切瓦片好处是实现简单、贴合国内地理数据常用的 CGCS2000 框架坏处是靠近两极时经纬度网格与视觉距离严重不成比例。所以天地图和谷歌、搜搜混合使用不能只看范围相同就认为可以互转必须先确认坐标参考系再决定是否要做投影转换。跨服务叠加时的偏移多半来自这里。3.4 三个服务的参数对照表服务投影切片原点原点位置X 方向Y 方向显示级别比例尺集合项数谷歌WGS84 Web Mercator(-20037508.342789199, 20037508.342789199)左上角向右向下0-1718搜搜WGS84 Web Mercator(-20037508.342789244, 20037508.342789091)左下角向右向上4-1815天地图CGCS2000经纬度切割(-180, 90)左上角向右向下1-1818把这张表缩成一句话谷歌是 XYZ 方向、完整金字塔搜搜是 TMS 方向、从第 4 层开始的金字塔天地图是另一个坐标参考系、从第 2×2 层开始的金字塔。三套参数看着相似实际是三种不同的世界划分规则。4. 比例尺集合为什么是 2 的幂瓦片金字塔的换算关系4.1 比例尺小数其实是“比例尺分母的倒数”三份参数表里的比例尺集合初看是一串意义不明的浮点。第一个值 1.6901635716026553E-9最后一个是 2.2153311965710323E-4中间每一项都是前一项的 2 倍。这个规律不是巧合而是瓦片金字塔“逐级二分”的直接体现。要读懂这些小数先还原它们的来历。Web Mercator 第 0 级全球宽度 40075016.68557849 米放在 256 像素的瓦片里每个像素代表约 156543.03 米这是第 0 级的“地面分辨率”。如果屏幕按 96 DPI 计算1 像素长约 0.00026458 米两者相除就得到比例尺分母约 591658711也就是常说的 1:591658711。把这个分母取倒数正好得到 1.6901635716026553E-9。下一级瓦片数量翻倍细分后每个像素代表的地面距离减半比例尺分母也减半倒数自然就变成原来的 2 倍。这些浮点数的本质是每一级别“地图比例尺”的倒数。参数表没有直接把分母写成 591658711 这样的大整数而是存成小数形式是因为很多瓦片服务的元数据格式为了统一起见把“数字越大级别越细”的直观方向做成单调递增的数列。看参数时如果不懂这一层很容易把它们当成毫无意义的随机浮点。4.2 用一段代码验证根据原点与级别算出瓦片范围与其背参数不如把参数变成可复算的公式。下面这段 Python 演示了如何用谷歌和搜搜的原点、方向约定反推出任意级别任意瓦片的经纬度范围。import math R 6378137.0 WORLD 2 * math.pi * R # 约 40075016.68557849 米 def webmercator_tile_bbox(z, x, y, y_downTrue): 按 Web Mercator 切片规则计算某瓦片的米制包围盒。 y_downTrue 表示 XYZ 约定行号向下递增 y_downFalse 表示 TMS 约定行号向上递增。 n 2 ** z # 当前级别全球每边瓦片数 tile_w WORLD / n # 单个瓦片的米制宽度 left -WORLD / 2 x * tile_w right left tile_w # 主轴固定X 方向都由西向东 if y_down: top WORLD / 2 - y * tile_w bottom top - tile_w else: bottom -WORLD / 2 y * tile_w top bottom tile_w return (left, bottom, right, top) # 谷歌 z4, tile (8, 4)Y 向下 print(webmercator_tile_bbox(4, 8, 4, True)) # 搜搜 z4, tile (8, 4)Y 向上 print(webmercator_tile_bbox(4, 8, 4, False))代码里最关键的一点是 Y 方向两个分支。谷歌的top从全球北边开始向下减搜搜的bottom从南边开始向上加。同样的(8, 4)行号在两种约定下对应的地理范围完全不同。实际工作的血泪经验是写工具函数时不要只有一个分支务必把两个方向都做成参数否则切完瓦片再想接别的服务只能重新生成一遍。这段代码还能反过来验证参数表里的比例尺值算出瓦片宽tile_w除以 256 得每像素米数再除以 0.0002645833 得到分母取倒数后和参数表比对即可。所有 2 倍关系都能严丝合缝对上。4.3 级别范围与精度对应你的应用该用哪几级级别范围决定一张瓦片能看清多小的地物。按第 0 级每像素 156543 米算第 4 级每像素约 9784 米第 17 级约 1.19 米第 18 级约 0.60 米。搜搜的 18 级对应谷歌 18 级也就是理论地面分辨率约 0.6 米已经接近普通卫星影像的精度极限。选级别不是越大越好因为每升一级瓦片总数翻 4 倍。金字塔第 17 级的瓦片数量是第 15 级的 16 倍存储和带宽成本陡增。应用中判断某个区域需要几级瓦片正确做法是先算目标区域在当前屏幕宽度下需要多少像素再反推比例尺层级而不是肉眼看着清晰就层层加载。这里最容易出现的坑是业务方要求“能看清街道”于是把最小显示级别设到 18结果一个城市级范围动辄请求数千张瓦片缓存被大面积穿透。比例尺集合里每个数差两倍的本质含义就是告诉你选高一级数据量×4别轻易越级。5. 混用三套瓦片参数典型翻车场景与排查避坑5.1 现象一图层垂直方向整体颠倒最常见也最迷惑的报错是“同一条道路在自己的地图底图上正常叠加上另一个服务的图层后楼层图标跑到河的对岸有时干脆上下镜像。”原因几乎都是 XYZ 与 TMS 行号混用。谷歌 Y 向下、搜搜 Y 向上两边瓦片 y 坐标互差2^z - 1。如果加载器把两个服务的瓦片当成同一套编号规则来请求垂直方向必然整体错位。解决方式是在瓦片 URL 组装处做一次统一换算y_tms 2**z - 1 - y_xyz。更稳妥的做法是让图层加载器支持一个y_origin参数取值为top或bottom在内部归一化成同一种坐标系后再计算 URL这样后续接入任何服务都不需要改业务代码。5.2 现象二低级别区域一片空白请求直接 404又一个高频问题把搜搜地图接入到需要全球浏览的应用里用户在缩放滑块上拖到凌晨级别时地图区域大片空白网络请求返回 404 或空图片。原因是搜搜显示级别只有 4 到 18 级金字塔第 0 到 3 层根本不存在。服务端没有生成这些瓦片请求了也是空。谷歌虽然支持 0 级但搜搜砍掉了这些层这是它约束存储成本的取舍。解决方式有两层。第一是在客户端把最小缩放级别钳制在 4不能让用户滑到 0 到 3第二是在缓存设计上针对搜搜的级别范围做独立配置不要无条件沿用“全级别缓存”的逻辑。排查时先看 HTTP 状态码如果低级别请求返回 404再确认服务文档里的显示级别范围基本立刻能定位。5.3 现象三天地图和谷歌瓦片叠加位置有规律性偏移明明是同一座城市天地图瓦片叠在谷歌底图上位置整体偏向一侧放大后偏移量不是常量而是随级别变化。原因在于坐标参考系不同。谷歌、搜搜都是 Web Mercator 投影瓦片坐标是米制天地图是 CGCS2000 坐标系下的经纬度切割瓦片坐标是度制。两者在概念上就不是同一种网格直接把某一方的瓦片当作另一方的底图错位不可避免。解决方式是明确主从关系要么以 Web Mercator 为统一工作坐标对天地图瓦片做重投影后再叠加要么把业务数据单独按 CGCS2000 生成瓦片关闭跨参考系的直接混合。这一类问题没有简单偏移公式可以修正因为投影畸变是非线性的强行用一个常量平移量去凑级别一变化就露馅。5.4 这类问题的通用排查顺序踩坑踩多了以后我总结出一条固定排查路线。第一步对比双方参数表里的投影字段投影不同直接定位到参考系转换问题不用继续往下查。第二步对比 Y 轴方向发现一个向下一个向上就去检查瓦片行号换算。第三步对比显示级别范围低级别空白就查级别钳制。第四步对比切片原点数值如果相差在 0.001 米以内则忽略如果差到米级说明全图范围都不一致重点查瓦片网格对齐。这套顺序把三份参数表的差异逐项映射到具体症状上。遇到任何新地图服务我都先拿它的参数表跑一遍这四步有问题先验证再改代码而不是靠肉眼判断图层错位量。6. 参数背后是一条完整规则从验证一个新服务的参数开始拿到任何新地图服务的参数文档不要急着把数字抄进配置。先做三件事。第一人工选择一个已知经纬度的地标用手边的工具算出它在目标级别下应属于的瓦片范围然后用浏览器直接请求看一下瓦片影像确认这个范围里能看到地标第二在低级别和高级别各请求一张瓦片检查服务端是否真实返回验证级别范围不是写错而是确实存在第三用同一组坐标分别请求两个服务的瓦片对齐地物检查偏移方向。这三步做完参数表里的每个数字才真正属于你。我一般会把每个服务的原点、方向、级别范围写成一个独立配置对象方向显式写成y_axis枚举禁止使用布尔值暗示。因为布尔值true/false在阅读时完全没有语义而top或bottom一眼就能看出约定。比例尺集合则用生成函数替代手抄列表给出首项和级别数程序自动生成剩下所有项。这样从源头杜绝了复制粘贴浮点数时少一位数的问题。搜搜选择 Y 轴向上、从 4 级起步谷歌坚持左上角原点、从 0 级起步天地图干脆用另一套坐标系这三份参数映射了不同历史阶段的不同取舍浏览器渲染习惯、地理数据存储习惯、国内坐标系标准最终沉淀成三种差异化的世界划分方式。理解这些取舍之后参数表不再是黑匣子而是一张能为你所用的地图协议说明书。从那以后我每次接入新地图服务都会强迫自己先走一遍参数验证流程再写任何加载代码这个习惯让我少加了好几个通宵的班希望帮到你。本文还有配套的精品资源点击获取