孫 健 李少彬
(南京公共交通(集團)有限公司,南京 210037)
合理科學的公交調度和線網規劃,可以緩解城市快速發展、人口激增、出行需求大幅度上升引起的交通擁擠、交通安全事故等普遍問題。而公交調度和線網規劃也依賴于對海量客流的全面、精準分析和統計。國內外研究學者通過運用海量IC卡數據,結合車輛GPS數據,對客流建立多維度數學模型,從客流OD、候車時長、客流擁堵等方面分析客流特征和規律。本文通過原始刷卡數據中已經提供的線路編碼、車輛編碼、刷卡經緯度、刷卡時間,結合車輛調度信息以及地理信息系統提供的線路下各站點經緯度信息,通過經緯度坐標投影算法以及車輛實時調度信息的查詢計算,得出精確的刷卡站點信息。同時利用redis數據庫內存高吞吐的特性,實時過濾清洗刷卡設備記錄到的重復刷卡數據。刷卡站點信息反映了各線路各站點客流量的高低,對整個公交線路的運營具有指導意義,對客流量擁擠地區的治安管理也具有一定的參考價值。
原始刷卡數據只包含了部分信息:
(1)車輛注冊線路編碼。線路編碼是市民卡中心對線路名稱的一種規范。同時,在本地數據庫維護一張線路編碼和線路名稱一一對應的映射關系表。
這樣做的好處在于:存儲線路編碼比存儲線路名稱更節約數據庫空間,而且查詢線路編碼比查詢線路名稱更快。
(2)車輛編碼。車輛編碼也是市民卡中心對車輛名稱的一種規范。
(3)刷卡經緯度、刷卡時間。這兩者分別記錄了刷卡所在的空間和時間上的信息。空間的信息可以用于計算線路上各個站點的距離,時間的信息可以用于查詢當前車輛所在的實時調度信息。
調度信息指的是車輛的進出站信息,包括:
(1)車輛實際運營線路編碼。車輛所在的運行線路編碼區別于原始刷卡數據中的注冊線路編碼,實際運營中,車輛可能會被臨時調度至其他線路運營。
本文計算中,刷卡數據屬于哪個線路、哪個站點以實際調度信息為準,可以精確反映公交車輛的實時運營情況。
(2)線路上下行。車輛在某條線路上運行,根據運行方向的不同,可以規定為上行和下行。
(3)站點信息。站點信息指的是該時刻車輛“進”或“出”的站點。
車輛實時調度信息緩存在redis數據庫,利用其內存高吞吐的特性,為原始刷卡數據實時計算刷卡站點提供了高性能的數據庫查詢條件。
地理信息系統為我們提供了精確的位置信息,為了計算方便,在mysql數據庫中維護了一張線路與站點的靜態信息表。包含了各線路下所有站點的經緯度信息、上下行信息、各站點上一個站點和下一個站點的信息,見表1樣例。

表1 線路經過的站點數據樣例
計算刷卡站點主要考慮兩種算法,分別為:
(1)坐標投影算法,基于刷卡經緯度和站點經緯度計算刷卡站點。
(2)調度信息計算刷卡站點,基于刷卡時間和車輛的進出站時間計算刷卡站點。
兩種算法各有優缺點,本文結合兩種算法,得到較為精準的刷卡站點。
原始刷卡數據記錄的是車輛注冊線路,因此需要通過車輛自編碼去redis或者mysql數據庫查詢車輛的進出站數據,進出站數據中記錄的才是車輛真正的運行線路。同時明確了上下行可以為第2步減少需要比對的站點,提高計算效率。
計算刷卡經緯度與所在線路上各站點經緯度的距離。距離最小的站點記為minStopCode。最小距離記為minDistance。計算距離涉及到兩個部分。
(1)經緯度轉換。地球表面是一個不規則的球面,為了便于說明,以下用一個橢圓繞軸旋轉形成的球面來表示:

式中,R為赤道半徑,r為極軸半徑。由于推算資料的不同,R和r的值會有些許差異,本文采用的是WGS-84橢球體[1,6],即R=6378137米,r=6356752.314米。考慮到計算距離時需要使用同一套坐標系,對線路下各站點的經緯度進行坐標系轉換。舉例說明:(118.484871, 32.043482)經緯度轉換后為(118.808118, 32.07247)。
(2)經緯度計算距離。影響兩點之間距離計算的兩個因素:
a.經度每度的距離,即弧長。緯度越小,弧長越大,反之,則越小。
b.緯度每度的距離大概是相等的,約為111000米。
計算某個緯度下經度平均每一度距離S[2-3]的公式如下:

式中,B為所在區域的緯度。
考慮到我們計算所在的目標區域緯度范圍為:北緯31°14′至32°37′。因此分別將這兩個緯度值代入公式(2),對兩個計算的結果取平均值,為97850.268米。用這個值進行兩個點之間距離的計算[4-5]。舉例說明:刷卡經緯度(118.778736,32.051028)和轉換后的站點經緯度(118.778835,32.051083)計算距離為11.2米。
如果minDistance≤50米,則取對應的站點作為刷卡站點。
如果minDistanc>50米,則說明刷卡點距離最近的站點都比較遠,不好判別刷卡站點。進行第3步。
存在以下兩種異常情況:
(1)原始刷卡數據無刷卡經緯度,這是由刷卡設備或者車輛GPS設備異常導致的。
(2)經緯度坐標投影算法計算的最近站點距離都大于50米,這可能是人為原因導致的。
上述兩種情況都會導致原始刷卡數據計算不到刷卡站點。因此需要通過刷卡時間和車輛的進出站信息去進一步尋找刷卡站點。通過調度信息尋找刷卡站點的依據可以概括為以下公式:

式中,adTime為車輛的進出站時間,swipeTime為刷卡時間。整個公式的含義是:取調度信息中該車輛的進出站時間小于刷卡時間,且是最大的一個進出站時間,所對應的站點作為刷卡站點。

圖1 刷卡站點計算流程圖
原始刷卡數據是通過activemq點對點的方式主動推送過來的,在進行站點計算之前我們首先借助redis數據庫內存高吞吐的特性,對實時過來的刷卡數據進行去重,清洗掉重復數據。如果刷卡時間早于當前系統時間20分鐘以上,則暫時放置在緩沖隊列,記為隊列3,新開一個線程基于歷史的進出站數據,采用車輛調度算法計算刷卡站點,否則刷卡數據暫時放置在另一個緩沖隊列,記為隊列1。新開一個線程,基于車輛實時進出站信息尋找運行線路和線路方向,同時采用坐標投影算法,計算刷卡站點,記為線程1。這樣設計的好處在于提高程序的計算性能,線程1中對于無經緯度和最小距離misDistance大于50米的刷卡數據,由于算法不一樣,暫時放置在一個新的緩沖隊列,記為隊列2。新開一個線程2處理隊列2中的刷卡數據,線程2只處理無經緯度和最小距離misDistance大于50米的刷卡數據,而這些數據依賴于車輛的調度信息,由于車輛調度信息是2分鐘從接口獲取一次,因此進出站數據可能存在延遲,此時隊列2就發揮它的作用了,對于這些不具備處理條件的刷卡數據(刷卡時間大于調度信息里面最大的進出站時間,代表進出站數據延遲),隊列2會暫時“保管”,直到延遲的進出站數據過來。這里需要考慮一個異常情況,比如說:進出站數據接口出問題了,就會出現進出站數據永遠延遲的情況。
此時隊列2的數據就會越積越多,嚴重消耗內存,最終影響程序的正常運行。因此,這里還有一個機制,就是每次對隊列2中刷卡時間距離當前系統時間超過20分鐘的刷卡數據進行批量處理,保證隊列2的數據大小不會無窮地增大。

表3 站點刷卡分析統計

表2 不同推送時間的站點刷卡分析
以2020-07-15一整天的刷卡數據進行分析,得出數據表2、表3。
通過表2可以看出,原始刷卡數據存在發送延遲的情況,但是數據量不大,僅占0.51%。后期也通過算法找到了部分刷卡數據對應的刷卡站點。但是原始刷卡數據的延遲對刷卡站點計算的準確性會一定的影響,尤其跟大屏展示站點實時刷卡數據量的理念是不符的。

圖2 線路分時段客流統計和各站點客流統計
通過表3可以看出,通過坐標投影算法無法判斷刷卡站點的數據(包括:無經緯度和misDistance>50米)大部分依然可以通過新的算法(根據刷卡時間和車輛調度信息判斷刷卡站點)找到對應的站點。
由于車輛進出站數據中站點和上下行的對應關系與各線路下各站點信息這個基礎表的對應關系不符。例如:在進出站數據中A站對應的方向是:上行,但是在基礎表中A站對應的方向是:下行。這種信息不符的情況導致了143條刷卡數據找不到刷卡站點。
總體匹配效果還是可以實際應用的,正常發送的刷卡數據中找不到站點的數據,僅占一天的3.63%。
圖2給出了6路兩個方向不同時段的客流數量,以及各站點所屬不同峰段的客流數量。不同時段的客流數量對于公交運營在不同時間段投入的人員部署具有參考意義,各站點所屬不同峰段的客流數量反映了客流分布的主要區域,對多熱點區域的治安和交通管理具有參考價值。本文基于時間和站點兩個維度的客流統計可以更精確更全面地反映公交乘客出行偏好規律。
本文利用GIS技術將線路站點客流量熱力圖層和地圖圖層疊加,通過熱力圖的方式展現了線路上各站點的客流分布情況。熱力圖支持分時段查詢,便于分析不同峰段的客流分布情況。圖3分別展示了南京市早晚高峰的客流分布特點,對于公交分時段運營部署的調整具有指導意義,更能滿足乘客的出行需求。

圖3 南京市高峰期客流熱力分布
(1)本文針對南京地區的公交刷卡數據,選取一組可以唯一標識一條刷卡數據的特征值,借助redis數據庫,利用其內存的高吞吐特性,在實時接收數據的同時,對重復的刷卡數據進行清洗。避免了由于刷卡設備故障而導致的重復統計問題。
(2)本文根據南京地區的實際地域特征和經緯度分布情況,基于GIS進行經緯度轉換和距離計算,找到了部分較為準確的刷卡站點。
(3)針對坐標投影算法中不可避免出現的問題:原始刷卡數據沒有經緯度。所謂“巧婦難為無米之炊”,缺少了經緯度這個必要條件,坐標投影算法失效。此時,車輛的調度信息就發揮作用了,結合刷卡數據本身包含的刷卡時間信息,依然可以判斷出刷卡站點。
(4)通過一天的刷卡數據分析,最終找不到刷卡站點的數據僅占3.63%。
(1)原始刷卡數據延遲對刷卡站點計算有一定的影響。本文的算法在實時計算方面準確性更高些,但對于延遲過來的數據,雖然絕大部分都能找到站點,但是準確性會受影響。
(2)進出站數據和各線路下各站點基礎信息的不一致性導致了少量數據算不到刷卡站點,這一點其實是可以避免的。