簡(jiǎn)介這是一套將圖數(shù)據(jù)庫(kù)Neo4j與OpenStreetMap地理數(shù)據(jù)結(jié)合、以Java實(shí)現(xiàn)的簡(jiǎn)單路由服務(wù)項(xiàng)目源碼面向需要在地圖類應(yīng)用中集成路線規(guī)劃能力的Java開(kāi)發(fā)者。壓縮包共35個(gè)文件核心為22個(gè)Java源文件附帶3個(gè)OSM示例地圖、1個(gè)PBF數(shù)據(jù)文件以及Gradle構(gòu)建配置、屬性文件和說(shuō)明文檔整體約314KB結(jié)構(gòu)清晰便于直接導(dǎo)入與二次開(kāi)發(fā)。項(xiàng)目展示了從OSM數(shù)據(jù)解析、路網(wǎng)建模到Cypher查詢最短路徑的完整鏈路可作為理解空間數(shù)據(jù)建模與圖數(shù)據(jù)庫(kù)路線的實(shí)踐參考。已有169人學(xué)習(xí)或下載適合對(duì)圖數(shù)據(jù)庫(kù)、地理信息系統(tǒng)或路徑優(yōu)化感興趣的中高級(jí)Java工程師。1. Neo4jOSM 到底是什么與其說(shuō)得繞路不如換成圖遍歷做地圖和導(dǎo)航的都知道傳統(tǒng)路由服務(wù)要么用 PostGIS pgRouting要么自己寫 A*。但你有沒(méi)有想過(guò)一個(gè)問(wèn)題路網(wǎng)本身就是一張圖路口是節(jié)點(diǎn)路段是邊而 Neo4j 天生就是存“節(jié)點(diǎn)和關(guān)系”的數(shù)據(jù)庫(kù)。Neo4jOSM 這個(gè)方向本質(zhì)就是拿 OpenStreetMap 的原始路網(wǎng)數(shù)據(jù)灌進(jìn) Neo4j把“兩點(diǎn)之間怎么走”從最短路徑算法問(wèn)題變成圖數(shù)據(jù)庫(kù)的遍歷查詢問(wèn)題。我第一次接觸這個(gè)方案是被一個(gè)做同城配送的朋友拉去看的他們想在一套圖數(shù)據(jù)庫(kù)里同時(shí)管知識(shí)圖譜和路徑計(jì)算不想為了一個(gè)路由功能單獨(dú)再插一套 pgRouting。當(dāng)時(shí)我的第一反應(yīng)是“圖數(shù)據(jù)庫(kù)做路由肯定慢”但實(shí)際跑完才發(fā)現(xiàn)數(shù)據(jù)量控制在十萬(wàn)級(jí)節(jié)點(diǎn)以內(nèi)時(shí)Cypher 的遍歷效率完全能接受而且開(kāi)發(fā)和排錯(cuò)的成本比傳統(tǒng)方案低得多。這個(gè)方案適合兩類人一類是已經(jīng)在用 Neo4j 做業(yè)務(wù)、需要順帶解決路線計(jì)算的人另一類是想快速做一個(gè)輕量導(dǎo)航原型、又不想碰地理信息系統(tǒng)那套重工具的開(kāi)發(fā)者。2. 為什么路由要選圖數(shù)據(jù)庫(kù)從路網(wǎng)的數(shù)據(jù)模型說(shuō)起2.1 路網(wǎng)不是坐標(biāo)系而是圖結(jié)構(gòu)很多人第一次接觸 OSM 數(shù)據(jù)時(shí)會(huì)下意識(shí)把它當(dāng)成一堆經(jīng)緯度坐標(biāo)。這其實(shí)是最大的誤解。OSM 的原始數(shù)據(jù)模型里只有三類核心元素Node點(diǎn)、Way線、Relation關(guān)系。一段從 A 路口到 B 路口的道路是由一串 Node 組成一條 Way多個(gè) Way 再組合成完整的道路網(wǎng)。這和 Neo4j 的 Label、Relationship 模型有一種天然的對(duì)應(yīng)關(guān)系。我在設(shè)計(jì)這套路由服務(wù)的數(shù)據(jù)模型時(shí)走了兩條路線來(lái)回對(duì)比。第一種方案是把每個(gè) OSM 的 Way 當(dāng)作一條 Neo4j 關(guān)系這條路的所有幾何信息存在關(guān)系的屬性里。第二種方案是節(jié)點(diǎn)對(duì)應(yīng)路口關(guān)系對(duì)應(yīng)路段。最終我選擇了第二種因?yàn)槁酚傻暮诵挠?jì)算單元是“從一個(gè)節(jié)點(diǎn)到另一個(gè)節(jié)點(diǎn)經(jīng)過(guò)哪些關(guān)系”如果 Way 直接作為關(guān)系路口的轉(zhuǎn)彎角度、多條路匯聚的邏輯反而要額外處理。OSM 數(shù)據(jù)里最容易被忽視的是方向性。高速公路是單向的普通街道是雙向的。在 Neo4j 建模時(shí)關(guān)系必須有 Direction 屬性區(qū)分 oneway 和雙向否則后續(xù)算出來(lái)的路線可能帶著你逆行。這不是算法的復(fù)雜度問(wèn)題而是數(shù)據(jù)模型的精準(zhǔn)度問(wèn)題。2.2 圖數(shù)據(jù)庫(kù)的路由優(yōu)勢(shì)一條 Cypher 就夠傳統(tǒng)路由方案的痛點(diǎn)在于最短路徑算法是外部實(shí)現(xiàn)的要么是 GIS 擴(kuò)展的存儲(chǔ)過(guò)程要么是獨(dú)立微服務(wù)。Neo4j 的好處是路徑遍歷是 Cypher 查詢語(yǔ)言的原生能力不需要額外寫算法模塊。拿一個(gè)最基本的需求舉例找從 A 點(diǎn)到 B 點(diǎn)的最短路徑。Cypher 里的 MATCH pshortestPath(...) 可以直接跑通。更重要的是你不用像傳統(tǒng)方案那樣預(yù)先建好拓?fù)潢P(guān)系表圖數(shù)據(jù)庫(kù)的節(jié)點(diǎn)和關(guān)系本身就是拓?fù)?。新增一條道路就是一個(gè)新關(guān)系刪除一條封路就是刪除一個(gè)關(guān)系。對(duì)于“路線需要隨路況實(shí)時(shí)調(diào)整”的場(chǎng)景這種數(shù)據(jù)模型的靈活性是壓倒性的。當(dāng)時(shí)我并用 pgRouting 和 Neo4j 各實(shí)現(xiàn)了一版在數(shù)據(jù)量一致的情況下Neo4j 的啟動(dòng)慢一些但小范圍查詢的熱數(shù)據(jù)會(huì)比關(guān)系型方案更穩(wěn)因?yàn)楸闅v過(guò)程是在內(nèi)存里完成的不需要反復(fù) JOIN 多張表。2.3 用得當(dāng)心不是所有路由需求都適合 Neo4j這是我在朋友圈說(shuō)過(guò)最多的一句話拿 Neo4j 做路由控制好規(guī)模就是利器失控就是災(zāi)難。Neo4j 的遍歷效率會(huì)隨跳數(shù)線性增長(zhǎng)十跳以內(nèi)的路線幾乎秒出但超過(guò)二十跳響應(yīng)時(shí)間開(kāi)始惡化。如果你要做的全國(guó)范圍貨車調(diào)度幾十萬(wàn)甚至上百萬(wàn)個(gè)路網(wǎng)節(jié)點(diǎn)Neo4j 社區(qū)版未必扛得住。適合用 Neo4j 的場(chǎng)景是單城市或區(qū)域性的路網(wǎng)節(jié)點(diǎn)量在十萬(wàn)級(jí)且路由計(jì)算不是核心業(yè)務(wù)的全部壓力。比如門店配送路徑、園區(qū)內(nèi)部導(dǎo)航、景點(diǎn)游覽路線。如果答案是“全國(guó)幾千萬(wàn)個(gè)路口節(jié)點(diǎn)”我建議直接往 pgRouting 或 Valhalla 方向選型。3. 把 OSM 路網(wǎng)灌進(jìn) Neo4j完整導(dǎo)入鏈路與參數(shù)設(shè)置3.1 工作臺(tái)搭建設(shè)置與數(shù)據(jù)準(zhǔn)備我是按這套流程跑的先準(zhǔn)備好環(huán)境。Neo4j 社區(qū)版是必需的版本我推薦 4.x 以上因?yàn)?Cypher 的語(yǔ)義和 APOC 插件的兼容性更穩(wěn)定。另一個(gè)準(zhǔn)備是 OSM 數(shù)據(jù)文件范圍別貪大先用一個(gè)小城市或一個(gè)區(qū)的 .osm.pbf 格式測(cè)試鏈路。我一般不建議直接用 pbf 去解析而是先轉(zhuǎn)成 OSM XML 格式方便肉眼檢查數(shù)據(jù)。用 osmium 工具做這個(gè)轉(zhuǎn)換最省心。wget https://download.geofabrik.de/asia/china-latest.osm.pbf osmium cat china-latest.osm.pbf -o beijing.osm這里的 china-latest.osm.pbf 是整個(gè)國(guó)家的數(shù)據(jù)但我只需要北京范圍所以用 osmium 的邊界過(guò)濾更合理。真正實(shí)操時(shí)我會(huì)加 bbox 參數(shù)只提取目標(biāo)區(qū)域這樣導(dǎo)入 Neo4j 的數(shù)據(jù)量小一個(gè)數(shù)量級(jí)排錯(cuò)也方便。上面的命令只是第一步重點(diǎn)在于后續(xù)的數(shù)據(jù)結(jié)構(gòu)轉(zhuǎn)換解析要自己寫而不是靠現(xiàn)成的導(dǎo)入工具硬灌因?yàn)楝F(xiàn)成工具往往不做拓?fù)淝逑础?.2 自己寫一個(gè) Python 解析器核心代碼與邏輯拆解圖數(shù)據(jù)庫(kù)里做路由最重要的不是導(dǎo)入 OSM 數(shù)據(jù)本身而是構(gòu)建出可導(dǎo)航的拓?fù)洹SM 原始數(shù)據(jù)里一條 Way 有多個(gè) Node這些 Node 可能是純幾何形狀點(diǎn)也可能正好是路口。我的策略是只把路口節(jié)點(diǎn)導(dǎo)入 Neo4j路段作為 Relationship 屬性里的坐標(biāo)串存下來(lái)。這里給一個(gè)能直接跑的解析器骨架import osmium from neo4j import GraphDatabase class RouterWriter(osmium.SimpleHandler): def __init__(self, driver): super().__init__() self.driver driver self.way_nodes {} self.node_coords {} self.turn_rules [] def node(self, n): # 只保留有路口潛力的節(jié)點(diǎn)坐標(biāo)先全部緩存 self.node_coords[n.id] (n.location.lon, n.location.lat) def way(self, w): if highway not in w.tags: return highway_type w.tags[highway] if highway_type not in [motorway, trunk, primary, secondary, tertiary, residential]: return nodes [n.ref for n in w.nodes] oneway w.tags.get(oneway, no) # TODO確定哪些節(jié)點(diǎn)是交叉路口需要與其它 way 求交集 self.way_nodes[w.id] { nodes: nodes, highway: highway_type, oneway: oneway }關(guān)鍵邏輯先在 Python 里保留一份 way 節(jié)點(diǎn)序列緩存再在后續(xù)清洗中過(guò)濾出真實(shí)路口。直接邊讀 OSM 邊寫入 Neo4j 的做法我試過(guò)一次導(dǎo)入中途遇到數(shù)據(jù)異常就得回滾很難排查。所以我把清洗和寫入拆成了兩個(gè)階段第一階段先落盤成 CSV第二階段用 Neo4j 的批量導(dǎo)入命令。這是效率最高、也最容易控制錯(cuò)誤的方式。3.3 Neo4j 導(dǎo)入命令和索引配置解析出路口和路段之后生成兩個(gè) CSV 文件一個(gè) nodes.csv 一個(gè) ways.csv然后直接用 Neo4j 的LOAD CSV或 admin import 寫入。社區(qū)版里最穩(wěn)妥的是逐條執(zhí)行 Cypher 寫入數(shù)據(jù)量小于五萬(wàn)條時(shí)沒(méi)問(wèn)題。// 創(chuàng)建路網(wǎng)節(jié)點(diǎn) LOAD CSV WITH HEADERS FROM file:///nodes.csv AS row CREATE (n:RoadNode { id: toInteger(row.osm_id), lat: toFloat(row.lat), lon: toFloat(row.lon) }); // 創(chuàng)建路段關(guān)系 LOAD CSV WITH HEADERS FROM file:///ways.csv AS row MATCH (a:RoadNode {id: toInteger(row.source)}) MATCH (b:RoadNode {id: toInteger(row.target)}) CREATE (a)-[:ROAD { highway_type: row.highway, distance_m: toFloat(row.distance_m), oneway: row.oneway }]-(b);注意這里的 oneway 屬性一定要在導(dǎo)入時(shí)處理成方向關(guān)系。我踩過(guò)的坑是雙向路段在 OSM 里是一條 Way但如果只在 Cypher 里建一條關(guān)系從 B 到 A 就沒(méi)辦法遍歷。正確做法是在解析器里判斷 oneway如果是雙向就把 source 和 target 互換再建一條反向關(guān)系。索引設(shè)置很關(guān)鍵。路由查詢的第一步是錨定起點(diǎn)和終點(diǎn)節(jié)點(diǎn)如果id屬性沒(méi)有索引neo4j 會(huì)全表掃描這會(huì)讓十萬(wàn)級(jí)節(jié)點(diǎn)的查詢直接卡上十幾秒。我當(dāng)時(shí)是這么下的CREATE INDEX road_node_id IF NOT EXISTS FOR (n:RoadNode) ON (n.id);這個(gè)索引幾乎決定了所有路由查詢的基礎(chǔ)性能務(wù)必最先創(chuàng)建。4. Cypher 里實(shí)現(xiàn)最短路徑三個(gè)查詢方案與參數(shù)調(diào)優(yōu)4.1 最直觀的寫法shortestPath 函數(shù)數(shù)據(jù)導(dǎo)入完成之后最重要的環(huán)節(jié)就是寫路由查詢。先頭最簡(jiǎn)單的版本用 Neo4j 內(nèi)建 shortestPath 方法MATCH (a:RoadNode {id: 12345}), (b:RoadNode {id: 54321}) MATCH p shortestPath((a)-[:ROAD*]-(b)) RETURN p, reduce(s 0.0, r IN relationships(p) | s r.distance_m) AS total_distance這里的[:ROAD*]表示沿任意深度遍歷關(guān)系。shortestPath 內(nèi)部做的是雙向 BFS 的優(yōu)化版在小型路網(wǎng)上會(huì)非常快可問(wèn)題是它默認(rèn)按跳數(shù)最少優(yōu)先不是按路程最短優(yōu)先。如果一條路線經(jīng)過(guò)很多短路段另一條路線只經(jīng)過(guò)兩條長(zhǎng)路段它會(huì)選擇后者。這跟我實(shí)際做配送路由時(shí)的需求正好相反。這是第一個(gè)要調(diào)的點(diǎn)如果只是求“經(jīng)過(guò)路口最少”的路線shortestPath 就夠如果求的是“物理距離最短”需要換方案。4.2 按距離加權(quán)的最短路徑APOC 擴(kuò)展的 DijkstraNeo4j 官方的 APOC 插件庫(kù)提供了一套更靠譜的算法實(shí)現(xiàn)支持帶權(quán)重的 Dijkstra。這是我最常用的路由寫法也是真正能上生產(chǎn)環(huán)境的方式MATCH (a:RoadNode {id: 12345}), (b:RoadNode {id: 54321}) CALL apoc.algo.dijkstra(a, b, ROAD, distance_m) YIELD path, weight RETURN path, weightapoc.algo.dijkstra四個(gè)參數(shù)含義分別是起始節(jié)點(diǎn)、目標(biāo)節(jié)點(diǎn)、關(guān)系類型、權(quán)重屬性。這里的 weight 就是上面導(dǎo)入時(shí)存的 distance_m單位是米。用它跑出來(lái)的結(jié)果是真正按距離算的最短路徑。這個(gè)查詢有兩點(diǎn)值得注意。第一APOC 版本要跟 Neo4j 版本對(duì)應(yīng)我在 Neo4j 4.4 配 APOC 4.4 的 core 包否則會(huì)遇到閃退或函數(shù)找不到的問(wèn)題。第二如果路網(wǎng)關(guān)系里存在 0 權(quán)重或負(fù)權(quán)重Dijkstra 會(huì)直接掛掉甚至死循環(huán)。導(dǎo)入數(shù)據(jù)時(shí)我做了過(guò)濾凡是 distance_m 小于 1 的路段直接丟棄避免這種邊緣情況。4.3 從一個(gè)節(jié)點(diǎn)出發(fā)查詢所有可達(dá)路徑熱詞里有人搜“neo4j查詢從一個(gè)節(jié)點(diǎn)出發(fā)如何查詢多條”這個(gè)恰恰是圖數(shù)據(jù)庫(kù)路由最有優(yōu)勢(shì)的場(chǎng)景。比如配送站要同時(shí)服務(wù)三十個(gè)客戶點(diǎn)傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)要一條條調(diào)接口而 Cypher 只需要一次查詢就可以把所有按距離排序的可達(dá)路徑拉出來(lái)。MATCH (start:RoadNode {id: 12345}) MATCH (target:RoadNode) WHERE target.id IN [54321, 54322, 54323, 54324] CALL apoc.algo.dijkstra(start, target, ROAD, distance_m) YIELD path, weight RETURN target.id, weight, [n IN nodes(path) | n.id] AS node_list ORDER BY weight ASC執(zhí)行計(jì)劃上這種寫法每一次 CALL 都會(huì)觸發(fā)一次單源 Dijkstra所以如果目標(biāo)節(jié)點(diǎn)有幾十上百個(gè)性能會(huì)直線下降。我的優(yōu)化思路是先加一個(gè)粗粒度的距離過(guò)濾比如用 Neo4j 的空間函數(shù)先算節(jié)點(diǎn)間的直線距離過(guò)濾掉三公里外的節(jié)點(diǎn)減少需要跑 Dijkstra 的目標(biāo)數(shù)量。![Note] 可以把這段查詢發(fā)布成自定義存儲(chǔ)過(guò)程因?yàn)?Neo4j 官方寫法對(duì)結(jié)果去重和并行有一定限制存儲(chǔ)過(guò)程能更好地控制資源。5. 路由上線的避坑記錄坐標(biāo)偏移、數(shù)據(jù)漂移與性能問(wèn)題5.1 路線生成后在地圖上位置對(duì)不上這是最詭異的故障。數(shù)據(jù)導(dǎo)入了、查詢通了、路徑也返回了但在前端地圖組件上畫出來(lái)后路線浮在馬路邊的住宅區(qū)里。排查后發(fā)現(xiàn)是坐標(biāo)參考系的鍋?，F(xiàn)象OSM 數(shù)據(jù)默認(rèn)坐標(biāo)系是 WGS84GPS 用的經(jīng)緯度坐標(biāo)而高德或百度地圖在國(guó)內(nèi)使用的是 GCJ-02 加偏坐標(biāo)系。Neo4j 里存的是原始 WGS84前端地圖工具自動(dòng)做了坐標(biāo)系糾偏于是雙重偏移導(dǎo)致路線錯(cuò)位。原因把 OSM 的坐標(biāo)直接當(dāng)成了國(guó)內(nèi)地圖運(yùn)營(yíng)商坐標(biāo)系里的坐標(biāo)來(lái)用。解決要么在解析器里把 WGS84 轉(zhuǎn)成 GCJ-02 再入庫(kù)要么前端關(guān)閉自動(dòng)偏轉(zhuǎn)。我選了前者寫了一個(gè)wgs84_to_gcj02的算法函數(shù)在導(dǎo)入 CSV 前先做一次坐標(biāo)轉(zhuǎn)換這樣后續(xù)所有業(yè)務(wù)邏輯和可視化都保持一致。5.2 一度路口連不上拓?fù)鋽嗔褜?dǎo)致路線查不到又一個(gè)高頻坑。導(dǎo)入完成后路由只返回了一個(gè)起點(diǎn)節(jié)點(diǎn)路徑完全不存在。我單步排查發(fā)現(xiàn)有 37% 的節(jié)點(diǎn)成了“孤島”完全沒(méi)有關(guān)系。原因有三個(gè)。第一OSM 原始數(shù)據(jù)里兩條路在物理上交叉但并沒(méi)有共享同一個(gè)節(jié)點(diǎn) ID這也是數(shù)據(jù)拓?fù)鋽嗔训牡湫驮蛑弧５诙馕鰰r(shí)我把節(jié)點(diǎn)精度過(guò)濾做得太激進(jìn)把一些交叉口誤判成了形狀點(diǎn)丟了。第三一條道路斷開(kāi)兩段時(shí)終點(diǎn)節(jié)點(diǎn) ID 和另一段的起點(diǎn)節(jié)點(diǎn) ID 不一致。解決在導(dǎo)入后的 Neo4j 里寫一次清洗腳本把坐標(biāo)距離小于五米的節(jié)點(diǎn)做合并。具體的條件是把兩個(gè)節(jié)點(diǎn)的經(jīng)緯度做差值小于閾值就用一個(gè)節(jié)點(diǎn)的 ID 統(tǒng)一替換掉關(guān)系里的引用。MATCH (a:RoadNode), (b:RoadNode) WHERE a.id b.id AND abs(a.lat - b.lat) 0.0001 AND abs(a.lon - b.lon) 0.0001 WITH a, b LIMIT 1000 MATCH (a)-[r:ROAD]-(n) MERGE (b)-[r2:ROAD {distance_m: r.distance_m}]-(n) DELETE r這種做法我先限制每批只處理 1000 條因?yàn)榇笈?MATCH 在 WHERE 條件里的計(jì)算開(kāi)銷非常大跑久了容易 OOM。跑一遍可以恢復(fù)大部分?jǐn)嗔淹負(fù)涞珪?huì)出現(xiàn)重復(fù)關(guān)系所以跑完之后還要加 DISTINCT 去重。5.3 Neo4j 沒(méi)按配置文件分配內(nèi)存查詢慢到像假死跑路由查詢時(shí)發(fā)現(xiàn)只要跳數(shù)超過(guò)十五次響應(yīng)時(shí)間從 50ms 暴漲到 10s一度以為是數(shù)據(jù)量問(wèn)題。后來(lái)發(fā)現(xiàn) Neo4j 默認(rèn)的內(nèi)存配置把堆內(nèi)存限制在 512MB。原因Neo4j 的neo4j.conf文件沒(méi)有修改默認(rèn)堆內(nèi)存只有幾百 MB圖遍歷是把節(jié)點(diǎn)加載到堆內(nèi)的內(nèi)存不夠自然開(kāi)始頻繁 GC哪怕數(shù)據(jù)量只有幾萬(wàn)條也卡。解決在neo4j.conf里修改以下配置。注意修改后必須重啟 Neo4j 服務(wù)。server.memory.heap.initial_size2g server.memory.heap.max_size2g server.memory.pagecache.size2g具體大小根據(jù)自己的機(jī)器來(lái)。我一般建議初始堆和最大堆設(shè)成一致避免運(yùn)行中堆自動(dòng)擴(kuò)容帶來(lái)的停頓。這兩項(xiàng)設(shè)成不同值時(shí)Neo4j 會(huì)頻繁執(zhí)行擴(kuò)縮容路由查詢的延遲曲線變得非常難看。5.4 關(guān)系方向設(shè)置錯(cuò)誤路線總讓你掉頭我在測(cè)試一個(gè)環(huán)形路網(wǎng)的導(dǎo)航時(shí)路線算法給出的路徑一直在原地打轉(zhuǎn)或者強(qiáng)制連續(xù)兩次 U 形彎。翻遍代碼最后發(fā)現(xiàn)是把雙向路段的兩個(gè)方向關(guān)系都建了但 oneway 判斷錯(cuò)誤把它當(dāng)成僅單向錄入。OSM 數(shù)據(jù)里oneway標(biāo)簽除了yes和no之外還有一種-1表示逆行車道即單向但方向與 Way 節(jié)點(diǎn)序列相反。我的解析器里一開(kāi)始只判斷了yes把-1當(dāng)成了雙向路段。解決方式很簡(jiǎn)單把 oneway -1 的情況在生成關(guān)系時(shí)交換 source 和 target再調(diào)整 distance_m 并寫回。if oneway -1: source, target target, source這種錯(cuò)誤不太容易靠日志發(fā)現(xiàn)因?yàn)閳D結(jié)構(gòu)上完全沒(méi)有異常但算出的路線就是不合理。所以我在每個(gè)路段關(guān)系上都加了一個(gè)direction屬性存儲(chǔ)車流方向后續(xù)查問(wèn)題時(shí)可以直接用WHERE r.direction backward做過(guò)濾便于排查。6. 進(jìn)階玩法給路由加上多約束條件與速度權(quán)重基礎(chǔ)的路由已經(jīng)能跑通但真實(shí)場(chǎng)景里還需要區(qū)分“最短距離”和“最快時(shí)間”。配送場(chǎng)景更關(guān)心時(shí)間自駕場(chǎng)景更關(guān)心是否走高速步行場(chǎng)景必須排除快速路。這些本質(zhì)是把單一的distance_m權(quán)重屬性變成多維屬性再在查詢時(shí)按場(chǎng)景切換權(quán)重字段。我在關(guān)系上額外保存了speed_kph屬性從 OSM 的maxspeed標(biāo)簽獲取如果沒(méi)有則按高速公路類型賦默認(rèn)值。然后程序里先計(jì)算cost_seconds distance_m / speed_kph * 3.6存成單獨(dú)屬性再用 APOC 的 dijkstra 函數(shù)換成cost_seconds做權(quán)重MATCH (a:RoadNode {id: 12345}), (b:RoadNode {id: 54321}) CALL apoc.algo.dijkstra(a, b, ROAD, cost_seconds) YIELD path, weight RETURN [r IN relationships(path) | r.road_name] AS roads, weight AS total_seconds做法說(shuō)起來(lái)很簡(jiǎn)單真正要踩的坑是maxspeed的解析。OSM 標(biāo)簽里maxspeed30表示限速 30 km/hmaxspeedwalk表示步行速度maxspeednone表示不限速。解析器里必須做一層歸一化否則字符串類型直接轉(zhuǎn) float 時(shí)會(huì)直接報(bào)錯(cuò)整條導(dǎo)入鏈路停掉。我還給自己的服務(wù)加過(guò)一個(gè)實(shí)用功能根據(jù)路由結(jié)果的起點(diǎn)和終點(diǎn)從路段的highway_type屬性過(guò)濾掉不適合當(dāng)前交通模式的關(guān)系類型。騎行時(shí)剔除 motorway步行時(shí)剔除 trunk。把a(bǔ)poc.algo.dijkstra里的關(guān)系類型參數(shù)從ROAD改成動(dòng)態(tài)拼接或直接在關(guān)系創(chuàng)建時(shí)打上access標(biāo)簽組合CALL apoc.algo.dijkstra(a, b, ROAD, cost_seconds) YIELD path, weightROAD的表示只沿關(guān)系方向正向遍歷。這一招對(duì)單行道的處理特別管用可以繞開(kāi)很多逆行的坑。整體把這套服務(wù)從原型到落地做下來(lái)我最深的感受是Neo4j 做路由的優(yōu)勢(shì)不在算法執(zhí)行速度而在工程速度。它讓路線計(jì)算和你原有的圖數(shù)據(jù)模型長(zhǎng)在一起不用在業(yè)務(wù)和非業(yè)務(wù)之間頻繁做語(yǔ)義轉(zhuǎn)譯。這是一個(gè)性價(jià)比很高的方案關(guān)鍵是把數(shù)據(jù)清洗和方向處理做扎實(shí)希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取