編程對我來說有一種獨特的吸引力，享受著用代碼將自己的想法一步步實現這個過程，付出的代價就是犧牲掉不少空閑時間。當其他人吃著火鍋唱著歌的時候，我可能正默默的對著電腦屏幕發呆或敲著一行行代碼。

本科和研究生階段的研究方向都是交通信息與控制，閑來無事的時候喜歡搗鼓搗鼓軟件，先后接觸了vissim、synchro、sidra、visum、TC等。這些軟件功能涉及面廣，在行業各領域被廣泛應用。但是在應用過程中，驚覺大多微觀交通軟件的開發是以國外的交通情況為背景，針對國內實際交通情況應用并不能完全協同。但若對模型參數進行校正則可以在國內交通情境中較好地應用，上述軟件在國內有較高的占有率也說明了這一點。不過國內實際交通情況及其復雜，用戶的操作習慣也存在差異，這些軟件還是有一些不太適應的地方，某些情境下無法解決用戶的實際痛點。以常用的synchro和sidra兩款交叉口軟件為例，總結起來主要有以下幾方面：

圖一、左側為synchro、右側為sidra渠化示意圖

上圖為兩款軟件的渠化示意圖：其箭頭標志大小、類型，人行橫道線，整體的渠化示意圖風格與國標《道路交通標志和標線（GB5768-2009）》存在較大的差異。除此之外，上述兩款軟件渠化示意圖也無法對實際交叉口中的左轉待轉區、直行待轉區、可變車道、公交專用道，導流線渠化島等進行處理。

圖二、國標GB5768-2009左轉待轉區示意圖

圖三、TC繪制的交叉口流量圖

synchro和sidra更加注重的是數據評價分析，還很難滿足實際項目報告對圖形化結果的需求，需要借助于其他的軟件來實現，并且實現過程相對繁瑣。

開發的第一個功能模塊是繪制交叉口流量圖。一圖勝千字，在報告中用交叉口流量圖來表示各個轉向之間的交通需求比使用表格和文字要直觀明了。在此之前交叉口流量圖主要采用TC、CAD和PPT繪制：TC繪制流量轉向圖步驟較為繁瑣，且無法處理掉頭流量；CAD主要適用于十字交叉口流量繪制，難以直觀展現各個方向交通需求大??；PPT是手動繪制各個線條，比較耗時。

圖四、左側為CAD繪制、右側為PPT繪制的流量圖

流量圖也是整個信號交叉口軟件相對容易實現的功能，以流量圖作為開發的第一個模塊功能，目的就是先找個軟柿子捏捏，作為編程學習的練習項目，這個階段利用C#的GDI進行繪圖。原本以為畫幾條粗細不一的線上去，再添加上流量標簽就能搞定的事情，卻比想象的要麻煩得多。實際交叉口的復雜程度遠超想象：每條線條的起始點位置、寬度、曲率、與輸入流量之間的關系等問題都需要解決；點位計算結果不穩定，一個點位的偏差就會造成整個繪制出錯；編程水平太low：程序漏洞百出，經常出現各種始料未及的麻煩。

圖五、桌面端交叉口流量圖計算不穩定

這個階段，不斷驗算點位計算公式，調試代碼存在的問題，筆記本上的筆記也越來越多。

圖六、雜亂的筆記

經過了挺長一段時間的優化完善，盡管仍然偶爾出現不穩定的狀況，桌面端的交叉口流量圖應用已經可以逐漸可以在一些實際項目中運用了。

圖七、桌面版的交叉口流量圖軟件

經過一段時間的試用體驗后，我發現桌面端的交叉口流量圖應用在實際使用中還是存在著問題，即無法在xp、macOS和其它部分操作系統中正常使用。那時候web端在線應用逐漸增多，web應用優點是運行在瀏覽器環境中，打破了操作系統之間的限制，能夠更靈活地適應用戶需求。參考了html5中的canvas繪圖功能，決定嘗試開發web端的交叉口流量圖應用。

由于之前沒有接觸過html5、css、js等，所以又開始一邊學習，一邊開發。web端應用分為前端和后端：前端canvas負責繪圖，后端負責點位計算等。前端頁面布局設計內容相對較少，主要通過html和css完成；前端繪圖功能利用js控制canvas進行繪圖完成，這個過程就是將之前在桌面端的核心代碼用js實現了一遍。由于是第一次使用js語言來寫應用，其整體語言風格跟C#存在較大差異，剛開始難以適應，編碼質量也很差，開發進度緩慢。

圖八、js繪圖功能開發

盡管進展緩慢，有了桌面端的開發經驗，前端繪圖功能總體進展還算順利，終究還是將桌面端繪圖功能用js語言實現了。

Web端交叉口流量圖功能開發的難點在于后臺功能的開發，之前完全沒有接觸過后臺開發，也不知道使用什么后臺語言，經過一番對比，在php、java、Python和nodejs中最后選用了nodejs作為后臺開發工具，選擇nodejs最重要的原因是后臺也可以用js實現，不用再去研究新的語言，開發速度會快一些。

選定nodejs作為后臺開發后，緊接著就是學習nodejs的相關內容，感謝這個偉大的互聯網時代，獲取學習資料的難度比我想象中要小得多，一番學習之后搭建起了初步了web端交叉口流量圖框架。Web端開發的最后一個難點就是將應用部署到服務器上，跟著網上的攻略買服務器、買域名、學習基本的linux系統操作命令，一切就緒之后，web端的交叉口流量圖應用終于可以正式運行。

圖九、web端交叉口流量圖初始上線界面

盡管現在回過頭來看界面設計簡直慘不忍睹，當時完成上線后能正常訪問心里還是有些小激動的。

Web端交叉口流量圖應用上線后，便開始準備開發交叉口渠化示意圖功能。為了使得渠化示意圖能最大程度的貼合實際交叉口，我重點參考了國標中關于交叉口標線相關的規范，借鑒了國標中交叉口示意圖的繪圖風格，并以此作為渠化示意圖繪制的基本風格，功能上能夠實現處理左轉待轉區、直行待轉區、可變車道、公交專用道，右轉渠化島等。

交叉口渠化示意圖開發中，需要計算的點位數遠多于交叉口流量轉向圖，對點位計算的精度要求也更高，所以整體開發難度更大，加之期間有其他事情耽擱，開發周期相當漫長，交叉口渠化示意圖最后上線測試也比預期推遲了很長一段時間。

圖十、web端交叉口渠化示意圖初始上線界面

上線測試一段時間后，根據大家的反饋，部分交叉口左轉或者掉頭半徑不足時左轉或掉頭車道會被設置在進口道外側。因此又增加了車道調整功能，通過點擊箭頭標志更換箭頭類型，使其更加適應實際交叉口情況。

圖十一、箭頭調整功能

要構成一個完整的信號交叉口設計評價分析應用，有了交叉口流量圖和渠化示意圖模塊后，還缺少信號方案設計和評價分析模塊。將已有的流量圖和渠化示意圖模塊組合到一起搭建初步的交叉口應用框架。首先需要解決的問題是應用界面設計，流量圖和渠化示意圖界面看起來嚴重缺乏設計感，也不太滿足軟件交互需求。為此學習了一段時間界面設計，參考其他一些在線應用的界面設計風格，在AI中繪制了初始版本的界面。

圖十二、應用界面設計

交叉口信號方案一般由相位相序圖和相位配時圖組成，考慮了非機動車相位、行人相位、搭接相位、待轉相位等開發了信號方案設計模塊。

圖十三、信號方案設計

完成信號方案設計模塊后，開始開發評價分析功能。根據交叉口評價分析的實際需求，選擇交叉口飽和度、延誤、排隊長度和服務水平作為評價分析指標，基于HCM2000手冊中評價分析模型進行計算。結合項目報告中對評價分析結果圖形化的需求，四個指標的評價結果均采用了圖形化展示效果。

圖十四、飽和度評價分析

圖十五、延誤評價分析結果

圖十六、排隊長度評價分析結果

圖十七、服務水平評價分析結果

考慮到實際應用中對交叉口評價分析大多數需要對早高峰、平峰、晚高峰等情況進行評價分析，或者某個交叉口改造中不同方案的對比，交叉口應用支持對渠化、流量、信號等進行多方案設計，并可以在評價結果中直接對比分析不同方案，也支持將評價分析結果導出到excel中進一步處理分析。

圖十八、多方案評價結果對比分析

從萌發開發信號交叉口評價分析應用的想法到最后上線測試足足經歷了三年多時間，從大四到研三，把一個簡單的想法一步步實現，整個過程既充滿挑戰也收獲不少。特別希望在校學習的小伙伴若有想法，就盡最大努力去實現，感謝這個偉大的互聯網時代，有海量的學習資料供我們參考，真正阻礙前進的或許不再是專業技能、不是編程、不是某一個軟件工具，而是你勇往直前的決心和愿意背后付出的努力。