編程對我來說有一種獨特的吸引力，享受著用代碼將自己的想法一步步實現(xiàn)這個過程，付出的代價就是犧牲掉不少空閑時間。當(dāng)其他人吃著火鍋唱著歌的時候，我可能正默默的對著電腦屏幕發(fā)呆或敲著一行行代碼。
本科和研究生階段的研究方向都是交通信息與控制，閑來無事的時候喜歡搗鼓搗鼓軟件，先后接觸了vissim、synchro、sidra、visum、TC等。這些軟件功能涉及面廣，在行業(yè)各領(lǐng)域被廣泛應(yīng)用。但是在應(yīng)用過程中，驚覺大多微觀交通軟件的開發(fā)是以國外的交通情況為背景，針對國內(nèi)實際交通情況應(yīng)用并不能完全協(xié)同。但若對模型參數(shù)進(jìn)行校正則可以在國內(nèi)交通情境中較好地應(yīng)用，上述軟件在國內(nèi)有較高的占有率也說明了這一點。不過國內(nèi)實際交通情況及其復(fù)雜，用戶的操作習(xí)慣也存在差異，這些軟件還是有一些不太適應(yīng)的地方，某些情境下無法解決用戶的實際痛點。以常用的synchro和sidra兩款交叉口軟件為例，總結(jié)起來主要有以下幾方面：
圖一、左側(cè)為synchro、右側(cè)為sidra渠化示意圖
上圖為兩款軟件的渠化示意圖：其箭頭標(biāo)志大小、類型，人行橫道線，整體的渠化示意圖風(fēng)格與國標(biāo)《道路交通標(biāo)志和標(biāo)線（GB5768-2009）》存在較大的差異。除此之外，上述兩款軟件渠化示意圖也無法對實際交叉口中的左轉(zhuǎn)待轉(zhuǎn)區(qū)、直行待轉(zhuǎn)區(qū)、可變車道、公交專用道，導(dǎo)流線渠化島等進(jìn)行處理。
圖二、國標(biāo)GB5768-2009左轉(zhuǎn)待轉(zhuǎn)區(qū)示意圖
圖三、TC繪制的交叉口流量圖
synchro和sidra更加注重的是數(shù)據(jù)評價分析，還很難滿足實際項目報告對圖形化結(jié)果的需求，需要借助于其他的軟件來實現(xiàn)，并且實現(xiàn)過程相對繁瑣。
開發(fā)的第一個功能模塊是繪制交叉口流量圖。一圖勝千字，在報告中用交叉口流量圖來表示各個轉(zhuǎn)向之間的交通需求比使用表格和文字要直觀明了。在此之前交叉口流量圖主要采用TC、CAD和PPT繪制：TC繪制流量轉(zhuǎn)向圖步驟較為繁瑣，且無法處理掉頭流量；CAD主要適用于十字交叉口流量繪制，難以直觀展現(xiàn)各個方向交通需求大??；PPT是手動繪制各個線條，比較耗時。
圖四、左側(cè)為CAD繪制、右側(cè)為PPT繪制的流量圖
流量圖也是整個信號交叉口軟件相對容易實現(xiàn)的功能，以流量圖作為開發(fā)的第一個模塊功能，目的就是先找個軟柿子捏捏，作為編程學(xué)習(xí)的練習(xí)項目，這個階段利用C#的GDI進(jìn)行繪圖。原本以為畫幾條粗細(xì)不一的線上去，再添加上流量標(biāo)簽就能搞定的事情，卻比想象的要麻煩得多。實際交叉口的復(fù)雜程度遠(yuǎn)超想象：每條線條的起始點位置、寬度、曲率、與輸入流量之間的關(guān)系等問題都需要解決；點位計算結(jié)果不穩(wěn)定，一個點位的偏差就會造成整個繪制出錯；編程水平太low：程序漏洞百出，經(jīng)常出現(xiàn)各種始料未及的麻煩。
圖五、桌面端交叉口流量圖計算不穩(wěn)定
這個階段，不斷驗算點位計算公式，調(diào)試代碼存在的問題，筆記本上的筆記也越來越多。
圖六、雜亂的筆記
經(jīng)過了挺長一段時間的優(yōu)化完善，盡管仍然偶爾出現(xiàn)不穩(wěn)定的狀況，桌面端的交叉口流量圖應(yīng)用已經(jīng)可以逐漸可以在一些實際項目中運用了。
圖七、桌面版的交叉口流量圖軟件
經(jīng)過一段時間的試用體驗后，我發(fā)現(xiàn)桌面端的交叉口流量圖應(yīng)用在實際使用中還是存在著問題，即無法在xp、macOS和其它部分操作系統(tǒng)中正常使用。那時候web端在線應(yīng)用逐漸增多，web應(yīng)用優(yōu)點是運行在瀏覽器環(huán)境中，打破了操作系統(tǒng)之間的限制，能夠更靈活地適應(yīng)用戶需求。參考了html5中的canvas繪圖功能，決定嘗試開發(fā)web端的交叉口流量圖應(yīng)用。
經(jīng)過一段時間的試用體驗后，我發(fā)現(xiàn)桌面端的交叉口流量圖應(yīng)用在實際使用中還是存在著問題，即無法在xp、macOS和其它部分操作系統(tǒng)中正常使用。那時候web端在線應(yīng)用逐漸增多，web應(yīng)用優(yōu)點是運行在瀏覽器環(huán)境中，打破了操作系統(tǒng)之間的限制，能夠更靈活地適應(yīng)用戶需求。參考了html5中的canvas繪圖功能，決定嘗試開發(fā)web端的交叉口流量圖應(yīng)用。
由于之前沒有接觸過html5、css、js等，所以又開始一邊學(xué)習(xí)，一邊開發(fā)。web端應(yīng)用分為前端和后端：前端canvas負(fù)責(zé)繪圖，后端負(fù)責(zé)點位計算等。前端頁面布局設(shè)計內(nèi)容相對較少，主要通過html和css完成；前端繪圖功能利用js控制canvas進(jìn)行繪圖完成，這個過程就是將之前在桌面端的核心代碼用js實現(xiàn)了一遍。由于是第一次使用js語言來寫應(yīng)用，其整體語言風(fēng)格跟C#存在較大差異，剛開始難以適應(yīng)，編碼質(zhì)量也很差，開發(fā)進(jìn)度緩慢。
圖八、js繪圖功能開發(fā)
盡管進(jìn)展緩慢，有了桌面端的開發(fā)經(jīng)驗，前端繪圖功能總體進(jìn)展還算順利，終究還是將桌面端繪圖功能用js語言實現(xiàn)了。
Web端交叉口流量圖功能開發(fā)的難點在于后臺功能的開發(fā)，之前完全沒有接觸過后臺開發(fā)，也不知道使用什么后臺語言，經(jīng)過一番對比，在php、java、Python和nodejs中最后選用了nodejs作為后臺開發(fā)工具，選擇nodejs最重要的原因是后臺也可以用js實現(xiàn)，不用再去研究新的語言，開發(fā)速度會快一些。
選定nodejs作為后臺開發(fā)后，緊接著就是學(xué)習(xí)nodejs的相關(guān)內(nèi)容，感謝這個偉大的互聯(lián)網(wǎng)時代，獲取學(xué)習(xí)資料的難度比我想象中要小得多，一番學(xué)習(xí)之后搭建起了初步了web端交叉口流量圖框架。Web端開發(fā)的最后一個難點就是將應(yīng)用部署到服務(wù)器上，跟著網(wǎng)上的攻略買服務(wù)器、買域名、學(xué)習(xí)基本的linux系統(tǒng)操作命令，一切就緒之后，web端的交叉口流量圖應(yīng)用終于可以正式運行。
圖九、web端交叉口流量圖初始上線界面
盡管現(xiàn)在回過頭來看界面設(shè)計簡直慘不忍睹，當(dāng)時完成上線后能正常訪問心里還是有些小激動的。
Web端交叉口流量圖應(yīng)用上線后，便開始準(zhǔn)備開發(fā)交叉口渠化示意圖功能。為了使得渠化示意圖能最大程度的貼合實際交叉口，我重點參考了國標(biāo)中關(guān)于交叉口標(biāo)線相關(guān)的規(guī)范，借鑒了國標(biāo)中交叉口示意圖的繪圖風(fēng)格，并以此作為渠化示意圖繪制的基本風(fēng)格，功能上能夠?qū)崿F(xiàn)處理左轉(zhuǎn)待轉(zhuǎn)區(qū)、直行待轉(zhuǎn)區(qū)、可變車道、公交專用道，右轉(zhuǎn)渠化島等。
交叉口渠化示意圖開發(fā)中，需要計算的點位數(shù)遠(yuǎn)多于交叉口流量轉(zhuǎn)向圖，對點位計算的精度要求也更高，所以整體開發(fā)難度更大，加之期間有其他事情耽擱，開發(fā)周期相當(dāng)漫長，交叉口渠化示意圖最后上線測試也比預(yù)期推遲了很長一段時間。
圖十、web端交叉口渠化示意圖初始上線界面
上線測試一段時間后，根據(jù)大家的反饋，部分交叉口左轉(zhuǎn)或者掉頭半徑不足時左轉(zhuǎn)或掉頭車道會被設(shè)置在進(jìn)口道外側(cè)。因此又增加了車道調(diào)整功能，通過點擊箭頭標(biāo)志更換箭頭類型，使其更加適應(yīng)實際交叉口情況。
圖十一、箭頭調(diào)整功能
要構(gòu)成一個完整的信號交叉口設(shè)計評價分析應(yīng)用，有了交叉口流量圖和渠化示意圖模塊后，還缺少信號方案設(shè)計和評價分析模塊。將已有的流量圖和渠化示意圖模塊組合到一起搭建初步的交叉口應(yīng)用框架。首先需要解決的問題是應(yīng)用界面設(shè)計，流量圖和渠化示意圖界面看起來嚴(yán)重缺乏設(shè)計感，也不太滿足軟件交互需求。為此學(xué)習(xí)了一段時間界面設(shè)計，參考其他一些在線應(yīng)用的界面設(shè)計風(fēng)格，在AI中繪制了初始版本的界面。
圖十二、應(yīng)用界面設(shè)計
交叉口信號方案一般由相位相序圖和相位配時圖組成，考慮了非機(jī)動車相位、行人相位、搭接相位、待轉(zhuǎn)相位等開發(fā)了信號方案設(shè)計模塊。
圖十三、信號方案設(shè)計
完成信號方案設(shè)計模塊后，開始開發(fā)評價分析功能。根據(jù)交叉口評價分析的實際需求，選擇交叉口飽和度、延誤、排隊長度和服務(wù)水平作為評價分析指標(biāo)，基于HCM2000手冊中評價分析模型進(jìn)行計算。結(jié)合項目報告中對評價分析結(jié)果圖形化的需求，四個指標(biāo)的評價結(jié)果均采用了圖形化展示效果。
圖十四、飽和度評價分析
圖十五、延誤評價分析結(jié)果
圖十六、排隊長度評價分析結(jié)果
圖十七、服務(wù)水平評價分析結(jié)果
考慮到實際應(yīng)用中對交叉口評價分析大多數(shù)需要對早高峰、平峰、晚高峰等情況進(jìn)行評價分析，或者某個交叉口改造中不同方案的對比，交叉口應(yīng)用支持對渠化、流量、信號等進(jìn)行多方案設(shè)計，并可以在評價結(jié)果中直接對比分析不同方案，也支持將評價分析結(jié)果導(dǎo)出到excel中進(jìn)一步處理分析。
圖十八、多方案評價結(jié)果對比分析
從萌發(fā)開發(fā)信號交叉口評價分析應(yīng)用的想法到最后上線測試足足經(jīng)歷了三年多時間，從大四到研三，把一個簡單的想法一步步實現(xiàn)，整個過程既充滿挑戰(zhàn)也收獲不少。特別希望在校學(xué)習(xí)的小伙伴若有想法，就盡最大努力去實現(xiàn)，感謝這個偉大的互聯(lián)網(wǎng)時代，有海量的學(xué)習(xí)資料供我們參考，真正阻礙前進(jìn)的或許不再是專業(yè)技能、不是編程、不是某一個軟件工具，而是你勇往直前的決心和愿意背后付出的努力。
