这次我们来看一个把 QGIS 和 MCP 放到一起的实践项目:QGIS-MCP。简单说,它就是一层把开源 GIS 桌面软件 QGIS 的能力暴露给 AI 助手的桥。以前你要在 QGIS 里加载图层、执行缓冲区分析、统计某个区域内的要素数量,都得自己打开桌面软件一步一步点菜单;现在通过 MCP 协议,AI 客户端可以直接给你发指令,QGIS 在后台执行并把结果返回。对这个组合,大家最常问的问题有三个:还不会装 QGIS、不知道 MCP 是什么协议、接入之后到底能做什么。这篇文章直接把这几个问题都过一遍。
先给结论。QGIS-MCP 这个方向最有价值的地方有三点:第一,它把 QGIS 里最常用的图层管理、要素查询、空间分析能力变成了 AI 可调用的工具;第二,整个接入链路是标准的 MCP 协议,理论上任何支持 MCP 的 AI 客户端都能接,比如 Claude Desktop、Codex、Dify 这类平台;第三,除了让 AI 帮你点菜单,你还可以在脚本里批量调用同样的接口,做一套自动化的 GIS 数据处理流程。环境上不挑显卡,普通 CPU 机器就能跑,主要开销在 QGIS 进程本身和地图瓦片加载上。
这篇文章会按一条完整链路来演示:本机安装或确认 QGIS,搭建 Python 环境并启动 QGIS-MCP 服务,在 AI 客户端里配置 MCP 连接,用自然语言让 AI 完成图层加载、空间分析,再把同一套能力写到 Python 脚本里做批量任务。最后会把加载天地图、高德、百度在线地图时容易踩的坐标偏差、权限申请问题单独拎出来讲,并结合项目本身的功能边界、合规要求和使用建议做一次整理。
适合看的读者:正在做 GIS 数据处理、想用 AI 提效的工程师;在做 MCP 工具集成的开发者;以及刚接触 MCP 协议、想找一个能实际跑通的示例来学习的人。如果你只是想知道“这东西值不值得试”,那答案也很直接:值得,尤其是你每天都要在 QGIS 里重复做图层统计和空间查询的时候。
1. QGIS-MCP 核心能力速览
先给一张速览表,对照着看自己关心的问题,再展开解释。
| 能力项 | 说明 |
|---|---|
| 项目性质 | 通过 MCP 协议把 QGIS 桌面端变成 AI 可调用的工具服务 |
| 通信协议 | MCP(Model Context Protocol),基于 JSON-RPC 2.0 的工具调用协议 |
| 核心功能 | 图层加载管理、矢量要素查询、空间分析、地图浏览与导出 |
| 客户端支持 | 任何支持 MCP 的 AI 客户端,例如 Claude Desktop、Codex、Dify 等 |
| 硬件要求 | 普通 CPU 机器即可,不依赖 GPU,显存不是瓶颈 |
| 前置软件 | QGIS 3.x、Python、MCP Python SDK |
| 启动方式 | 命令行启动 MCP 服务,再在客户端配置文件注册 |
| 接口能力 | MCP 工具接口,可在脚本中按 JSON-RPC 格式调用 |
| 批量任务 | 可以在 Python 循环中连续调用多个工具,组合成批处理流程 |
| 主要风险 | 在线地图源授权、坐标系偏差、QGIS 环境变量配置错误 |
下面逐项解释表中几个关键点。
第一,MCP 是软件协议,不是硬件协议。它是在 AI 模型与外部工具之间做消息中转的应用层协议,核心交互方式是 JSON-RPC。AI 通过 tools/list 拿到可用工具列表,通过 tools/call 发起一次具体调用,工具执行完把结构化结果返回给大模型。QGIS-MCP 做的事情,就是把 QGIS 里的 PyQGIS 能力封装成这些 tool,让大模型能直接调用。热词里有人问“MCP 是软件协议还是硬件协议”,答案很明确:它是软件协议,工作在网络应用层。
第二,这个方案不挑显卡,也不是重负载服务。真正吃资源的是 QGIS 进程在后台加载图层、执行几何计算;MCP server 本身只是一个比较轻的中转层。所以在普通办公电脑上也能跑通,重点是保证磁盘上有足够的空间放地图数据和项目文件。如果你的目标是让 AI 批量分析几百个 shp 文件,建议先跑一个小数据集验证稳定性,再放完整数据进去。
第三,QGIS-MCP 的收益不只是“用嘴操作 QGIS”。更实际的价值是:它给了你一套统一的接口,把 QGIS 的分析能力接入到自己现有的工作流里。写脚本时不必单独学一遍复杂的 PyQGIS 调用方式,只需要按 MCP 工具的输入输出传参数,返回结果统一是结构化 JSON,非常好对接。这也是我把接口调用和批量任务单独写成章节的原因,因为这才是它的长期价值所在。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 适用场景与使用边界
这个项目的适用对象很明确。如果你属于下面三类人之一,建议认真看后面的部署步骤。
第一类是日常处理地理数据、要反复执行图层统计和空间查询的 GIS 工程师。比如每周都要统计某个行政区范围内的新增道路长度,以前要打开 QGIS、加载道路图层、按行政区裁剪、再跑统计,现在可以让 AI 按固定指令完成整个过程,人只需要检查结果。
第二类是在 Dify、Codex、Claude Desktop 上接 MCP 工具的 AI 应用开发者。你已经熟悉 MCP 协议的基本配置,但缺一个真实业务工具作为案例。QGIS-MCP 比单纯的文件操作工具复杂一些,能触发坐标转换、字段筛选、几何运算这些实际场景,更适合用来做工具集成的验证。
第三类是刚接触 MCP 协议、想读一个真实工具落地案例的人。通过 QGIS-MCP 可以看到一个桌面软件是如何被封装成 AI 工具、如何暴露函数清单、如何接收参数并返回结构化结果的全过程。
它不适合什么场景,也要提前说清楚。QGIS-MCP 不适合做实时导航、高并发在线地图服务,单次调用要经过“用户提问、模型理解、工具调用、GIS 执行、结果返回”几步,延迟在秒级,不适合对响应时间敏感的场景。它也不适合做精细的制图排版,地图符号化、图幅整饰这些工作还得回到 QGIS 界面里人工调整。此外,完全没有 GIS 基础、也不习惯维护 Python 环境的用户,配置阶段仍然会卡住,并不是零门槛开箱即用。
边界问题不可回避。天地图、高德地图、百度地图这类在线底图数据都受平台授权协议约束,个人学习测试没问题,但商业项目、公开部署、批量抓取数据前必须确认授权范围。涉及位置隐私的数据,例如小区点位、企业地址、人员轨迹,不要拿到公共 AI 服务里去分析;如果确实需要分析敏感位置数据,建议走本地部署大模型加本地 MCP 服务的方式,数据不出内网。不要用这套能力批量爬取地图内容,超出授权范围的抓取行为有合规风险。
3. 环境准备:QGIS、Python 与 MCP 协议基础
动手之前,先把环境清单列出来,照着检查。
- 操作系统:Windows 10/11、macOS、Linux 均可,QGIS 官方安装包覆盖三大平台。
- QGIS:推荐 QGIS 3.x 系列,安装时保持默认组件,确保 Python 支持可用。
- Python:独立安装 Python 3.10 或更高版本,专门用于跑 MCP server。
- MCP SDK:安装 Python 版 MCP SDK,或者按 QGIS-MCP 项目 README 的依赖列表安装。
安装要点需要特别留意。QGIS 安装包一般自带 Python 和 PyQGIS,但 MCP server 最好装在独立的 Python 环境里,避免和 QGIS 内置 Python 混用产生依赖冲突。Windows 上要确认三个路径:QGIS 安装路径、QGIS 自带的 Python 解释器路径、以及你为 MCP 准备的系统 Python 路径。大多数启动失败都发生在这一环节,后面排查方法里会展开。
先确认 QGIS 是否已经安装到位。
bash复制# Windows PowerShell 或 macOS/Linux 终端
qgis --version
如果命令提示找不到 qgis,就从开始菜单或 Applications 里找 QGIS 安装目录,或者直接打开 QGIS 桌面程序,在“关于”面板里查看版本号。注意,即使桌面程序能打开,命令行也不一定能直接找到 qgis,因为安装路径不一定被加入系统 PATH,这一步不用慌。
接着创建独立的 Python 虚拟环境并安装 MCP SDK。
bash复制python -m venv .venv
# Windows PowerShell
.venv\Scripts\Activate.ps1
# macOS / Linux
source .venv/bin/activate
pip install mcp
这里只安装 mcp 基础库,QGIS-MCP 项目可能还有额外依赖,以项目 README 为准。接下来验证 PyQGIS 是否能在当前解释器环境里正常导入。因为 QGIS 的 Python 库不在默认的 site-packages 里,往往需要手动指定路径,所以验证这一步很关键。
bash复制python -c "from qgis.core import QgsApplication; print('QGIS Python OK')"
如果这里报 ModuleNotFoundError,说明当前解释器找不到 QGIS 库。解决办法是把 QGIS 安装路径和 bin 目录加入环境变量后重新执行。Windows 下可以参考下面的写法,具体路径以本机实际安装目录为准。
bash复制set QGIS_PATH=C:\Program Files\QGIS 3.34
set PATH=%PATH%;%QGIS_PATH%\bin
环境准备阶段的核心思路是:QGIS 桌面程序能打开,只是第一步;真正决定 QGIS-MCP 能不能跑的,是 Python 能不能在命令行里导入 qgis.core 这个库。先把这个条件满足了,再进入下一步部署。
4. 安装部署与 QGIS-MCP 服务启动
环境准备好之后,开始安装项目本体。通常有两种方式取得代码:用 git 拉取远程仓库,或者下载发布包解压。下面给一套通用流程,具体命令需要按实际使用的项目仓库调整。
bash复制git clone <你的 QGIS-MCP 仓库地址> qgis-mcp
cd qgis-mcp
python -m venv .venv
# Windows PowerShell
.venv\Scripts\Activate.ps1
# macOS / Linux
source .venv/bin/activate
pip install -r requirements.txt
依赖安装完成后,启动 MCP 服务。不同项目提供的入口模块名不一样,下面命令中的 qgis_mcp.server 只是一个常见示例,实际入口请以项目 README 为准。
bash复制python -m qgis_mcp.server
服务启动后,正常情况下日志会打印监听地址和已注册的工具列表。如果你看到 tools 列表里有加载图层、查询要素、缓冲区分析之类的函数,说明服务本身已经就绪。这里要注意,QGIS-MCP 服务有两种传输模式,一种是 stdio 模式,适合 Claude Desktop 这类由客户端直接拉起子进程的场景;另一种是 HTTP 或 Streamable HTTP 模式,适合通过网络访问,日志里会打印端口。配置 AI 客户端之前,先搞清楚你的客户端支持哪种模式。
这里还有一个细节:MCP 服务启动时不一定要求 QGIS 桌面程序已打开,它可能会自动拉起 QGIS 进程,也可能用 QGIS 的 standalone Python 模式运行。如果服务起来了,但执行任何图层操作都返回“找不到 QGIS”或“无法连接”,不要急着怀疑代码,先回头检查环境变量里 QGIS 路径是否配置正确。
从网络安全角度,MCP 服务本质上是一个本地的 JSON-RPC 服务,建议只绑定 127.0.0.1,不要绑定 0.0.0.0 暴露到公网。否则任何能访问到该端口的人都能指挥你的 QGIS 执行操作,这是不必要的安全风险。如果确实需要远程访问,建议通过内网网关加鉴权的方式处理,而不是直接把端口公开出去。
5. 在 AI 客户端里配置 QGIS-MCP
不同 AI 客户端接入 MCP 的方式不完全一样,但底层逻辑相同:都是在客户端里登记一个“服务名、启动命令、工作目录”三元组。下面分别看 Claude Desktop、Codex 和 Dify 这类平台的常见配置方式。
Claude Desktop 通过配置文件注册 MCP 服务,核心是 mcpServers 这一段配置。因为你是要在本地启动 Python 模块,所以 command 写 python,args 写模块名,cwd 指向项目根目录。
json复制{
"mcpServers": {
"qgis": {
"command": "python",
"args": ["-m", "qgis_mcp.server"],
"cwd": "D:/Projects/qgis-mcp",
"env": {
"QGIS_PATH": "C:/Program Files/QGIS 3.34"
}
}
}
}
这里 env 里的 QGIS_PATH 按需配置,如果项目不读取这个变量,可以省略。关键点是 cwd 必须指向项目实际路径,而不是通用路径,否则客户端拉起 Python 后会找不到入口模块。
Codex 这类命令行客户端通常提供交互式命令来添加 MCP server,本质上也是生成类似的 JSON 配置,只是入口换成了命令行。例如在 Codex 的配置目录里新增一个 MCP 条目,把启动命令填成 python、参数填成 -m qgis_mcp.server,效果和上面的配置等价。如果你用的是通义灵码这类 IDE 插件去接 MCP,配置方式也类似,通常是在插件设置里找到 MCP 服务配置入口,粘贴服务器启动命令即可。
Dify 等平台型工具则多走 HTTP 模式。你需要先以 HTTP 模式启动 QGIS-MCP 服务,拿到监听地址,然后在 Dify 的工具或插件市场里添加自定义 MCP 工具,填入服务地址。地址形式类似 http://127.0.0.1:服务日志端口/mcp,具体路径以项目说明为准。Dify 的好处是可以把 QGIS 能力编排进工作流节点,再结合大模型节点做更复杂的 Agent 流程,适合搭业务应用。
配置完成后要重启客户端。怎么判断连接成功?看三个方面:第一,客户端工具列表里能看到 qgis 相关工具;第二,向 AI 提问“当前 QGIS 里加载了哪些图层”,能返回实际的图层列表而不是凭空编造;第三,执行一次零风险的查询,例如按 ID 查找某个要素,能拿到结构化 JSON 结果。这三个验证都通过,说明 QGIS-MCP 已经真正接入了你的 AI 客户端。
6. 功能测试与效果验证
6.1 图层加载测试
测试目的:确认 AI 能指挥 QGIS 加载本地矢量文件并读取字段信息。
测试输入示例:加载 D:/data/parcels.geojson 并列出字段列表。
操作步骤:先确保 MCP 服务和 QGIS 进程正常;再在客户端中发送这条指令;最后观察返回内容是否包含文件名、几何类型、字段列表和要素数量。
最直接的判断标准:返回 JSON 中能看到 geometryType、fields、featureCount 等信息,且字段名称和文件实际字段一致。如果返回“文件不存在”或“图层无效”,先手动在 QGIS 里打开同一个文件,排除数据文件本身损坏的可能;再检查工具是否有权限访问该路径。这里要提醒一个常见的坑:Windows 下的中文路径容易出问题,尽量把所有测试数据放到英文路径下。
6.2 空间分析测试
测试目的:验证 AI 能否调用 QGIS 的几何分析能力,而不只是读取属性。
推荐从缓冲区分析开始。测试输入:对 parcels 图层执行 100 米缓冲区分析,返回输出图层要素数量。
操作步骤:先确认 parcels 图层已经加载;然后让 AI 执行 buffer 类工具;最后检查返回的要素数和预期是否接近。缓冲区操作是 GIS 里最具代表性的空间分析之一,能跑通它,说明 MCP 工具链路里的参数传递、坐标系处理和结果返回都是通的。
需要注意,空间分析的结果可能写入临时图层,也可能保存到指定文件。如果 AI 返回时只给了图层名而没有文件路径,建议在提示词里补充一句“把结果保存到 D:/output 目录”,让结果落盘,方便后续检查。
6.3 在线地图加载测试:天地图、高德、百度
在线地图加载是 QGIS 用户最常搜的主题之一,热词里高频出现的“QGIS 加载天地图”“QGIS 如何下载百度或高德地图”都可以归到这里。用 QGIS-MCP 加载在线地图,本质和在 QGIS 界面里添加 XYZ Tiles 数据源一致,只是由 AI 来执行。
先看天地图。天地图需要先到官网申请 key,并配置域名白名单。加载时使用 WMTS 或 XYZ 瓦片地址,在地址参数里带上 tk 值。最常见的坑是瓦片显示灰底白格,说明当前域名不在 key 的白名单里。排查办法是去天地图控制台检查 key 状态和域名配置,改完白名单后重新加载。
再看高德和百度。高德地图使用的是 GCJ-02 坐标系,百度地图使用的是 BD-09 坐标系,而 QGIS 工程默认使用 WGS-84。直接把高德或百度瓦片叠加到 WGS-84 矢量数据上,会出现整体偏移,严重时道路和边界错位几米到几十米。正确处理方式有两种:一是为在线瓦片单独建立项目,把工程 CRS 设置为对应的坐标系;二是先把矢量数据转换到 GCJ-02 或 BD-09 后再叠加分析。
如果想快速验证在线地图能不能配合 QGIS-MCP 使用,成本最低的路径是:先在 QGIS 界面里添加一个 XYZ 瓦片连接,确认链接有效,再让 AI 基于这个已有图层做数据叠加分析。不要把“测试地图加载”和“测试 MCP 功能”两件事混在一起,否则出错了不容易定位。
7. 接口调用与批量任务
QGIS-MCP 的 MCP 工具接口本质上遵循 JSON-RPC 2.0 规范。如果不想通过 AI 客户端,可以直接写脚本按协议发起请求。下面的 Python 代码是一个通用调用模板,具体工具名称和参数字段需要根据你启动的服务提供的能力列表来调整。
python复制import json
import urllib.request
def call_mcp_tool(url, tool_name, arguments, request_id=1):
payload = {
"jsonrpc": "2.0",
"id": request_id,
"method": "tools/call",
"params": {
"name": tool_name,
"arguments": arguments
}
}
req = urllib.request.Request(
url,
data=json.dumps(payload).encode("utf-8"),
headers={"Content-Type": "application/json"}
)
with urllib.request.urlopen(req, timeout=120) as resp:
return json.loads(resp.read().decode("utf-8"))
调用地址从服务日志里获取,HTTP 模式下通常是 http://127.0.0.1:端口号/mcp,实际以日志展示为准。写脚本前,先请求一次 tools/list,把所有工具名、描述和参数结构打印出来,再写实际调用逻辑,可以避免频繁改参数格式。
批量任务的处理思路也比较固定。这里给出一种目录驱动加循环调用的方式。
python复制import time
layer_list = [
{"name": "road_2020", "path": "D:/data/road_2020.shp"},
{"name": "road_2021", "path": "D:/data/road_2021.shp"},
{"name": "road_2022", "path": "D:/data/road_2022.shp"},
]
for item in layer_list:
result = call_mcp_tool(
url="http://127.0.0.1:8000/mcp",
tool_name="load_layer",
arguments=item
)
print(item["name"], result.get("status"))
time.sleep(1)
批量任务有三个关键细节要记住。第一,每次调用使用自增的 request_id,方便和日志对齐,定位失败请求。第二,失败的任务不要立即重试,先确认是数据文件问题还是 MCP 服务问题,否则反复调用只会堆积错误日志。第三,批处理建议把每个任务的入参、状态、耗时和错误写入 CSV 或 SQLite,中途断电后可以断点续跑,不用全部重新执行。这个习惯在线程数超过十、数据量超过几十个文件的批次任务里尤其重要。
8. 资源占用与性能观察
QGIS-MCP 不像大模型推理那样吃显卡,它的瓶颈通常在 CPU、内存和磁盘。如果你在跑批量空间分析,需要关注三个指标。
第一个是 CPU。加载大型 shp 文件、执行几何运算时,QGIS 进程的 CPU 使用会明显升高,可能长时间维持高位;而 MCP server 本身的 CPU 占用非常低,它只是转发请求和结果。如果 CPU 被打满,优先怀疑是不是正在执行复杂的几何运算,而不是怀疑通信协议效率。
第二个是内存。加载大栅格影像,比如 TIF、MBTiles,内存涨幅最明显;同时加载几十个图层时,内存占用可能达到几个 GB。建议先用小范围测试数据观察内存基线,再决定是否让 AI 一次处理全部图层。如果内存经常逼近上限,把批处理任务拆小,比如每次只处理 5 个图层,跑完一轮再处理下一轮。
第三个是磁盘。瓦片缓存和临时目录会不断消耗磁盘空间,长时间跑批量任务时尤其明显。QGIS 默认把缓存放在用户目录下面,跑完大任务后要清理缓存文件和临时输出,避免占用过多磁盘空间。
观察方式很简单:Windows 用任务管理器,按 CPU 和内存排序,看哪一个进程在涨;macOS 或 Linux 用 htop 或 ps -aux 查看。另外 QGIS 自带的日志消息面板会输出数据处理过程中的警告和错误,很多性能问题会在这里留下线索。
如果发现性能不足,优先做三件事:一是对输入图层做几何简化,二是按区域分块处理,三是提前过滤掉不需要的字段。不要一上来就拿全国级数据让 AI 做全量分析,即使服务能撑住,等待时间也会让调试效率大幅下降。
9. 常见问题与排查方法
把容易出现的问题整理成一张表,方便快速定位。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 客户端看不到 qgis 工具 | MCP 服务未启动或配置路径错误 | 查看服务日志和客户端配置 | 先手动启动服务,再重启客户端 |
| 启动报 Python 解释器错误 | QGIS 内置 Python 与系统 Python 混用 | 确认服务使用的解释器路径 | 统一环境变量,或直接用 QGIS 自带 Python |
| 执行图层操作返回找不到文件 | 路径含中文或反斜杠导致解析失败 | 查看返回的错误路径信息 | 改用英文路径、正斜杠或 GeoPackage |
| 加载高德地图后大量错位 | GCJ-02 坐标系与 WGS-84 不一致 | 对比图层范围和参考底图 | 切换工程 CRS 或做坐标转换 |
| 天地图瓦片灰底不显示 | key 未申请或域名白名单不匹配 | 登录天地图官网检查 key 状态 | 添加当前域名到白名单后重新加载 |
| MCP 服务端口被占用 | 上一个服务进程未正确退出 | 查看端口占用进程 | 结束旧进程或改用其他端口 |
| 批量任务执行到一半卡住 | 单条数据异常或缓存膨胀 | 查看 QGIS 日志和任务状态记录 | 减小批次大小,对失败数据逐条重试 |
| AI 多次调用同一工具结果不一致 | 参数未标准化 | 让 AI 输出统一 JSON 模板 | 在提示词中固定参数格式 |
依赖安装失败也很常见。如果 pip install 报依赖冲突,不要用系统 Python 强行安装,建议重新建一个干净虚拟环境,再按 requirements.txt 安装。如果 pip 下载慢,可以换成国内镜像源,但要注意这是网络环境问题,和 QGIS-MCP 项目本身无关。
还有一个需要注意的坑是 QGIS 版本差异。QGIS 3.x 不同小版本之间,PyQGIS 的部分 API 可能有变动,某些低版本写的工具在高版本里会提示方法不存在。遇到这种情况,优先看官方升级文档或 QGIS 的 API 变更说明,不要盲目改代码。
10. 最佳实践与使用建议
把 QGIS-MCP 接入日常工作流后,下面这些工程化建议值得保留。
第一,固定一套最小可运行配置。把 QGIS 安装路径、Python 解释器路径、MCP 启动命令写成一个启动脚本,放到项目目录里,团队其他成员共用。这套配置一旦验证通过,就不要频繁改动,避免出现“在我机器上能跑”的问题。
第二,提示词里给固定模板。例如规定“加载图层后必须先调用字段列表工具查看字段,再执行分析”“分析结果必须返回 JSON 格式”“失败必须返回错误原因”。固定模板能减少大模型自由发挥带来的输出不稳定。
第三,数据目录分三层。原始输入放 input,分析结果放 output,临时缓存放 cache,目录结构写死在配置里。这样既能防止批处理任务污染原始数据,也能在出问题时迅速定位是哪个文件被改动了。
第四,批量任务必须插桩记录。每一条任务记录入参、状态、耗时、错误信息,写进日志文件。没有日志的批处理几乎无法排查,特别是跑了上百个图层之后。
第五,MCP 服务只监听本机地址。如果后续做成内网工具平台,再加认证层,由平台统一管控访问权限。
第六,合规红线要提前确认。在线地图数据授权、敏感位置数据、隐私要素图层,是 GIS 场景里最容易踩红线的三个地方。使用前确认授权,使用中控制数据范围,使用后清理中间产物,这些习惯能让项目走得更稳。
11. 总结与下一步
QGIS-MCP 这个方向最值得先尝试的,不是一上来就让它做复杂的空间分析,而是先打通链路:启动服务、配置客户端、让 AI 加载一个图层并回答字段信息。这一步能跑通,后面加缓冲区、裁剪、属性筛选,本质上都是同一套 MCP 工具接口的延伸。最先要验证的功能建议是图层加载加空间分析,这套组合能覆盖大部分日常 GIS 重复劳动。
最容易踩的坑集中在环境变量和 Python 解释器选择上。提前把 QGIS 路径统一好,确认 python -c 能导入 qgis.core,后面就能少掉大半启动问题。在线地图加载也容易踩坐标系坑,高德、百度的地图源必须先确认 CRS 再做叠加分析。
下一步可以考虑两个方向。一是把 QGIS-MCP 接入 Dify 工作流,做成一个具备 GIS 分析能力的业务应用;二是写几个批量脚本,把每周重复的统计任务自动化,并加上日志和断点续跑。两个方向都不需要换硬件,也不需要重新学一套技术栈,就是在现有接口上继续扩展。对经常处理地理数据的人来说,这套组合值得收藏备用。
