从零构建全栈 WebGIS 系统：基于 Flask + PostGIS + Leaflet 的地名与路径规划平台

为什么要做这个系统？

地名是承载空间、自然与文化信息的重要地理标识。然而，传统的地名管理往往依赖人工或重型桌面端 GIS 软件，存在信息更新滞后、多端共享困难等痛点。

为了探索更轻量、高效的空间数据管理模式，我独立全栈开发了这套基于 B/S 架构的地名与路径规划管理系统。系统彻底打通了从底层空间数据库（PostGIS）、后端业务逻辑（Flask）到前端动态交互（Leaflet + Vanilla JS）的数据流，并自主集成了基于真实路网的 Dijkstra 最短路径计算功能。

---

1. 核心架构与技术栈

系统采用经典的前后端分离 B/S 架构，开发流完全在本地/云端虚拟环境（venv）中隔离，确保了极高的可移植性。

• 前端交互与地图渲染：HTML5 / CSS3 / JavaScript, Leaflet.js (集成 MarkerCluster 聚合插件处理海量点位)。
• 后端 API 与核心逻辑：Python (Flask), 提供跨域 (CORS) 支持的 RESTful API。
• 空间数据库底座：PostgreSQL + PostGIS，原生支持空间索引与 ST_AsGeoJSON 等空间查询函数。
• 路径规划算法层：基于 OSMnx 与 NetworkX 解析 OpenStreetMap 真实路网，自主实现 Dijkstra 算法。

graph TD
    A[前端浏览器 UI / Leaflet Map] <-->|AJAX / GeoJSON / REST API| B(后端 Flask Web Server)
    B <-->|SQL / psycopg2| C[(PostgreSQL + PostGIS 数据库)]
    B <-->|起点/终点 坐标| D[路径规划模块 path_finding.py]
    D <-->|读取| E((南通市 OSM 路网图 graphml))

---

2. 空间数据库设计与互操作

数据的核心在于 PostgreSQL + PostGIS。针对地名数据，我设计了 place_info 表，除了常规的属性字段（ID、名称、省市县）外，重点维护了空间坐标（经纬度）。

后端如何与 PostGIS 优雅交互？
在后端的 access_DB.py 中，我并没有只取属性数据，而是利用 PostGIS 的强大空间函数，直接在 SQL 查询阶段将几何数据转化为前端可以直接使用的 GeoJSON 格式：

# 核心 SQL 逻辑示例 (伪代码)
SELECT 
    id, name, category, 
    ST_AsGeoJSON(ST_MakePoint(longitude, latitude))::json AS geometry 
FROM public.jsplaces;

这种处理方式极大减轻了后端的序列化负担，前端拿到数据后可直接通过 L.geoJSON() 加载。

---

3. 核心突破一：海量地名 CRUD 与地图动态聚合

本系统不仅是一个展示平台，更是一个管理平台。

1. 双向数据绑定：前端数据表与地图标记完全同步。在数据表中新增、修改或删除某条地名数据（AJAX 异步请求），后端更新 PostGIS 后，前端地图上的 Marker 会立刻响应刷新。
2. 海量点渲染优化：江苏省内地名数据庞大，直接渲染数万个 Marker 会导致浏览器 DOM 崩溃。我引入了 Leaflet.markercluster 插件。在 L_map.js 中，将其封装为 MarkerClusterGroup，在不同缩放级别下动态聚合点位，保障了地图滚轮缩放的丝滑体验。

图 1：基于 Leaflet 的地名空间聚合展示与属性弹窗

---

4. 核心突破二：基于真实路网的 Dijkstra 最短路径规划

这是系统中最具挑战性，也是最有意思（Geek）的功能。它不同于直接调用百度/高德地图 API，而是从零实现基于矢量图结构的算法计算。

4.1 算法选型与实现

最短路径采用经典的 Dijkstra（迪杰斯特拉）算法，核心思想是通过贪心策略，不断更新起步节点到周围邻接节点的临时标号，直至找到终点。

4.2 工程化落地流程

在 path_finding.py 中，我完成了以下全链路开发：

1. 路网预处理：使用 OSMnx 提前下载并构建南通市路网的拓扑图对象（.graphml），将道路交叉口抽象为节点（Node），道路抽象为边（Edge）。
2. 坐标捕捉（Snapping）：用户在前端 Leaflet 地图上任意点击两个点，后端接收到坐标后，利用 KD-Tree 算法在拓扑图中找到距离这两个点最近的真实路网节点。
3. 图遍历与路径回溯：使用 NetworkX 和最小堆（heapq）实现高效率的 Dijkstra 算法遍历，计算出最短路径节点的序列，并将其转化为经纬度坐标串返回给前端。
4. 前端绘制：前端利用 L.polyline 将路径平滑渲染在地图上。

图 2：基于 Dijkstra 算法的真实路网动态最短路径规划效果

---

5. 项目总结：从业务到底层的全栈视角

开发这个地名管理系统，是我将 GIS 理论（空间拓扑/路径分析） 与 现代 Web 工程（API 设计/前后端分离/DOM 交互） 深度融合的一次成功尝试。

1. 产品同理心：在设计地名属性修改功能时，我深刻体会到用户操作的便捷性要求。前端校验配合后端容错，才能打造稳健的 B 端管理系统。
2. 技术深度探索：手写 Dijkstra 并对接实际的 OSM 路网，让我对“图计算”和“路径导航”的底层逻辑有了本质认识。这远比仅仅调一个第三方 API 接口有价值得多。
3. 未来展望：目前系统尚未集成大型空间框架引擎，未来考虑将本地开发流迁移至 GitHub Codespaces 或 Docker 容器中，并结合 CI/CD 实现自动化部署，进一步践行云原生 WebGIS 开发流。

---