简介面向 GIS 从业者、测绘与规划设计人员的一款轻量地图输出工具。它基于 QGIS 工程封装可将配置好的地图一键导出为图片或 PDF省去学习专业地图打印软件的环节适合日常出样、投标展示、客户汇报等场景。压缩包共 321 个文件大小约 69.79MB内部以大量 dll 动态库支撑运行同时包含 gfs、svg、png、csv、xml 等多类资源分别承担样式描述、矢量符号、位图素材、属性数据与工程配置等职能结构完整紧凑。已有 365 人学习下载。使用这套工具后能直接获得保留 QGIS 图层样式与符号效果的高清晰度地图文件既满足打印输出精度要求也便于电子版汇报和交互演示对流动作图、需要频繁产出交付物的团队或个人来说是一套开箱即用的插件化方案。1. 地图导出工具把在线地图变成离线图片和PDF没那么玄学做测绘、规划或者外业踏勘的人基本都遇到过同一个尴尬在网页上缩放好地图、截个长图交给同事结果打印出来糊成一团比例尺也是错的。地图导出图片/PDF工具解决的就是这个问题——把在线地图按指定范围、指定级别、指定画幅拼合成一张无损大图或PDF而不是屏幕截图。它适合三类人需要给报告配高分辨率底图的工程师、要做外业图纸的规划人员、以及想把在线瓦片数据沉淀成内部素材的开发人员。核心能力就三件事按经纬度范围裁剪、按级别换算金字塔瓦片、按DPI拼版输出PDF。下面我把整个原理、参数、踩坑一次讲透。2. 瓦片拼图原理与地图源选型先搞清楚它在背后做了什么2.1 金字塔瓦片模型理解级别、行列号与投影的三角关系在线地图的底图从来不是一张大图而是按金字塔模型切成无数个 256×256 像素的小方块。层级Z越低一张瓦片覆盖的地理范围越大层级越高单张瓦片覆盖的范围越小但细节越丰富。经典 Web 墨卡托投影下全球范围在第 0 级是 1 张瓦片第 1 级是 4 张第 N 级是 2^N × 2^N 张。导出工具背后做的事就是根据你给的矩形范围左上角和右下角的经纬度反算出某一层级下需要下载哪些行列号的瓦片然后按位置拼成一张大图。这个过程的数学核心是两个公式经纬度转 Web 墨卡托平面坐标再通过分辨率换算到瓦片行列号。以最常见的 XYZ 瓦片编码为例计算某经纬度所在瓦片行列号的 Python 代码长这样import math def lonlat_to_tile_xy(lon, lat, zoom): # 先转墨卡托投影坐标再换算瓦片行列号 lat_rad math.radians(lat) n 2 ** zoom x_tile (lon 180.0) / 360.0 * n y_tile (1.0 - math.asinh(math.tan(lat_rad)) / math.pi) / 2.0 * n return int(x_tile), int(y_tile)这里的math.asinh(math.tan(lat_rad))是 Web 墨卡托投影的逆运算用于把纬度的球面坐标映射到平面。注意这套公式只在 Web 墨卡托EPSG:3857下成立如果你接的是 GCJ-02 偏移坐标或地方坐标系行列号会整体偏移拼出来的图会出现一条明显的错缝。2.2 地图源选型在线瓦片、离线栅格还是自建瓦片服务地图导出工具支持什么地图源决定了你能用在什么场景。我拆过的这类工具通常支持三种数据源。第一种是标准 XYZ 在线瓦片比如常见的 OpenStreetMap、影像图、路网图这类瓦片服务稳定、免费但有一定访问频率限制适合中小范围导出。第二种是已下载到本地的 MBTiles 或文件夹形式的瓦片缓存适合内网环境或重复导出速度和稳定性最好。第三种是自建瓦片服务一般是 GeoServer 发布的地图服务URL 规则与 XYZ 不完全一致通常需要单独适配。选型时我的建议很简单一次性临时导出用在线瓦片如果同一个区域要反复导出、或者范围很大先把瓦片拉取到本地缓存再拼图能避免很多网络超时和瓦片缺失的问题。某次导出一个城区 20 平方公里影像图第一次直接在线拼做到一半连接中断重新跑一遍浪费时间后来改成先下载瓦片到本地再拼接虽然多了磁盘占用但成功率接近 100%。2.3 输出格式的本质区别栅格图片与PDF里到底装的是什么很多第一次用的人会把「导出 PDF」理解成类似 Word 导出的矢量文档这是最大的认知偏差。地图导出工具生成的 PDF本质上是一个带地理配准信息的栅格图像外壳——里面装的还是拼接好的位图只是用一个容器包起来便于打印和分发。明白这一点你就能理解两个关键现象导出 PDF 的文件大小与同分辨率图片差不多不会因为「矢量」而变小PDF 内的地图放大到超过导出级别时同样会糊因为它根本没有隐藏的高分辨率数据。选择图片还是 PDF取决于交付需求图片适合插入报告、做进一步图像处理PDF 适合直接打印、归档和跨平台预览。部分工具支持在 PDF 中嵌入矢量标注层这类矢量信息确实可以无损缩放但底图本身仍然是栅格。3. 核心导出流程拆解从经纬度范围到最后成图3.1 范围换算与级别计算先算出你要下载多少张瓦片导出第一步是把需求量化给定的经纬度范围在当前级别下横跨多少行、多少列瓦片总数量是不是在可接受范围内。这一步做得仔细后面拼图基本不会翻车。def calc_tile_range(bounds, zoom): west, south, east, north bounds x_min, y_max lonlat_to_tile_xy(west, north, zoom) x_max, y_min lonlat_to_tile_xy(east, south, zoom) count (x_max - x_min 1) * (y_max - y_min 1) return (x_min, y_min, x_max, y_max), count这里y_min和y_max是反的因为瓦片坐标系 Y 轴向下——北纬对应小的行号南纬对应大的行号。第一次写这个逻辑的人很容易把上下颠倒拼出来的图上下翻转或者位置完全错乱。算完瓦片数量后根据方块数量估计体积。一张 256×256 的 PNG/JPEG 瓦片约 20-50KB1000 张瓦片对应约 20-50MB 原始下载量拼成的图按 RGB 三通道计算约 256×256×3×1000 ≈ 196MB 内存占用。如果估算后瓦片数超过 2 万张我一般就会提醒自己要么降低级别要么换更高效的数据源要么分批导出再后期拼接。3.2 并发下载瓦片控制线程数与重试机制下载瓦片是导出过程中最耗时、最容易出问题的环节。按顺序逐张下载 5000 张瓦片按每张 100ms 计算需要 8 分钟以上用并发下载可以压缩到 1-2 分钟。但并发数不是越大越好我把常见的异步下载方案整理成一个模板import asyncio import aiohttp async def download_tile(session, url, path, retries3): for attempt in range(retries): try: async with session.get(url, timeout10) as resp: if resp.status 200: data await resp.read() with open(path, wb) as f: f.write(data) return True except (aiohttp.ClientError, asyncio.TimeoutError): if attempt retries - 1: raise await asyncio.sleep(1 * (attempt 1)) return False async def bulk_download(tile_urls, semaphore_limit8): sem asyncio.Semaphore(semaphore_limit) async with aiohttp.ClientSession() as session: async def guarded(url, path): async with sem: return await download_tile(session, url, path) await asyncio.gather(*[guarded(u, p) for u, p in tile_urls])这里的semaphore_limit是并发上限我常用 5-8。原因很简单瓦片服务器通常有访问频率限制并发太高会触发 429 状态码retries3配合退避等待能在网络抖动时自动补下。别相信任何地图服务商的“稳定连接”现实中瓦片下载失败最常见的不是程序逻辑错误而是服务端限流、DNS 解析超时、连接被重置。3.3 拼接成图与边缘裁切处理范围和画布尺寸的毫米级对齐瓦片全部到位后按各自行列号填入一个大画布。这里有个许多人忽略的细节用户给的导出范围通常不是瓦片网格的整数边界所以最终成图需要在填充完所有完整瓦片后对边缘做一次像素级裁切否则图上会多出边框或出现空白。from PIL import Image def stitch_tiles(tile_dir, x_min, y_min, x_max, y_max, out_path, crop_bounds_px): # 先拼完整画布 full_w (x_max - x_min 1) * 256 full_h (y_max - y_min 1) * 256 canvas Image.new(RGB, (full_w, full_h)) for x in range(x_min, x_max 1): for y in range(y_min, y_max 1): tile_path f{tile_dir}/{x}_{y}.png tile Image.open(tile_path) canvas.paste(tile, ((x - x_min) * 256, (y - y_min) * 256)) # 边缘裁切crop_bounds_px 是原始范围在画布中的像素矩形 canvas.crop(crop_bounds_px).save(out_path)crop_bounds_px的计算方式左上角经纬度对应的像素坐标 (左上角在瓦片内的偏移 x左上角在瓦片内的偏移 y)右下角同理。这个偏移量可以通过经纬度转像素坐标获得注意 Web 墨卡托的像素坐标原点是左上角X 轴向右Y 轴向下。3.4 PDF输出与地理配准不只是把图片塞进去最后一步是生成 PDF。简单实现是直接把大图嵌入 PDF 页面但这会让打印时按纸张缩放难控——你导出的图是 8000×6000 像素打印到 A4 上到底对应多大比例尺正规的做法是同时写入地理配准信息让 PDF 内嵌的地理范围能被识图工具读取。从工程角度我建议在输出 PDF 的同时额外生成一个世界文件TFW 或 PGW记录像素对应的地理坐标和分辨率。这样这张图未来在任何 GIS 软件中打开都能直接叠回到正确位置而不只是一张“好看但没坐标”的图片。有的工具把这套东西做在导出菜单里有的需要手动保存拿到工具后先确认这一点。4. 参数配置与输出质量控制导出的图能不能用看这几个参数4.1 缩放级别Zvs DPI清晰度问题的本质换算初次使用的人最容易问为什么导出的图放大后是模糊的答案不在工具而在「缩放级别 DPI」这对组合。地图导出工具输出的所有栅格图其真实信息量取决于你选择的瓦片级别 Z而不是导出的图片尺寸。在固定范围内Z 每加 1瓦片数量翻 4 倍图片像素翻 4 倍清晰度翻一倍。正确做法是先确定交付物需要的打印比例尺或地面分辨率再反推级别。估算公式是地面分辨率 156543.03392 × cos(纬度) / 2^Z单位为米/像素。选好 Z 后再设置 DPI常见做法是打印图用 300 DPI显示屏用 150 DPI换算成最终画布尺寸 宽度像素 / DPI × 2.54 厘米。这个公式能帮你一眼看出8000 像素宽、300 DPI 的图实际物理宽度约 67.7 厘米。4.2 坐标偏移与坐标系选择GCJ-02、WGS-84 与地方坐标系这个坑我踩过不止一次。国内大多数在线地图服务用的是 GCJ-02 加密坐标相比 WGS-84 有约 300-700 米的偏移国外地图源和 GPS 设备采集的原始数据是 WGS-84。如果你的范围是拿 GPS 设备去现场测的直接输入到工具里拼出来的图会和真实位置差几百米。处理方式有三种。情况一工具设置了坐标系自动识别优先确认它识别到的是 WGS-84 还是 GCJ-02。情况二手动转换把 GCJ-02 转 WGS-84 的算法公开可用我一般把转换函数单独抽出来避免在导出流程里反复写。情况三如果做的是野外参照图不是精确测量图直接在工具里把地图源切换为对应坐标系的地图源省去转换步骤。4.3 批量导出与命名规则管理多个范围或多级比例尺的输出导出工具真正体现效率的地方在批量处理。比如要把某个区域按 1:1000、1:2000、1:5000 三种比例尺各导出一份手动作三次固然可行但后续别人拿到文件根本分不清哪张对应哪个比例尺。建议在导出前就把命名规则定好按「区域名_级别_比例尺_日期」编排例如demo_area_z18_1k_20250120.pdf。批量导出时还可能遇到单张图过大导致内存溢出的问题。此时按列切开下载拼接、最后整体合并是常见解法但会牺牲一定效率。另一个保守做法是减小瓦片级别或使用 JPEG 而非 PNG 作为瓦片缓存格式JPEG 文件体积约为 PNG 的三分之一内存占用同样下降代价是可能引入压缩噪声。4.4 输出文件的验证方法图拼好了怎么确认没出错拼图完成后直接交图是不负责的。我会做三道验证第一打开成图看一眼边缘是不是平直、有没有白边或错位这能筛掉大部分瓦片缺失和行列号算错的问题第二把输出文件放到 GIS 软件里叠加一个已知坐标图层看是否对齐分布第三检查文件大小是否与预期吻合——偏差超过 30% 往往意味着瓦片下载不完整或拼接时丢了行。地图导出工具如果有日志把下载成功数与总瓦片数对比一下是最快捷的校验方式。5. 避坑指南瓦片错位、空白黑块、内存溢出等高频故障排查5.1 导出图片出现整齐的黑块或灰块现象成图中每隔一段距离出现规整的深色方块形状与瓦片大小完全一致。原因部分瓦片下载失败但重试机制未触发或地图源对高频请求返回了透明底图。最常见的是单张瓦片请求 404 或 403 后程序把空内容直接写入了文件。解决检查下载日志里是否有文件名缺失的瓦片把重试机制从「请求失败重试」改为「文件不存在或文件大小小于 1KB 时重试」因为很多地图源在限流时返回的 HTTP 状态码是 200但内容是一个极小的占位图。写成代码就是# 下载后校验而非只看状态码 if len(data) 1024: # 疑似限流占位图 raise ValueError(ftile too small: {url}, size{len(data)})5.2 拼接后的图整体向左上方或右下角偏移现象所有地物都偏移固定距离不是细微误差而是肉眼可辨的几十上百米。原因范围坐标用了 GCJ-02地图源瓦片是 WGS-84或反过来。如果是这种偏移切图没错错的是坐标系没有对齐。定位方法是取图上一个已知地标对照地图服务的坐标看差值大小差值约 300-500 米基本可判定为火星坐标与 WGS-84 的差异。解决做一次坐标转换后再计算瓦片范围不要直接拿原始 GPS 坐标去算行列号。转换代码较短但注意 GCJ-02 转 WGS-84 存在迭代逼近问题极少数边缘点可能误差偏大验证时多取几个控制点。5.3 大范围导出时内存占用迅速飙升直至崩溃现象导出范围几十平方公里、级别较高时程序中途卡死或系统提示内存不足。原因瓦片数量多导致拼接画布巨大例如 10000×10000 像素的 RGB 图占内存约 300MB这还没算 Pillow 内部转换产生的额外拷贝。如果中途还要做裁剪、旋转峰值内存可能是图本身的三到四倍。解决分块拼接。先把瓦片按行切成多个条带分别保存为临时文件最后再统一合并或者直接降低级别。我通常在工具里把内存上限与瓦片数量做一个硬关联超过阈值就自动切换到分块模式。5.4 导出的 PDF 打印尺寸与预期不符现象PDF 打开正常放到 CAD 或打印预览里尺寸不对比如明明想打 A3结果显示成一张巨大的画布。原因PDF 页面尺寸是按像素除以 DPI 计算的而有些工具默认 DPI 是 72 而非 300。8000 像素宽的图在 72 DPI 下是 282 厘米在 300 DPI 下是 67.7 厘米。很多新手只关注像素数量忽略了 DPI 这个隐藏变量。解决在导出参数里明确设置目标 DPI并检查 PDF 元数据中的页面尺寸是否等于预期物理尺寸。如果你用的工具导出的 PDF 不写 DPI 信息用 PDF 后期处理软件重设页面尺寸也是一种补救手段。5.5 同一区域第二次导出时图片内容和第一次不同现象相同范围、相同级别两次导出的地图内容不一致比如有些建筑消失或新增。原因在线地图源的内容是不断更新的前后间隔数天或数周瓦片自然不同。还有极小概率是 CDN 缓存策略导致不同节点返回了新旧不同的瓦片。解决这不是工具的 Bug而是数据源的时效性。要求一致性时先把瓦片下载到本地缓存再多次拼接或直接使用冷门时段导出。如果做历史对比分析请务必在导出时记录瓦片服务的来源和日期。6. 进阶用法把导出工具变成流水线的一环熟练了手动导出之后下一步是把它嵌入自动化流程。常见场景包括每天定时导出某个区域的最新底图用于值班大屏批量导出多个项目点位周边 500 米范围的高清影像作为调查附件或者与后处理流程联动导出后自动加水印、压缩、归档。我推荐一种轻量做法把导出逻辑封装成命令行脚本接收参数包括范围、级别、输出路径、坐标系类型python export_map.py --bounds 120.1,30.2,120.2,30.3 \ --zoom 17 --format pdf --dpi 300 \ --crs wgs84 --out ./output/demo.pdf脚本内部把范围解析、瓦片下载、拼接、PDF 打包串起来并写一个简单的日志文件记录每次导出的参数、耗时和瓦片总数。这套流程维护成本低但能解决大量重复劳动。验证环节同样重要。我一般会在脚本里加入一个「黄金区域」校验每次导出后自动与该区域上一次导出的已知文件做对比如果文件大小偏差过大或瓦片数量异常自动打上警告标记。这样做的原因是自动化流程跑久了人会放松检查让机器替你做第一道把关。如果你当前的需求只是偶尔导几张图掌握前文中手动操作的参数和避坑点已经足够。当导图变得频繁、范围变大、需要交付给多方复核时再上自动化。从一次导出到一个可复用脚本中间最关键的不是代码技巧而是对瓦片规则、坐标投影和 DPI 换算这些底层参数的真正理解。直到今天我每次拿到新工具第一件事仍然是先看它的坐标处理逻辑和重试策略——这两处决定工具上限。希望这篇文章能帮你少走几步弯路导出的每一张图都落在正确的位置上。本文还有配套的精品资源点击获取