我來說說TMC(資訊採集、系統展示、導航作用等雜談)

TMC(Traffic Message Channel,交通訊息頻道)就是我們常說的即時交通路況，如果從狹義的來看，可能就是歐洲的RDS-TMC，一種基於FM廣播的即時交通路況發送和接收系統，廣義的理解已經完全超出了歐洲標準的限制，資料轉送不僅僅可以使用FM發射，也可以使用GPRS或者DAB等方式進行傳輸，並且TMC已經不僅僅是交通路況資訊，甚至可以傳輸天氣資訊，而最終的發展演變可能可以傳送停車場車位、電影院入座、餐館就餐等許多即時資訊，儼然是一個LBS的系統了。那麼現階段TMC的作用是什麼呢？從提供的資訊來看，就是告知駕駛員道路擁堵程度、突發交通事件、交通管制等交通訊息，和交通廣播台主持人不斷播報即時路況資訊類似，只不過電台是人工的語音的方式罷了。而TMC最最重要的功能是不僅僅告知使用者交通訊息，而是在GPS導航裝置中提供導航建議，合理避開擁堵管制等交通路段，以讓使用者最快時間到達目的地。TMC大概就是這個樣子吧，下面就細說一下個人對TMC的理解吧。

至今為止我依然不明白TMC是如何獲得交通訊息的，對於交警部門可能有交警值崗所以很容易得到交通訊息，當然，我認為這麼多的交通探頭也是協助交警獲得交通訊息的重要途徑，而對於交通管制資訊來說本身就是他們發起的自然是首Crowdsourced Security Testing道的，所以對於交警部門可能獲得交通訊息的方式非常多，但電子化的技術相對較少，可能更多需要人為判斷(可能這也是最有效辦法)。而對於TMC的公司來說，當然不可能直接從交警部門獲得資訊(當然也有可能可以通過其他途徑獲得交通部門的交通訊息)，那麼有可能和交通部門一樣，採用路況資訊員的方式，定點定人完成即時路況資訊的收集，交通廣播台就是通過各個地方的司機朋友不斷的向電台傳送簡訊或撥打到電話告知他們所遇到的路況，也算是比較有效方式。而據說TMC公司最多的可能是採用浮動車的形式，方式也許是這樣，比如與某出租車公司合作，在車上安裝一個獲得當前速度並不斷將資訊返回公司的裝置，通過即時獲得各個路段的車速(當然是多輛車權值後的車速)來判斷道路的擁堵程度，對於交通路況來說車速就是最重要的道路擁堵與否的標準。當然在此情況下的弊端也是非常的明顯，如果浮動車數量不夠多，或者浮動車分布不均勻等都是影響資料品質的問題。我就在想，每個路段安裝一定數量的雷達或者紅外車速等，是否同樣也可以達到路況監測的目的呢，不過這樣的工作可能只能交通部門來做吧，一般人或公司可能做不了。

說完了資料的收集，下面就是處理，資料的處理也是一個非常關鍵的部分，資料的解算演算法同樣會影響最終資料，畢竟這麼多筆資料並發反饋給服務端，如何計算如何權值都是一套科學的演算法，不過個人不理解此部分，所以也說不出個所以然。另外，對於網路傳輸也是一個值得考慮的地方，最快的速度獲得資料並以最快的速度發送到用戶端，此點也很關鍵，如果網路慢、解算慢，最後發送的資料是半個多小時前的資料，那還算是即時路況嗎，準確性也就更不用說了。一個公司對即時路況的回應時間間隔同樣也是實力的體現。

資訊採集並解算完成後則需要將此資訊發布，發布的是電子訊號，看不見聽不到摸不著，非圖形非語音訊號對於使用者來說是沒有任何意義的，那麼如何表現？其實方法很多，比如電台播音員的告知、撥打10086語音諮詢、環路上的道路擁堵資訊指示牌等等都是表現形式，只是比較簡單的表現。而最多的應該是發布在WEB端或者手機端的即時路況資訊，如何?？

在此之前先說一下簡單的TMC表現，一般以線性表示為主，紅色表示擁堵，黃色表示緩慢，綠色表示暢通，一般是這三種情況，而對於交通事故等，除了影響到線的顏色意外，嚴重的需要在此位置用一交通事故的符號表示出來，其實也就是一個Point罷了。說完表現我們可以講實現方法了：

1，最簡單的辦法：即時的繪製出線段的顏色和標示出交通事故點位。快速路上的道路資訊擁堵指示牌就是一個最簡單的繪製，已經固定的線型(LCD燈已經根據道路形態固定好形狀了)，發出不同的顏色表示擁堵資訊，仍然是紅色黃色和綠色，最最簡單的方式了。而如果基於WEB來做的話，甚至可以用SVG或者VML來繪製，而基於手機端的話，只需要帶有圖形引擎的繪製軟體就可以了。即時路況的更新就是不斷重新整理圖形的繪製。但這些都是比較初級的形態，但也是非常有效形態。

2，基於WebMap的方法(個人思路)：在現有WebMap之上再繪製一層線或者點，只是WebMap內建的底圖算是基礎資料了。可以使用比如MapBar的引擎，或者Google Maps API，個人比較推薦Gmap API，因為如果你在瀏覽器上繪製非常多的Line和Point，除了記憶體消耗大以外，引擎也需要有這樣的承受能力，比較Google的最佳化應該做的不錯的，引擎承受能力也可以吧。而且最最重要的一點，Gmap API支援kml，你甚至只需要不斷的更新你的kml資料就能表現出即時路況的效果，感覺非常的方便，但我也沒有做過這樣的測試，更不用說對於WebMap引擎的壓力測試了。不過這種方法也是比較糟糕的，因為在大資料量的情況下，瀏覽器奔潰的幾率較大(個人愚見)。

3，在WebMap之上疊加圖片：WebMap作為底圖基礎資料，TMC資料作為一個圖層疊加於WebMap之上，不使用畫線畫點的方式，而是採用疊加圖片的方式，Gmap API不是已經支援overlay了嗎，所以只需要產生即時路況圖片疊加就可以了。至於如何產生圖片，方法很簡單了，就是WMS，用GeoServer或者ArcIMS等應該都可以。其實上面的第一種方法也可以直接用WMS來實現。我們僅僅需要更新後台資料庫或者地圖檔案，WMS不斷重新整理輸出新的路況圖片，這樣就可以實現動態路況了。方法也是比較簡單，大多數公司的TMC的實現都採用此法吧。(如果判斷錯誤歡迎指正。個人認為Google Map上疊加的wikipedia地圖，用的也應該是overlay WMS圖片的方式，而不是直接的marker)

以上是對於TMC展示的個人思路，我所能想到也大概就是這些了。那麼如何作用於導航的呢，此點最為關鍵，我們還是說原理。其實剛剛上面有一點沒有說到的是，什麼地方用紅色line表示，哪些用綠色的line，如何由堵車紅色變成暢通的綠色等，這些如何做到的？所有的即時路況其實都和路有關，而即使每一條路都有長有短，也並不是一堵車就整條路堵車的，其實很簡單，將所有的路都打斷，段越多原則上表現的越細膩或者實際，一般來說在路和路的交叉口打斷是比較合理的，如果還有必要則可以進一步的打斷，而每一個段就是一條記錄，速度資訊最終會賦值到這些道路上，堵車與否的資訊也就算是賦值到這些道路上了，繪圖也就知道著色資訊了。說的再白話簡單一些，一個地區的所有路段(不是道路)都記錄於資料庫中，一個路段就是一條記錄，而每個路段都是包含座標資訊的，這些座標資訊用於繪製Line形狀，而對於每個路段的即時路況只有可能是三種情況中的一種，要麼暢通要麼擁堵要麼緩慢，根據這三種情況對Line使用紅黃綠分別著色，即時路況資訊就一目瞭然的顯示了。此點算是對上面三種表現方式的總結概括吧，但對於導航來說此點也是非常重要。

在導航電子地圖中，所有的道路都是以路段的形式來表現的，每個路段就是一條記錄，有形態、等級、速度、名稱、單行資訊等，當然更有唯一的ID標記，不然上面所說的著色也是無從談起。理解了這些的話我們就可以將整個實現思路串起來了，也就可以理解明白TMC公司和資料公司以及導航軟體公司是如何來合作的了。首先，TMC公司按照自己的方法對道路進行分段，以助於將路況資訊發布到每一個路段，然後，和資料公司合作，資料公司將TMC公司提供的路況訊號路段ID對應到導航電子地圖中的道路路段ID，TMC公司甚至不需要考慮座標資訊，因為資料公司的電子地圖中就包含了道路形態的座標資訊。而這兩張ID對應表是至關重要的表，一旦對應錯誤則整個TMC系統資料表現混亂，而導航來說更是無法使用了，因為TMC發布的東路發生堵車結果地圖對應到西路上堵車，那還能了得。這兩張表格，術語上來講，TMC公司提供的算是Location Table，而資料公司提供的算是Matching Table，也很容易理解，TMC公司發基於位置的路況資訊表格，而資料公司就是做道路路段對應表格。對於導航公司來說，如何使用TMC資訊呢，其實對於導航來說，航線規劃需要考慮道路等級、道路速度、道路單行限制等資訊，而TMC資訊則成為影響航線規劃的另一條參考資訊，根據TMC提供的路況資訊，將道路路段假想成等級降低、速度降低或者將道路設定成限制進入，可以說TMC資訊是動態改變道路的屬性來影響整個的航線規劃，當然，TMC資訊的加入導致的情況是，航線規劃也需要根據時間的推移不斷的改變航線，讓航線更加趨於合理，不可能是以前的從一個起點規划到終點中間一成不變的航線了。舉例來說：某路段發生交通事故，整個路段很快由暢通變成緩慢，如果事故嚴重甚至會變成擁堵，而TMC即時捕捉到該資訊，並解算成功，通過網路(FM/GPRS/DAB等都可以)廣播發送，在GPS導航裝置端已經有接收裝置，接收到事故資訊，原本規劃通過該事故路段的航線則需要重新計算，繞過該事故路段繼續行走於較暢通的路段，以免在事故路段進入堵車狀態。由此可見，TMC的資訊是非常有用的。

TMC技術展望。嚴格來說TMC技術應該算是LBS技術的一個分支，並且TMC技術是最有可能演變成LBS技術的，現階段為什麼那麼多公司做TMC，並且投入大量資金，個人擔心如同現在的導航電子地圖行業，因為現階段導航電子地圖都很燒錢，能夠贏利的為數不多，雖然十多家公司擁有導航電子地圖甲級資質，但真正製作導航電子地圖資料的沒有幾家，有些是因為自己的地圖能夠搭載自己的軟體賣個價錢，有些就根本沒有發布過導航電子地圖。TMC難道也要如此發展？不得而知，看態勢可能如此，業內做的最好的應該算是世紀高通公司了，加上被四維圖新公司併購，前景也許不錯，但暫時應該是沒有贏利的，因為真正使用他們TMC上市的為數少之又少，所以我很不解。至於前景，如文章開頭所言，重要之處首先打通這一通路，從資料擷取技術到發布到客戶的成熟應用，一路暢通的話對於後期來說是值得期待的，因為TMC本身就屬於增值服務，而增值服務可以有很多內容，下次就不僅僅是TMC了，可能是天氣預報、停車位資訊等等等等。而對於下遊行業來說，可以是導航市場，可以是10086這樣的服務市場，WebMap也算是一個部分，甚至可以是ITS研究部門等。如同早年的物流，誰掌握了通路誰就控制了市場(想不起來具體句子了，但意思大概如此)。誰掌握了TMC通路技術，誰就掌握了上下遊市場，不知道這樣說是否片面，但至少對於上下遊還是有影響的。讓我們期待TMC更迅速的發展吧。

本來應該寫成至少兩篇文章的(一篇是基於WebMap的TMC展示，一篇是TMC如何作用於導航系統)，最後一氣哈成了一篇，所以也就只能說是雜談了，個人只是接觸過一點TMC，而對TMC技術層面也不懂，雜談的也只能算是個人對於TMC的理解吧，正確與否，還望拍磚。