简介MapCutter 3.13.0 是一款面向地图开发与 GIS 应用的高清金字塔切图工具原名 MapTiler支持百度、高德、腾讯、天地图、谷歌、必应、MapBox 等地图源可对自定义地图、图片叠加层和瓦片图进行高品质切片适配 Leaflet、MapTalks、OpenLayers、Cesium 等前端框架及自定义模板适用于离线地图部署、遥感影像发布和游戏地图制作等场景。资源包为 RAR 压缩包共 302 个文件约 152.5MB主要包含 72 个 CSV数据与参数文件、59 个 DLL运行依赖库、56 个 PAK资源包、35 个 GFS切图格式规则以及 JSON、XML、HTML、EXE 等辅助文件整体目录结构清晰适合直接部署运行。包内还附带 ITRF、NAD、WKT 等地理坐标系支持文件并提供集成网页调试环境可对生成的页面进行修改与保存方便在离线或内网环境下使用。用户拿到后可完整实现从地图源加载、切图参数设定、图片预处理到多框架网页输出的工作流已有 261 人学习下载。 前一阵做政企项目客户要求电子地图完全跑在内网连底图都不能依赖在线服务。我第一反应就是把在线底图切成本地瓦片这就要用到地图金字塔切图。市面上的切图工具有不少我实际用下来最顺手的还是 MapCutter3.13.0 这个版本从去年一直用到现在百度、高德、腾讯、天地图、谷歌、必应、MapBox 这几个主流数据源都跑过切出来的瓦片在层级、接缝、体积上都比较稳定。这篇文章就把整套流程和踩过的坑一次性说清楚适合做 WebGIS、智慧园区、户外离线地图的开发者参考。1. MapCutter到底解决了什么事离线地图背后的金字塔逻辑1.1 一张地图是怎么被切碎又拼起来的所谓地图金字塔本质上就是把一张无限精细的大地图按照缩放级别一层一层切成固定尺寸的小方块。大多数在线地图都遵循一个约定每张瓦片是 256×256 像素的 PNG 图片级别越低图越概略级别越高细节越丰富。比如在常见的 XYZ 规则下第 0 级全球只有 1 张瓦片下一级变成 2×2 共 4 张再下一级变成 4×4 共 16 张。每放大一级瓦片数量翻 4 倍这就是金字塔名字的由来。浏览器或客户端在显示地图时并不是加载一整张大图而是根据当前视野范围计算出需要哪些行号和列号的瓦片然后分别请求。在线服务为什么快因为它已经把这些瓦片提前切好放在 CDN 上离线应用为什么卡因为它要么没有瓦片要么还在现场实时渲染。MapCutter 这类工具干的事情就是把这个提前切好的过程搬到你自己手里把百度、高德、腾讯、天地图、谷歌、必应、MapBox 等数据源的在线瓦片按金字塔层级批量下载下来存成标准目录结构交给任何支持本地瓦片的地图引擎去加载。我自己最初接触切图是因为一个户外轨迹 App 需要断网也能看底图。当时天真的想法是直接截屏保存结果放大到第二级就糊成一片。后来才明白离线地图的正确做法不是存图片而是存不同分辨率下的标准瓦片集合。MapCutter 的价值就在这里它把繁琐的多源适配、坐标换算、并发下载、目录生成全部封装好你只需要告诉它切哪里、切几级、用什么源就够了。1.2 谁需要它从项目场景倒推需求切图这个需求听着小众实际碰到的场景真的不少。首先是政务、园区、能源这类内网项目数据不能出内网底图必须本地化其次是商场导览、展会系统、景区地图这类对加载速度敏感的应用在线地图首页加载可能要好几秒切好的本地瓦片几乎是秒开再有就是野外测绘、电力巡检这类网络不稳定的场景手机在山上没信号但地图不能跟着一起失灵。还有一类需求很多人没意识到业务图层和底图要对齐。比如你在高德底图上叠加自己的设备点位、热力图、轨迹线如果底图是动态加载的在线图坐标系一旦被源站调整或者混合了多个数据源所有业务数据都要跟着排查。把底图切到本地、固定版本之后坐标系和缩放级别都稳定在一个快照上后续叠加图层就只需要集中处理一套坐标关系。MapCutter 在同一台机器上反复切不同数据源也方便我经常一个项目里切高德做陆地图切卫星源做宏观底图两套瓦片放在不同目录业务层自由切换。这里要提醒一句不管是哪家地图源瓦片数据都受版权和使用条款约束。切图用于个人开发、内网验证、自有系统缓存没问题如果是要对外商用分发务必先确认对应数据源的授权范围。这是从业者必须有的职业习惯别等收到法务函再补课。2. 七大地图源切片规则的大分化坐标系、投影与瓦片编号2.1 坐标系与投影为什么同一个点在不同地图里位置不一样很多人第一次用 MapCutter 切完瓦片把高德下载的瓦片套到自己的地图引擎里发现所有点位都偏了几百米。这不是工具坏了而是地图源之间的坐标系差异。国内常见的数据源大体分三派谷歌、天地图、MapBox 采用 Web 墨卡托投影坐标系接近 WGS-84 的全球标准高德、腾讯的瓦片虽然也按 Web 墨卡托网格切但底图坐标做了国测局加密处理也就是常说的 GCJ-02百度更特殊它在 GCJ-02 基础上又做了一层偏移形成 BD-09瓦片投影的圆点和行列规则也完全自成一派。理解这个差异有什么用直接决定了你用哪个源的瓦片做底图业务图层就必须配哪套坐标参数。比如我在项目里习惯用高德源做路网底图那么点位坐标采集、逆地理编码、路径规划全部走同一家服务这样坐标天然对齐。如果底图用 MapBox、业务数据却用高德 API 返回的坐标就得在接入层做坐标纠偏否则画上去的点会悬在马路对面。MapCutter 的便利在于它把每个源的投影细节都提前适配好了。你在界面里选了哪个源它就按那个源的瓦片规则去请求和落盘输出给你的目录结构统一是L/{z}/{x}/{y}.png这种标准形式。你不用自己去研究百度的原点偏移、天地图的矩阵级别转换工具已经在内部消化掉了。2.2 瓦片编号规则的差异XYZ、TMS、QuadKey 与 WMTS瓦片金字塔除了坐标系的差异还有个常年让人栽跟头的问题瓦片编号规则。最常见的 XYZ 规则里原点在左上角y 轴向下递增谷歌、MapBox、高德基本遵循这个逻辑。TMS 规则则把原点放在左下角y 轴向上递增如果拿 TMS 的请求规则去拼 XYZ 的瓦片地址地图会变成南北方向颠倒错乱。还有一些源更特殊比如必应地图用的是 QuadKey也就是把 x、y 的二进制位交错编码成一段字符串当作瓦片 ID天地图的 WMTS 服务每个级别有自己的矩阵编号行列号从 1 开始和 Google 的 0 起始规则差一位。这些规则在开发时很容易忽略因为浏览器里看着地图是正常的一旦你自己写瓦片请求地址立刻就会遇到花屏错位或者只加载一半的问题。用 MapCutter 切图时它内部已经按每个源的实际规则请求你不需要关心目标源是 TMS 还是 QuadKey。但切完输出后你的地图引擎必须以 XYZ 标准去读取本地瓦片——这是落地时最容易出问题的地方务必在引擎配置里确认不是 TMS。下面这张表我每次给团队讲切图都会贴基本能概括几个主要源的核心差异数据源坐标基准瓦片请求规则典型特征百度BD-09百度自定义级别从 3 起行列号原点在 (0,0) 经纬度处部分行列号为负数高德GCJ-02XYZ 风格瓦片网格按 Web 墨卡托切但坐标加密腾讯GCJ-02XYZ 风格结构与高德类似路网细节略有不同天地图CGCS2000/WGS-84WMTS矩阵级别号与 Google 差 1行列号从 1 起谷歌WGS-84XYZ国内常用全球覆盖完整必应WGS-84QuadKey瓦片 ID 是字符串需单独解析MapBoxWGS-84XYZ需配置 access_token风格排版可定制这张表的深意是数据源之间不是简单换个 URL的关系坐标系、瓦片组织、级别定义全都可能不一样。这也是为什么我不建议自己写脚本慢慢爬——短时间切个小区没问题一旦跨源、跨行政区、跨级别规则差异能把人逼疯。2.3 多源适配的价值同一套工作流覆盖所有项目接上面说自己写爬虫还要面对一个现实问题今天高德改了一次瓦片寻址规则明天必应换一组 CDN 域名后天 MapBox 升级 token 策略。每一次变动自建脚本都要跟去改一轮。MapCutter 这类工具因为持续维护源适配是跟着上游走的你只需要升级工具版本就能继续使用。我在不同项目里的实际分工是政企内网项目优先用天地图或高德数据更贴合国内路网需要全球视角的汇报大屏用 MapBox风格干净且配色可调需要和海外团队对齐坐标时用谷歌源。因为所有这些源都能在同一套 MapCutter 流程里切出来输出格式一致我的地图引擎和发布脚本完全不用改换的只是源这个选项。这就是多源适配带来的长期价值。3. 拿到MapCutter 3.13.0之后从数据源配置到切图落地的完整流程3.1 先算瓦片量切图前的预算不能省拿到工具先别急着选范围开切第一步永远是估算瓦片数量。这决定了你要切多久、占多大磁盘、用什么存储格式。以 Web 墨卡托全球图为例z 级全球瓦片数是 4 的 z 次方z14 时全球有 2.68 亿张z18 直接到 687 亿张——这个数字根本不是普通机器能碰的。我们日常切图都是切某个行政区或者某个项目范围而不是切全球。粗略估算公式把你需要的纬度跨度换算成米除以该级别单张瓦片覆盖的米数得到横向瓦片数经度方向同理。更省事的做法是在 MapCutter 里选好范围后只看它界面提示的预估瓦片数然后按每张瓦片平均 1030KB 估算磁盘。我切过一个约 1°×1° 的城市核心区14 到 18 级一共大约 40 万张瓦片PNG 总容量 12GB 左右。如果你要 19 级容量直接再翻四倍因为在最高级别每多一级就是 4 倍的工作量和存储量。还有一类隐形预算是请求频率。切图本质是向源站发起几十万次图片请求如果并发设置太高源站 CDN 可能直接封 IP。我自己会先在工具里要一个保守的并发数比如 8 到 16 线程并且开启请求间隔宁可多花三十分钟也不要切到一半被封。实测下来大多数源对这种节奏是友好接受的。3.2 界面参数配置从数据源到输出格式MapCutter 3.13.0 的操作界面属于典型的几个下拉框加一个地图预览模式核心流程非常简单。第一步选择数据源比如这里选高德第二步在预览图上框选出你要切的范围也可以直接输入经纬度边界让范围精确到小数点后四位第三步设置缩放级别范围比如从 10 级到 18 级第四步指定输出目录确认线程数和请求间隔后点击开始。存储格式是我特别建议先想清楚的一步。MapCutter 支持输出为标准目录瓦片和单文件数据库两种。目录格式就是L{zoom}/{x}/{y}.png适合放在 Web 静态服务器或者本地文件系统里直接加载调试直观但文件数量一多会占 inodeLinux 服务器上尤其明显。单文件格式则把所有瓦片写进一个 SQLite 容器里分发、拷贝都方便手机上加载也快适合做离线 App 资源包。小范围项目我用目录格式中大范围我都习惯先出单文件再按需拆包。级别范围怎么定我的经验是底图显示到 16 级通常够用于城市级概览18 级适合道路级精细展示20 级几乎只有市政施工和房屋轮廓才用得上。级别越高容错越低因为一张瓦片只有 256×256放得太大整张图都会发虚。不要盲目追求高等级先问业务场景到底需要放大到哪一级。3.3 跑切图和验证离线瓦片不是切完就结束点击开始之后MapCutter 会按当前源和范围逐级下载。这个过程有几个观察点一是看进度日志里有没有大量请求失败超时的条目偶尔一两条重试能过去成片失败就要立刻停二是看输出目录的层级结构是否正确每一级目录下瓦片是否按行列号生成三是抽查几个瓦片文件确认是正常图片而不是源站返回的错误页。全部切完后我会在本地起一个最简单的静态服务器比如 Python 的python -m http.server然后用浏览器加载瓦片地址心算几个边界点的行列号去请求看看瓦片能否被正确读取。进一步可以在 QGIS 里或自己的地图 SDK 中加载这个本地瓦片目录叠加一条已知坐标的轨迹视觉确认位置没有偏差。这一步千万别跳我曾见过有人切完一堆瓦片直接丢上生产结果瓦片坐标 y 轴反了整个地图上下颠倒排查花了大半天。4. 切图过程中的常见坑与质量把控一次真实项目的排查记录4.1 高德瓦片整体偏移一次坐标系混用的完整排查一次项目中我用 MapCutter 切了高德源瓦片部署到自研地图引擎后发现所有建筑、道路都往东南方向偏了好几百米叠加轨迹线也整体错位。当时第一反应是工具切错了差点重新切一遍。后来按链路一步步排查才找到真正问题。排查的第一步是确认源本身没偏浏览器打开高德官方地图对比同一个范围官方完全不偏说明 MapCutter 下载的瓦片内容没问题。第二步检查自研引擎的坐标初始化参数确认中心点和投影设置正确排除了引擎加载错误。第三步我把引擎实际请求的瓦片 URL 和 MapCutter 输出目录里的路径逐一对比最终发现问题出在 y 轴方向引擎默认按 TMS 规则解析瓦片也就是 y 轴从下往上数而高德瓦片是标准的 XYZ 规则y 轴从上往下数。两者混用时每个瓦片的行号都反了地图自然乱套。修复方式很简单在引擎配置里把瓦片规则改成 XYZ或者在接入层把 y 翻转一下。关键是不要一看到偏位就去加什么坐标系纠偏参数那只是把越描越黑。这类问题几乎都是请求规则或者投影设置错了先查方向再查偏移顺序不能乱。得益于这次经验我后来所有项目落地瓦片时第一件事就是确认引擎的瓦片寻址规范和输出目录规范一致。4.2 文件数量爆炸与 inode 耗尽存储方案要提前定另一个高频坑是瓦片文件太多Linux 服务器上 inode 耗尽。切一个城市的 1418 级几十万个小文件是家常便饭如果默认文件系统 inode 上限不高再大点的范围就能把服务器写满。这不是磁盘空间不够而是文件系统的目录项数量用完了表现为磁盘明明还有剩余但创建新文件报 No space left on device。解决思路有两条。一条是尽量切成单文件格式把几十万张瓦片收敛成一个 SQLite 库文件拷贝、备份、分布式分发都轻松。另一条如果你必须用目录格式那么提前评估范围大小并给瓦片目录单独挂一个 inode 充足的磁盘分区。我个人的划分标准是预计超过 10 万张瓦片优先用单文件少于 10 万张目录格式可以接受。瓦片的压缩优化也值得做。底图瓦片大多数是线条、色块为主的地图渲染PNG 体积并不大但数量庞大。切完可以批量做一次压缩或者用工具自带的压缩选项把单张瓦片体积再降一档。别小看这个优化几万张瓦片每张省 5KB总量就能省下几百兆。4.3 并发、限流、断点与完整性校验让切图更稳的几个习惯切图工具虽然能并发下载但源头服务有保护策略尤其是免费数据源并发过高会直接返回 403 或者弹出验证码。正确做法是设置一个峰值得住的并发数而不是理论上最快的并发数。我习惯是 8 到 16 线程加少量延时切一个几十万张的范围预计时间会比极限并发慢 20%但稳定性成倍上升值这个差价。中断续传是另一个必须用上的能力。我切大范围时经常遇到下班前开始切第二天发现中途断网或者电脑休眠如果在工具里开了跳过已存在瓦片重跑一遍就能接着断点继续而不是从头再来。这个判断逻辑是会检查目标目录是否已有对应瓦片所以切图过程中不要手动去删除或改动输出目录。切完之后的完整性校验我通常做三件事一是看日志里是否有重试多次仍失败的记录二是把输出目录里的瓦片总数和预估数对比偏差太大说明有缺失三是随机抽几个层级和区域视觉上看看有没有糊图、错图。MapCutter 3.13.0 的日志文件会记录每个请求的最终状态保留它就等于保留了完整的切图审计记录。这招在排查瓦片少了四分之一这种神秘问题时非常管用。4.4 多源混用时的坐标统一与视觉协调项目做大了之后很多团队会同时使用两三个数据源高德路网、天地图影像、MapBox 行政边界。这时最需要注意的是各个源瓦片之间的坐标系差异。高德源切出来的是 GCJ-02 坐标体系的底图天地图影像源接近 WGS-84把两个源的瓦片放在同一个地图视图里叠加除非引擎做了坐标转换否则不可避免会错位。我的做法是一个项目里只保留一个主底图源所有业务数据都按主底图的坐标体系来采集和存储其他源的瓦片只做不叠加的对比查看或者预先把坐标体系统一好再进场。有些项目需要影像和路网叠加那就尽量选择同一家源的影像和路网避免跨厂商混拼。切图工具虽然能解决下载问题但坐标统一是项目架构层面的决定不是工具层能兜底的。另外视觉协调上不同源的地图配色风格差异很大高德偏清新、MapBox 偏扁平化、天地图偏正经。同一块屏幕里如果同时展示两种风格的底图用户会明显感觉不统一。多源的价值在于按项目场景选择最匹配的那个而不是把各种源强行揉在一个视图里。再分享一个我自己的习惯任何项目正式切图前先框一个小范围切 10 到 14 级用目标引擎实际加载确认无误再放大到完整范围和完整级别。这样多花十分钟能免去成千上万张瓦片切错后返工的成本。地图切图这个活前期多确认一次规则后期就省一整轮时间。本文还有配套的精品资源点击获取 离线地图切图实战：用MapCutter构建本地瓦片金字塔的完整指南
简介MapCutter 3.13.0 是一款面向地图开发与 GIS 应用的高清金字塔切图工具原名 MapTiler支持百度、高德、腾讯、天地图、谷歌、必应、MapBox 等地图源可对自定义地图、图片叠加层和瓦片图进行高品质切片适配 Leaflet、MapTalks、OpenLayers、Cesium 等前端框架及自定义模板适用于离线地图部署、遥感影像发布和游戏地图制作等场景。资源包为 RAR 压缩包共 302 个文件约 152.5MB主要包含 72 个 CSV数据与参数文件、59 个 DLL运行依赖库、56 个 PAK资源包、35 个 GFS切图格式规则以及 JSON、XML、HTML、EXE 等辅助文件整体目录结构清晰适合直接部署运行。包内还附带 ITRF、NAD、WKT 等地理坐标系支持文件并提供集成网页调试环境可对生成的页面进行修改与保存方便在离线或内网环境下使用。用户拿到后可完整实现从地图源加载、切图参数设定、图片预处理到多框架网页输出的工作流已有 261 人学习下载。 前一阵做政企项目客户要求电子地图完全跑在内网连底图都不能依赖在线服务。我第一反应就是把在线底图切成本地瓦片这就要用到地图金字塔切图。市面上的切图工具有不少我实际用下来最顺手的还是 MapCutter3.13.0 这个版本从去年一直用到现在百度、高德、腾讯、天地图、谷歌、必应、MapBox 这几个主流数据源都跑过切出来的瓦片在层级、接缝、体积上都比较稳定。这篇文章就把整套流程和踩过的坑一次性说清楚适合做 WebGIS、智慧园区、户外离线地图的开发者参考。1. MapCutter到底解决了什么事离线地图背后的金字塔逻辑1.1 一张地图是怎么被切碎又拼起来的所谓地图金字塔本质上就是把一张无限精细的大地图按照缩放级别一层一层切成固定尺寸的小方块。大多数在线地图都遵循一个约定每张瓦片是 256×256 像素的 PNG 图片级别越低图越概略级别越高细节越丰富。比如在常见的 XYZ 规则下第 0 级全球只有 1 张瓦片下一级变成 2×2 共 4 张再下一级变成 4×4 共 16 张。每放大一级瓦片数量翻 4 倍这就是金字塔名字的由来。浏览器或客户端在显示地图时并不是加载一整张大图而是根据当前视野范围计算出需要哪些行号和列号的瓦片然后分别请求。在线服务为什么快因为它已经把这些瓦片提前切好放在 CDN 上离线应用为什么卡因为它要么没有瓦片要么还在现场实时渲染。MapCutter 这类工具干的事情就是把这个提前切好的过程搬到你自己手里把百度、高德、腾讯、天地图、谷歌、必应、MapBox 等数据源的在线瓦片按金字塔层级批量下载下来存成标准目录结构交给任何支持本地瓦片的地图引擎去加载。我自己最初接触切图是因为一个户外轨迹 App 需要断网也能看底图。当时天真的想法是直接截屏保存结果放大到第二级就糊成一片。后来才明白离线地图的正确做法不是存图片而是存不同分辨率下的标准瓦片集合。MapCutter 的价值就在这里它把繁琐的多源适配、坐标换算、并发下载、目录生成全部封装好你只需要告诉它切哪里、切几级、用什么源就够了。1.2 谁需要它从项目场景倒推需求切图这个需求听着小众实际碰到的场景真的不少。首先是政务、园区、能源这类内网项目数据不能出内网底图必须本地化其次是商场导览、展会系统、景区地图这类对加载速度敏感的应用在线地图首页加载可能要好几秒切好的本地瓦片几乎是秒开再有就是野外测绘、电力巡检这类网络不稳定的场景手机在山上没信号但地图不能跟着一起失灵。还有一类需求很多人没意识到业务图层和底图要对齐。比如你在高德底图上叠加自己的设备点位、热力图、轨迹线如果底图是动态加载的在线图坐标系一旦被源站调整或者混合了多个数据源所有业务数据都要跟着排查。把底图切到本地、固定版本之后坐标系和缩放级别都稳定在一个快照上后续叠加图层就只需要集中处理一套坐标关系。MapCutter 在同一台机器上反复切不同数据源也方便我经常一个项目里切高德做陆地图切卫星源做宏观底图两套瓦片放在不同目录业务层自由切换。这里要提醒一句不管是哪家地图源瓦片数据都受版权和使用条款约束。切图用于个人开发、内网验证、自有系统缓存没问题如果是要对外商用分发务必先确认对应数据源的授权范围。这是从业者必须有的职业习惯别等收到法务函再补课。2. 七大地图源切片规则的大分化坐标系、投影与瓦片编号2.1 坐标系与投影为什么同一个点在不同地图里位置不一样很多人第一次用 MapCutter 切完瓦片把高德下载的瓦片套到自己的地图引擎里发现所有点位都偏了几百米。这不是工具坏了而是地图源之间的坐标系差异。国内常见的数据源大体分三派谷歌、天地图、MapBox 采用 Web 墨卡托投影坐标系接近 WGS-84 的全球标准高德、腾讯的瓦片虽然也按 Web 墨卡托网格切但底图坐标做了国测局加密处理也就是常说的 GCJ-02百度更特殊它在 GCJ-02 基础上又做了一层偏移形成 BD-09瓦片投影的圆点和行列规则也完全自成一派。理解这个差异有什么用直接决定了你用哪个源的瓦片做底图业务图层就必须配哪套坐标参数。比如我在项目里习惯用高德源做路网底图那么点位坐标采集、逆地理编码、路径规划全部走同一家服务这样坐标天然对齐。如果底图用 MapBox、业务数据却用高德 API 返回的坐标就得在接入层做坐标纠偏否则画上去的点会悬在马路对面。MapCutter 的便利在于它把每个源的投影细节都提前适配好了。你在界面里选了哪个源它就按那个源的瓦片规则去请求和落盘输出给你的目录结构统一是L/{z}/{x}/{y}.png这种标准形式。你不用自己去研究百度的原点偏移、天地图的矩阵级别转换工具已经在内部消化掉了。2.2 瓦片编号规则的差异XYZ、TMS、QuadKey 与 WMTS瓦片金字塔除了坐标系的差异还有个常年让人栽跟头的问题瓦片编号规则。最常见的 XYZ 规则里原点在左上角y 轴向下递增谷歌、MapBox、高德基本遵循这个逻辑。TMS 规则则把原点放在左下角y 轴向上递增如果拿 TMS 的请求规则去拼 XYZ 的瓦片地址地图会变成南北方向颠倒错乱。还有一些源更特殊比如必应地图用的是 QuadKey也就是把 x、y 的二进制位交错编码成一段字符串当作瓦片 ID天地图的 WMTS 服务每个级别有自己的矩阵编号行列号从 1 开始和 Google 的 0 起始规则差一位。这些规则在开发时很容易忽略因为浏览器里看着地图是正常的一旦你自己写瓦片请求地址立刻就会遇到花屏错位或者只加载一半的问题。用 MapCutter 切图时它内部已经按每个源的实际规则请求你不需要关心目标源是 TMS 还是 QuadKey。但切完输出后你的地图引擎必须以 XYZ 标准去读取本地瓦片——这是落地时最容易出问题的地方务必在引擎配置里确认不是 TMS。下面这张表我每次给团队讲切图都会贴基本能概括几个主要源的核心差异数据源坐标基准瓦片请求规则典型特征百度BD-09百度自定义级别从 3 起行列号原点在 (0,0) 经纬度处部分行列号为负数高德GCJ-02XYZ 风格瓦片网格按 Web 墨卡托切但坐标加密腾讯GCJ-02XYZ 风格结构与高德类似路网细节略有不同天地图CGCS2000/WGS-84WMTS矩阵级别号与 Google 差 1行列号从 1 起谷歌WGS-84XYZ国内常用全球覆盖完整必应WGS-84QuadKey瓦片 ID 是字符串需单独解析MapBoxWGS-84XYZ需配置 access_token风格排版可定制这张表的深意是数据源之间不是简单换个 URL的关系坐标系、瓦片组织、级别定义全都可能不一样。这也是为什么我不建议自己写脚本慢慢爬——短时间切个小区没问题一旦跨源、跨行政区、跨级别规则差异能把人逼疯。2.3 多源适配的价值同一套工作流覆盖所有项目接上面说自己写爬虫还要面对一个现实问题今天高德改了一次瓦片寻址规则明天必应换一组 CDN 域名后天 MapBox 升级 token 策略。每一次变动自建脚本都要跟去改一轮。MapCutter 这类工具因为持续维护源适配是跟着上游走的你只需要升级工具版本就能继续使用。我在不同项目里的实际分工是政企内网项目优先用天地图或高德数据更贴合国内路网需要全球视角的汇报大屏用 MapBox风格干净且配色可调需要和海外团队对齐坐标时用谷歌源。因为所有这些源都能在同一套 MapCutter 流程里切出来输出格式一致我的地图引擎和发布脚本完全不用改换的只是源这个选项。这就是多源适配带来的长期价值。3. 拿到MapCutter 3.13.0之后从数据源配置到切图落地的完整流程3.1 先算瓦片量切图前的预算不能省拿到工具先别急着选范围开切第一步永远是估算瓦片数量。这决定了你要切多久、占多大磁盘、用什么存储格式。以 Web 墨卡托全球图为例z 级全球瓦片数是 4 的 z 次方z14 时全球有 2.68 亿张z18 直接到 687 亿张——这个数字根本不是普通机器能碰的。我们日常切图都是切某个行政区或者某个项目范围而不是切全球。粗略估算公式把你需要的纬度跨度换算成米除以该级别单张瓦片覆盖的米数得到横向瓦片数经度方向同理。更省事的做法是在 MapCutter 里选好范围后只看它界面提示的预估瓦片数然后按每张瓦片平均 1030KB 估算磁盘。我切过一个约 1°×1° 的城市核心区14 到 18 级一共大约 40 万张瓦片PNG 总容量 12GB 左右。如果你要 19 级容量直接再翻四倍因为在最高级别每多一级就是 4 倍的工作量和存储量。还有一类隐形预算是请求频率。切图本质是向源站发起几十万次图片请求如果并发设置太高源站 CDN 可能直接封 IP。我自己会先在工具里要一个保守的并发数比如 8 到 16 线程并且开启请求间隔宁可多花三十分钟也不要切到一半被封。实测下来大多数源对这种节奏是友好接受的。3.2 界面参数配置从数据源到输出格式MapCutter 3.13.0 的操作界面属于典型的几个下拉框加一个地图预览模式核心流程非常简单。第一步选择数据源比如这里选高德第二步在预览图上框选出你要切的范围也可以直接输入经纬度边界让范围精确到小数点后四位第三步设置缩放级别范围比如从 10 级到 18 级第四步指定输出目录确认线程数和请求间隔后点击开始。存储格式是我特别建议先想清楚的一步。MapCutter 支持输出为标准目录瓦片和单文件数据库两种。目录格式就是L{zoom}/{x}/{y}.png适合放在 Web 静态服务器或者本地文件系统里直接加载调试直观但文件数量一多会占 inodeLinux 服务器上尤其明显。单文件格式则把所有瓦片写进一个 SQLite 容器里分发、拷贝都方便手机上加载也快适合做离线 App 资源包。小范围项目我用目录格式中大范围我都习惯先出单文件再按需拆包。级别范围怎么定我的经验是底图显示到 16 级通常够用于城市级概览18 级适合道路级精细展示20 级几乎只有市政施工和房屋轮廓才用得上。级别越高容错越低因为一张瓦片只有 256×256放得太大整张图都会发虚。不要盲目追求高等级先问业务场景到底需要放大到哪一级。3.3 跑切图和验证离线瓦片不是切完就结束点击开始之后MapCutter 会按当前源和范围逐级下载。这个过程有几个观察点一是看进度日志里有没有大量请求失败超时的条目偶尔一两条重试能过去成片失败就要立刻停二是看输出目录的层级结构是否正确每一级目录下瓦片是否按行列号生成三是抽查几个瓦片文件确认是正常图片而不是源站返回的错误页。全部切完后我会在本地起一个最简单的静态服务器比如 Python 的python -m http.server然后用浏览器加载瓦片地址心算几个边界点的行列号去请求看看瓦片能否被正确读取。进一步可以在 QGIS 里或自己的地图 SDK 中加载这个本地瓦片目录叠加一条已知坐标的轨迹视觉确认位置没有偏差。这一步千万别跳我曾见过有人切完一堆瓦片直接丢上生产结果瓦片坐标 y 轴反了整个地图上下颠倒排查花了大半天。4. 切图过程中的常见坑与质量把控一次真实项目的排查记录4.1 高德瓦片整体偏移一次坐标系混用的完整排查一次项目中我用 MapCutter 切了高德源瓦片部署到自研地图引擎后发现所有建筑、道路都往东南方向偏了好几百米叠加轨迹线也整体错位。当时第一反应是工具切错了差点重新切一遍。后来按链路一步步排查才找到真正问题。排查的第一步是确认源本身没偏浏览器打开高德官方地图对比同一个范围官方完全不偏说明 MapCutter 下载的瓦片内容没问题。第二步检查自研引擎的坐标初始化参数确认中心点和投影设置正确排除了引擎加载错误。第三步我把引擎实际请求的瓦片 URL 和 MapCutter 输出目录里的路径逐一对比最终发现问题出在 y 轴方向引擎默认按 TMS 规则解析瓦片也就是 y 轴从下往上数而高德瓦片是标准的 XYZ 规则y 轴从上往下数。两者混用时每个瓦片的行号都反了地图自然乱套。修复方式很简单在引擎配置里把瓦片规则改成 XYZ或者在接入层把 y 翻转一下。关键是不要一看到偏位就去加什么坐标系纠偏参数那只是把越描越黑。这类问题几乎都是请求规则或者投影设置错了先查方向再查偏移顺序不能乱。得益于这次经验我后来所有项目落地瓦片时第一件事就是确认引擎的瓦片寻址规范和输出目录规范一致。4.2 文件数量爆炸与 inode 耗尽存储方案要提前定另一个高频坑是瓦片文件太多Linux 服务器上 inode 耗尽。切一个城市的 1418 级几十万个小文件是家常便饭如果默认文件系统 inode 上限不高再大点的范围就能把服务器写满。这不是磁盘空间不够而是文件系统的目录项数量用完了表现为磁盘明明还有剩余但创建新文件报 No space left on device。解决思路有两条。一条是尽量切成单文件格式把几十万张瓦片收敛成一个 SQLite 库文件拷贝、备份、分布式分发都轻松。另一条如果你必须用目录格式那么提前评估范围大小并给瓦片目录单独挂一个 inode 充足的磁盘分区。我个人的划分标准是预计超过 10 万张瓦片优先用单文件少于 10 万张目录格式可以接受。瓦片的压缩优化也值得做。底图瓦片大多数是线条、色块为主的地图渲染PNG 体积并不大但数量庞大。切完可以批量做一次压缩或者用工具自带的压缩选项把单张瓦片体积再降一档。别小看这个优化几万张瓦片每张省 5KB总量就能省下几百兆。4.3 并发、限流、断点与完整性校验让切图更稳的几个习惯切图工具虽然能并发下载但源头服务有保护策略尤其是免费数据源并发过高会直接返回 403 或者弹出验证码。正确做法是设置一个峰值得住的并发数而不是理论上最快的并发数。我习惯是 8 到 16 线程加少量延时切一个几十万张的范围预计时间会比极限并发慢 20%但稳定性成倍上升值这个差价。中断续传是另一个必须用上的能力。我切大范围时经常遇到下班前开始切第二天发现中途断网或者电脑休眠如果在工具里开了跳过已存在瓦片重跑一遍就能接着断点继续而不是从头再来。这个判断逻辑是会检查目标目录是否已有对应瓦片所以切图过程中不要手动去删除或改动输出目录。切完之后的完整性校验我通常做三件事一是看日志里是否有重试多次仍失败的记录二是把输出目录里的瓦片总数和预估数对比偏差太大说明有缺失三是随机抽几个层级和区域视觉上看看有没有糊图、错图。MapCutter 3.13.0 的日志文件会记录每个请求的最终状态保留它就等于保留了完整的切图审计记录。这招在排查瓦片少了四分之一这种神秘问题时非常管用。4.4 多源混用时的坐标统一与视觉协调项目做大了之后很多团队会同时使用两三个数据源高德路网、天地图影像、MapBox 行政边界。这时最需要注意的是各个源瓦片之间的坐标系差异。高德源切出来的是 GCJ-02 坐标体系的底图天地图影像源接近 WGS-84把两个源的瓦片放在同一个地图视图里叠加除非引擎做了坐标转换否则不可避免会错位。我的做法是一个项目里只保留一个主底图源所有业务数据都按主底图的坐标体系来采集和存储其他源的瓦片只做不叠加的对比查看或者预先把坐标体系统一好再进场。有些项目需要影像和路网叠加那就尽量选择同一家源的影像和路网避免跨厂商混拼。切图工具虽然能解决下载问题但坐标统一是项目架构层面的决定不是工具层能兜底的。另外视觉协调上不同源的地图配色风格差异很大高德偏清新、MapBox 偏扁平化、天地图偏正经。同一块屏幕里如果同时展示两种风格的底图用户会明显感觉不统一。多源的价值在于按项目场景选择最匹配的那个而不是把各种源强行揉在一个视图里。再分享一个我自己的习惯任何项目正式切图前先框一个小范围切 10 到 14 级用目标引擎实际加载确认无误再放大到完整范围和完整级别。这样多花十分钟能免去成千上万张瓦片切错后返工的成本。地图切图这个活前期多确认一次规则后期就省一整轮时间。本文还有配套的精品资源点击获取