關於堵車的二三言語_風聞

想要寫這個話題是因為國慶回家下了高鐵，四十分鐘的車程開了有兩個多小時。我又有暈車的毛病，雖然這幾年坐的多了有一點適應了，但還是在路上一頓一頓的晃得難受。所以就想着寫寫吧。

我大概會寫成兩個版本，一個是單純就我已有的感受與知識水平來寫，另一篇是要查些文獻的，當然也就是知網上的一些公共資源，再向上有些超出我現在的能力範圍了。（下面是沒看文獻前的，文獻已經找了一些，還要消化消化。）

現在的陸地交通，除去軌道交通（這也是我最喜歡的一種了，快速高效還價格近人），可以説基本上還是2維的交通，或者説，是2.5維的。

當然了，現在有高架橋、地下通道，有高速公路，看似不是二維的。

首先，高架橋和地下通道有些是為行人設置的，這不在我的討論範圍內——這篇的討論範圍是用於小轎車以及卡車等機動車行駛的路面。根據常識，一些分橋上橋下兩條路的或者是高速公路，都是通過某些節點與普通道路相連，而這些路面與普通路面在二維地圖上重合的部分之間相互是不連通的（硬説車子衝出欄杆飛下那我無言以對），也就是説根據Dijkstra算法可以認為它們之間的距離是∞。

換言之，**這些路面與普通的路面分屬兩個不同的圖層，這兩個圖層分別將DEM中的高程值替換成諸如某時段的平均流量，那就可以構建模型。**而且根據道路分佈的總的特徵，以Grid為主體在複雜地區使用TIN時比較好的方法。這也就是交通問題的DEM模型化的基礎。其間3S的集成也很重要，例如可視化遙感圖像也是一個可靠的方法，要做到實時化就離不開GPS（為了避免被槓，解釋一下，美方命名的GPS、俄羅斯的格洛納斯、我國的北斗等都是全球衞星定位系統，也就是GPS，只不過美方起步的早剛好它的衞星定位系統就是叫GPS）。

在ArcGis中可以根據最原始的Dijkstra算法（或者是更先進的算法）設置程序來完成對交通的規劃，比如道路的寬度、紅綠燈時常設置等等。

與此同時，問題來了，一般情況下所設計的紅綠燈的時長是根據常態設置的。但是一但到了特殊的情況，這套為了平時的流量設計的程序，就遇到了困難。**最顯而易見的是一些國家法定假日的第一天（或者前一天）/最後一天（或者後一天），在一些火車站尤其是並不是交通樞紐但所處城市屬於區域次一級中心的火車站（交通樞紐反而因為其樞紐作用平日裏與假日相差倒並不這麼明顯）前的路上能明顯發現出站人數/進站人數明顯的增多，這就極容易形成交通擁堵。**高速上也有類似的現象。

所以，我在這裏提一個想法，算是一種思路，（實施起來必定是要經過許多具體的調整和補充的），在國家法定節假日的始末日尤其是五一假期、國慶黃金週、春節這三個假期的始末日分別對火車站的進出站口的交通信號燈的市場做出智能化的改變。當然，具體的怎麼變，變進站還是變出戰，變長還是變短，這都需要具體的統計以及根據往年的數據進行預估以及在調整前多渠道的公佈方案等等。

解決堵車問題的技術手段總體來説無非是路變得更大更寬、時間分配更加合理（人數減少這個不太切實際、當然公共交通如果有一天真的能完全滿足需求也不是不可能）。但是，在這之外還有別的導致堵車的原因。最常見的兩種一是諸如車禍這樣的突發路況，這在路面不夠寬的道路上尤為致命；另一種是有某些自詡車技高超的心急的老司機見縫插針式的行車習慣。一輛車見縫插針，兩個車道的車就得減速，本來各自保持車距雖然視野並不那麼開闊，駕駛並不那麼輕鬆但好歹是正常的行車幾下一來就變成了“蠕動前進”。而且，這也容易引發車禍。

而回到非技術層面，現在的常見的堵車，還是與相應的公共設施和公共服務供不應求以及過去很長一段時間城市發展沒有做好預期的規劃導致的歷史欠賬有關。現在流行倡導數目字管理，我想交通領域可能是最有可能實現也最需要相關體系的一個方面。過去我們講村村通是公共設施“有”的問題，現在講求數目字管理，是如何提高“效率”。當然了，由於我們的社會性質，有些偏遠地區的相應設施即使虧本也要跟上。

我所能想到的未來的交通(如果還保留着私家車)大概是這樣的：車輛自動駕駛（當然已經是能夠處理一般路況了）。車輛和路面都有着數據傳遞裝置。全國各地有各級的智能化數據處理中心，最小到鄉鎮一級，這與GIS系統連接在一起。並且能自動化根據一定區域內車流量的大小對指示燈時長進行規劃（可以以幾個基本預定時長*車速進行劃分）。

在這個基礎上，可以對車輛的行駛空間從2.5維變為真正的三維來拓展路徑。（當然，這時候可能都不能稱為車了）