可視化與公共交通的那些事（1）：我的車到哪兒了？
本文作者
不知每天搭乘地鐵或輕軌的你們，有多少人有過這樣的經歷：
電子站牌上說好還有2分鐘到站的車，過了20分鐘都還見影子。
或者，坐的車停停走走，有時甚至直接在半路停個10分鐘，上下不能。
抑或，車突然停了，乘務員廣播說請大家耐心等待，自己被困在車廂裡一臉懵逼，不明覺厲。
如果沒有過，那你真是很幸運。
如果有過，那你也很幸運，因為相比之下，在地球另一邊的美國波士頓人們更是生活在水生火熱之中。
在美國波士頓，有一條歷史悠久的地鐵線 — — 綠線（Green Line）。這條地鐵古老破舊卻運營至今，有一半的路程都在地面，和公交車並行，和行人賽跑。故障卡殼也是家常便飯。升級地鐵系統耗資巨大，美帝有錢也不能任性。於是，位於波士頓的馬薩諸塞州交通局（Massachusetts Bay Transportation Authority，下稱MBTA）開始思考如何改善這個問題。最後，在2017年夏天，有了一個一兩撥千金的解決方案 — — 針對調度員的可視化工具。
1.表面的和平 v.s. 懵逼的現場
在那山的這邊海的那邊有一群調度員，他們勤奮又苦逼，忙碌又懵逼。因為他們運營著波士頓地鐵綠線。不管今天地鐵有沒有晚點，他們都一刻不能放鬆。
2017年夏天，我正以可視化助理的身份在MBTA工作。 MBTA 位於波士頓，管理著美國麻省所有的地鐵和公交。但其公共交通之發達在美國算是數一數二。截止到2017年，除了渡船和其它特殊服務線路外，共有8362個站點、8條地鐵線和192條公交線路，每日平均至少4萬搭乘人次。
工作期間，我設計和前端開發了數個可視化工具，用於解決公共交通運營和規劃人員們實際工作中的問題，目前皆已在實際使用中。其中，地鐵綠線的可視化工具項目最令我感觸深刻。
因為，我們常常覺得，地鐵準時準點是理所應當，反之則埋怨不已。我們卻沒看到，準時準點這種表面的光鮮背後，有多少不為人知的心酸。畢竟在地鐵沒有準時出現在站台的第一瞬間，調度運營人員同樣很懵逼，還必須盡快弄清狀況並處理。甚至，他們的懵逼比你早，也許你所在的這個站台是風平浪靜，而前面的站台早已堵成一鍋粥。
為了解決懵逼這個問題，我們為地鐵綠線的現場調度員開發了一個移動端可視化工具 — — 綠線地鐵可視化工具（Green Line Headway Viewer）。
其實這裡的懵逼有兩個階段。第一個階段是當下不知道發生了什麼，比如，哪輛車堵上了？影響到哪些站？第二個階段是，弄清情況後怎麼處理，怎樣指揮。
我們做的這個綠線地鐵可視化工具，直接解決的第一階段的懵逼，讓調度員看到整個線路上的車的行駛情況。但這個工具通過實時地提供信息，其實也間接輔助了第二個階段。
因為一輛車的延誤可能是多因素決定的。前一輛車的延誤、前一站的車輛滯留、堵車等，都可能導致當前這一輛車無法準點。對於調度員來說，從指揮和成效這一過程實則是一個黑箱：我的準點發車並不能保證這輛車準點到站；我的準點發車可能導致下一站點車輛堵塞；我推遲發車可能減緩下一站車輛滯留的情況。只有調度員能夠獲取到自己調度操作的結果反饋，他才能學習和改進調度技能。
2.可視化如何一兩撥千金
那麼問題來了，這個綠線可視化工具是什麼樣的一個工具，是怎麼設計的，又是怎樣來解決問題的呢？
首先，讓我們走近綠線，看看綠線的準點問題背後，究竟是管理的扭曲還是科技的淪喪。
綠線是波士頓最早的地鐵線路，準確說應該是輕軌。部分路段與其它車輛混行，有時因為沒有專門的站台，乘客還需要在馬路中間上下車。
據說建成於1897年，說得好聽點叫很有歷史感，但其實就是很老舊，每次起步和進站都是一陣巨響，比十年前國內的火車噪音還大。我們有個老教授曾調侃說，綠線每次進站這一連貫的“吱”聲，都可以用來做“可聲化”（sonification）了，看看能從中獲得什麼洞見。
每年冬天， 因為鏟雪工程巨大，很多路段的地鐵運營服務慘不忍睹，MBTA也會暫停部分地鐵服務。看看網友的推特吐槽就知道了。
波士頓的綠線有B、C、D、E共4條支路，四條支路有兩個合併點，每條支路又有不同的終點。抵達終點的車輛會在終點掉頭，併入到另一個方向繼續運行。相對於其他地鐵線路，支路的分分合合直接讓綠線的運營上升到了困難模式。
除了幾個大的終點站有臨時的迷你調度室，裡面配備了電腦。在其他的站台，乘客來來去去，而現場調度員只有途徑的地鐵司機，和一個對講機。
然後實際上，幾乎每輛車上都有定位系統（GPS），幾乎主要的軌道上都安裝了傳感器（sensors）和自動車輛識別設備（AVI，Automatic Vehicle Identification）。並且，MBTA不僅有完整的車輛實時數據、站台和時刻數據等，還有很標準化的GTFS數據（General Transit Feed Specification）和實時API。這些數據資源不僅是更新迭代中的，更是對外開放的資源。
綠線可視化工具就是利用這些現成的數據資源，以可視化的方式為調度員提供必要的信息，從而填補管理不足和數據有餘的鴻溝。
首先，我們對現場調度員的工作流程做了梳理，以了解他們的使用場景和痛點。簡單來說，現場調度員的主要工作是評估每輛途徑車輛是否能準時從當前站台發車。如果不能，則需要做出臨時調整，並將新的發車時間告知司機和調度中心。同時，作為績效考核的一部分，他們還需要手工填寫實際發車時間表。
在使用我的工具之前，一旦有車輛未及時到站，或感受到任何異常，他們只能用對講機反反复復向其他調度員或司機詢問，然後自己在腦子裡整理和分析，再根據感覺和經驗做臨時決策。
據此，我們梳理出他們最關心的信息。對於站台A的調度員，他最關心的是抵達站台A的3輛車，包括是車輛編號、車當前的位置和計劃抵達時間。
結果，在給調度組展示這個初始版本後，調度組長樂不釋手，強烈要求我們能增加其他站台，讓所有現場調度員都能用上。對此，我們再次訪談了現場調度員。
訪談後我們發現，除了增加站台切換和支路切換的功能外，4條支路共同運行的路段也是他們會特殊關注的信息。一方面，這個調度員所在的站台，可能只是B支路的站台，也可能是四條支路同時運行的站台；另一方面，即便這個調度員不在4條支路混合的站台，由於這部分混合路段常常是延誤的製造廠，他們仍然會特別去關注這部分路段運行的情況。
所以，在設計上，我分別提供了B、C、D、E四條支路和共同路段的信息視角。共同路段的支路取名叫subway （地鐵） — — 雖然聽起來很怪，因為地鐵不是只有綠線啊，但這是調度員們強烈推薦的命名。他們開心就好。
另外，為了讓用戶快速辨別車輛屬於哪條支路（B、C、D、E），我不僅用了不同的圖標，也用了不同的顏色來表示車輛。在顏色的選擇上，主要是採納了調度系統原來使用的4個顏色。一開始，我們團隊都是拒絕的。因為紅、綠、黃、藍來表示B、C、D、E實在有些莫名其妙，並且波士頓的地鐵線本來就還有紅線、橙線、藍線。但是最後我們妥協了，理由是，這些調度員紛紛表示他們習慣了這個顏色編碼。再者，我們也發現綠線的調度運營與其他地鐵相對孤立，也不存在混淆的問題。
除了增加支路外，我們還增加了每個站台的視角。儘管不是每個站台都有調度員，但每個調度員都可以點擊選擇任何站台，以獲取該站台計劃抵達的車輛編號和時間。
最後，是解決一個設備問題。因為配備電腦成本高，也因為現場的靈活性，綠線可視化工具是一個基於移動端的網頁工具。由此，MBTA只需要給現場調度員配備一台平板，或他們自己也可以通過自己的手機瀏覽器訪問。
3.一個專業可視化工具的修養
因為我每天要乘坐綠線，所以得天獨厚，每次出門前都會看看車什麼時候到家門口的站台。畢竟，在波士頓的寒冬等車，實在是太具體。把握好時間剛剛好到站台上車，實在是太剛需。當然，市面上也不乏針對乘客的App，比如Google、Transit，能告知哪個線路的車還有多久到站、車目前走到哪兒了等信息。甚至，MBTA自己也有一個網頁版本。
那麼問題又來了，為什麼綠線調度員沒有使用這些大眾App？原因很簡單。
其一，大眾App沒有提供他們最需要的信息，即車輛編號。乘客不關心車輛編號，只關心是多少路的車。但調度必須要知道編號，來對應具體的車輛和司機。另外，在時間上，調度管理需要精確到秒，比如12:23:23抵達，而通常大眾App只提供到分鐘。
其二，大眾App提供了太多他們不需要的信息。比如，對於地鐵和公交混合站，大眾App通常也會提供公交線路的信息，而這些對於綠線調度來說，完全是信息噪音。
4.最後
其實綠線可視化工具是一個顯而易見的需求。但因為經費有限等各種原因，一直沒有得到重視。直到我完成這個工具的設計和開發，以實驗性項目的名義，項目組長爭取到經費給調度員配備了幾個平板。
項目結束後的某一天，看到組長給我留的紙條：
在短短半個月的試用之後，因為調度組的反饋非常好，MBTA正式成立了一個產品專項組負責針對綠線調度的產品研發。
在綠線可視化工具案例分享會議後，公交調度部門也表示很有興趣，希望能有一個類似的工具能實時查看擁堵路況。於是便有了公交路況可視化工具。
關於公交路口可視化工具，敬請期待 — — 可視化與公共交通的那些事（2）：堵車了麼？
