中國華錄杯之公交線路準點預測

 

 

 

 

按照慣例，給出我們組的最終成績0.03901和第一名成績0.03068

 

 

題目任務

公共交通綠色出行，是世界極力推行的策略。然而由于交通擁堵的原因，公交車經(jīng)常不能準時到站，要么長久不來，要么兩輛一起來。于是，是等公交車呢？還是不等公交車呢？我們可以通過實時的預測來解決這個問題。

公交線路準點預測賽題為參賽者提提供百余條公交車線路的運行信息，本賽題需要大家準確預測某一輛公交車是否能準時到達各個站點。

競賽提供了百余條公交線路長達一個月的運營信息，每條線路的每一輛公交車都會定時發(fā)送GPS信息，參賽者需要根據(jù)歷史信息訓練模型，根據(jù)GPS信息估計每輛公交車到站時間。具體來講，對于測試集中給到的每一條“待預測的公交車運行路線”，需要預測該輛公交車到達指定站點的時間。

數(shù)據(jù)

1. 數(shù)據(jù)總體

數(shù)據(jù)包含了天津市大約519條公交線路5716輛公交車的超過4億條GPS記錄，時間從2017年10月1日~10月31日。 用于比賽的數(shù)據(jù)被劃分為三個部分。

 

2. 訓練集的數(shù)據(jù)字段及樣例

訓練集包含了10月1日到10月24日之間的所有公交車輛的運行信息，包括線路id、公交車id、經(jīng)緯度、記錄時間、車輛運行狀態(tài)。 文件名為：201010xx.csv，其中xx為01, 02, 03,…, 24。

數(shù)據(jù)格式及樣例： O_LINENO,O_TERMINALNO,O_TIME,O_LONGITUDE,O_LATITUDE,O_SPEED,O_MIDDOOR,O_REARDOOR,O_FRONTDOOR,O_UP,O_RUN,O_NEXTSTATIONNO 671,911410,06:37:05,117.178,39.1618,0,1,0,0,0,0,2 671,911410,06:37:27,117.178,39.1618,0,1,0,0,0,0,2

字段解釋為：

O_LINENO           線路id            

O_TERMINALNO         公交車id

O_TIME                記錄時間        

O_LONGITUDE           經(jīng)度

O_LATITUDE         緯度              

O_SPEED                    瞬時速度

O_MIDDOOR        中門狀態(tài)      

O_REARDOOR           后門狀態(tài)

O_FRONTDOOR    前門狀態(tài)      

O_UP                        上行

O_RUN                  運行狀態(tài)      

O_NEXTSTATIONNO   下站編號

 

3. 測試集的數(shù)據(jù)字段及樣例

從10月25日～31日，我們共選取了6萬條線路。對于每條線路，我們給出了“日期，線路id，車輛id，開始預測時間，開始預測站點，結束預測站點上下行標記”。

文件名為：toBePredicted_forUser.csv

數(shù)據(jù)格式及樣例： O_DATA,O_LINENO,O_TERMINALNO,predHour,pred_start_stop_ID,pred_end_stop_ID,O_UP

10-25,1,902731,17:00:00,25,29,1

解釋后面三個字段：這條線路的predHour為17:00:00，是指在17:00:00時刻，車輛902731的下一站是pred_start_ID,即25；那么參賽者需要預測該車輛到達第25站、26站、27站、28站、29站的時間。 

 

4. 用于輔助估計“待預測線路”路況的數(shù)據(jù)

對應于待預測的線路，我們提供了每條線路之前一個小時的車輛信息，用于輔助估計路況。 數(shù)據(jù)格式同訓練集；但時間上與測試集無重合。

以3中的樣例進行說明。上例中，待遇測的線路是從17:00:00開始，那么，當天（即10-25）的16:00:00~16:59:59的所有公交車的信息都會給出，幫助了解當天的道路情況。

 

5. 其他數(shù)據(jù)使用

①可使用外部數(shù)據(jù)！但須滿足第2條！

②不能使用數(shù)據(jù)存在的漏洞！包括時間存在的漏洞，例如，假設被預測線路處于以下時間段2017年10月25日09:00:00～09:59:59，那么就不能使用2017年10月25日09:00:00以后的“任何事實數(shù)據(jù)”來預測此線路。

事實數(shù)據(jù)，是指真實記錄的數(shù)據(jù)，包括但不限于以下幾種數(shù)據(jù)：

（a）交通車輛的GPS記錄

（b）交通事故的真實記錄

（c）天氣情況的真實記錄（可采用“預報”的數(shù)據(jù)）

 

 

其他說明與數(shù)據(jù)清洗

數(shù)據(jù)集中清除了每天晚上23點到次日早上6點之間的數(shù)據(jù)。

判斷公交車是否到達車站使用且僅使用nextStation值的變化判斷。原因：假如同時考慮“nextStation變化”以及“瞬時速度為0”，那么有兩種情形。情形一，若公交車在車站停留時間超過10秒，那么gps記錄就一定會記錄到“瞬時速度為0”的情況，此時，判斷標準就是“速度為0”對應的時間。情形二，若某站無上下客，那么公交車為了遵守公交公司的約定，仍然會在公交站有停留，但時間很可能不足5秒，甚至速度為0的時間只是那么2秒鐘，那么這個“速度為0”但狀態(tài)被記錄下來的可能性就很小了，因為gps的發(fā)送時間間隔大多是10秒；此時，就無法采用“速度為0”來判斷。我們通過簡單統(tǒng)計，發(fā)現(xiàn)司機往往會提前按下“nextStation”的報站提醒（甚至是在紅綠燈路口就有可能按下報站提醒）————基于此，情形一和情形二的差異可（qi）能（shi）很大。

同理，若同時考慮車門開啟與否，也會遇到情形一與情形二，即“車門打開的狀態(tài)“可能并不能被捕捉到。

基于以上情形，如果強行考慮這些情況，是不容易有統(tǒng)一標準的。

為什么不用GPS呢？我們通過統(tǒng)計發(fā)現(xiàn)，GPS信息并不那么精確，比如有些離群點會定位到河里面，有些會到公園里面；若是通過GPS來判斷是否到站，標準會更加復雜。

因此，僅根據(jù)“nextStation變化”來確定是否到站，既簡單又不會有歧義。（當然，需要排除掉“連續(xù)按到站鍵”和“忘記按到站鍵”的情況啦）。（數(shù)據(jù)中已刪除連續(xù)按到站鍵的情況，但是保留有GPS信號丟失導致經(jīng)緯度為0,0這種情況）

 

數(shù)據(jù)預處理

官方提供的數(shù)據(jù)為

 

訓練數(shù)據(jù)解壓出來是

 

其中csv打開后是

 

 

既然是數(shù)據(jù)預處理，就不得不談使用的算法，要確定算法就不得不從問題入手。

嗨呀，我就直說了吧。這個任務是給出某趟公交的某站到達時間，所以不同線路之間的影響可以忽略，數(shù)據(jù)預處理時候就把線路分開。就像這樣（文件名是線路號O_LINENO）

 

算法

團隊使用了常見幾種算法進行比較，統(tǒng)計、聚類、神經(jīng)網(wǎng)絡、協(xié)同過濾推薦等?，F(xiàn)在大致講一下每種算法是怎么應用的：

統(tǒng)計，這是第一個進行嘗試的算法也是最終提交版本的基礎。不考慮此趟公交此站前的運行情況，僅考慮此趟公交此站的歷史數(shù)據(jù)，求取平均值、中位數(shù)、眾數(shù)。比較之后選擇結果較好的一個時間作為此趟公交從上站到此站的需要（預測）的時間。從直觀上來講這樣預測很不負責，因為缺乏了此趟公交的自己的運行情況。但是從大數(shù)據(jù)的結果上來看結果較好，因為大多數(shù)實際情況都沒有異常，“每天都是平凡的過”。

聚類，這是為了解決統(tǒng)計中絲毫不考慮此趟公交的運行情況問題。主要做法是將此趟公交的歷史數(shù)據(jù)進行聚類，根據(jù)預測的這趟公交最接近于歷史上哪類聚類中心，就按照那一類進行預測。這樣的好處是如果晴天公交運行和雨天的運行情況是兩種截然不同的情況，那么就會被聚類成不同類，這樣在預測時候就會根據(jù)要預測的這趟公交在要預測的站點之前的站點情況來判斷他是在晴天還是雨天運行的。本來這個算法作為統(tǒng)計的算法改良。但是實際情況并不好，尤其是需要預測的站點離出發(fā)站點比較近，也就意味著系統(tǒng)在需要預測的站點之前并不能確定這趟公交是在天晴還是下雨運行的，一旦聚類中心確定錯誤，其帶來的誤差也較大。從最后的結果上來看有些預測更準確了，有些預測偏差更大了，綜合比較不如直接統(tǒng)計。

神經(jīng)網(wǎng)絡，通過某條線路的歷史數(shù)據(jù)進行訓練，使用前3站的數(shù)據(jù)預測后一站的所用時間。且不說如果需要預測的站點是出發(fā)站的三站內(nèi)怎么辦，就是后面能夠正常預測的站點，網(wǎng)絡也沒有學習出來一個較好的結果。猜測可能是網(wǎng)絡對于公交車門的開關和車速等數(shù)據(jù)沒有理解吧，我也不清楚。

推薦算法，根據(jù)公交車前幾站所花費的時間“預測并推薦”他接下來的一站所花費的時間。雖然算法不同但是這個和聚類的算法對數(shù)據(jù)的操作很像，只是尋找聚類中心的計算方式不同。結果稍有不同，相同的是一樣的差勁。

 

轉了一圈又回到了熟悉的統(tǒng)計。對于數(shù)據(jù)分類細致程度影響了最后的結果，但是細分過頭又會因為數(shù)據(jù)不足或者其他原因導致結果變差。沒有具體記錄，大致的誤差隨細分程度的曲線是v型。

 

回頭總結一下：數(shù)據(jù)雖然很多了，但是還是有限。在使用一些方法時候數(shù)據(jù)缺失和不準確的問題嚴重。最致命的是丟失GPS數(shù)據(jù)后GPS返回0,0，但是算法沒有分別0,0是缺失還是真的公交車瞬移到了經(jīng)緯度0,0的地方。而且觀察數(shù)據(jù)后發(fā)現(xiàn)，有些線路的公交車上傳數(shù)據(jù)比較完整，有些線路的公交車就會誤差比較大（導致GPS數(shù)據(jù)幾乎無法使用），有些時候數(shù)據(jù)會丟失（有時候兩站之間有50個點，有時候只有40個點）。（也有可能不是丟失，是司機開快了~）

總結

本次大數(shù)據(jù)其實還不算很大，雖然之前寫算法都是所有數(shù)據(jù)讀取到內(nèi)存之后再處理在這個項目上行不通了，但是在數(shù)據(jù)細分之后，每類數(shù)據(jù)還都可以這樣都放到內(nèi)存中處理。

主辦方?jīng)]有要求使用的算法工具和語言，依舊覺得自己即使是在使用工具方面依然退步明顯。想一想自己從手寫算法到現(xiàn)在用工具都吃力也是蠻悲傷的。有時間會多玩玩工具的。

 

競賽的任務難度有高有低，同樣的是時間限制和沒有更多的精力。而且感覺做事不細致不規(guī)范，可能賽事方也只是想要一個粗略的結果吧。本次競賽我只是蜻蜓點水式的參與，希望有機會能夠有更好的成績。