Arcanis 的部落格

車載資通訊產學論壇 - PartII RDS-TMC

  先自首吧~自己本身對RDS這塊不熟,所以研討會講到這一塊時也是大概了解的聽聽而已,之所以會這麼慢才整理出報告也是因為這個原因~只能說是事前準備不足,雖然去之前也不知道他們要講這方面,不過這應該不能當作藉口。前一篇全國路況資訊中心」網頁介紹完後,接著的就是RDS - 副載波廣播系統(*1)的部分,以下將與網路資料混雜報告。   

  RDS主要是應用在頻率 87.5108.0 MHZVHF/FM廣波電台上,其目的是為了增進FM接受器的功能,從1984年開始在歐美發展,目前主要在歐美及日本發展較廣泛,TMC(Traffic Massage Channel*2)即為RDS的特殊應用,利用RDS的頻帶,以TMC所規範的格式進行即時路況資訊廣播的動作,亞洲其他地區以上海、北京、廣州以及台灣較多使用。 政府去年開始結合產業發展,計畫將導航業與廣播業合作,進行車載裝置運用的相關動作,可以從網路發現梅老師的名字有被列在上面~上面列舉了全國大專院校所開授的相關課程:http://www.mmnetlab.csie.ncku.edu.tw/pctc/website/teacher_team.html。業界在RDS-TMC上的成果以研勤的PAPAGO (*3)以及神達的MIO (*4)為代表例子,PAPAGO的開發是以結合3D VIEW的方式呈現道路周邊的街景(不含道路景像),而MIO則是以虛擬實境來模擬畫面(含道路景像)。哪個好用見仁見智,我也不能在這裡做推銷的動作,目前MIO有部分型號的機型可支援下載PAPAGO地圖。網路上有人將兩者做比較,認為MIO的:

  規劃速度較快
  
可設不反向規劃
  
地圖比較清晰
  
程式較小較不會當機
但缺點是:
  
地圖中沒有小路
  
僅北市有門牌號碼
  
畫面不優

PAPAGO則是:
  
語音較清楚
  
立體道路清楚
  
北中高三市可依門牌查詢地址
  
3D VIEW畫面較酷炫
  有小路顯示
缺點則為:
  
程式太大偶爾當機
  
搜尋速度慢

  回到RDSRDS-TMC對於路況事件的運作是依照編碼所對應的Table來取得,透過轉碼以RDS廣播格式來發送資訊,而使用者則透過車載的接受器來取得路況。簡單來說,就是由全國路況資訊中心將路況對應兩個主要的Table後,轉換成RDS-TMC格式後,將資料封包送入編碼器,然後傳至FM發射台再轉給車載裝置。

 

資訊轉換過程
(資訊轉換過程)

  Table的建立主要分為Location Table以及Event Table兩者,目前Location Table涵蓋範圍包含國道及快速公路全線,以及擁有即時路段速率的北市、北縣、中市、南市、雄市5縣市,共計約680條路徑及4500多個TMC座落點 (Point,包括十字路口、圓環、交流道、收費站、休息站等),而每個Location PathLocation Point均設有代號.

Location Table簡例
Location Table簡例

  Event Table則以在「全國路況資訊中心」網頁上可看到的7種道路狀況做為主類別,其下再細分次類別,TMC原本規劃31類,共1,402種路況事件編碼。而政府另外自訂「並排停車」、天氣、路段速率等自訂碼,額外增加資訊的提供度。

Event Table簡例 
Event Table簡例

  根據運研所的報告,目前RDS裝置已可正常執行e-traffic(全國路況資訊中心)上的訊息操作,我沒那種裝置所以也不能幫忙證實~周遭朋友也沒有裝置,所以這部分只能靠研討會上所聽得的成果報告出來了。

  目前政府預計將會在今年底前配合都市交通資訊中心的建置,先完成西部縣市的即時交通資訊,並於民98年中完成東部縣市的擴充,以及在所有公車上裝載GPS (我相信~近期內絕對不可能) 的動作。至於目前RDS的涵蓋率,以警廣做為主要發送單位,目前大致可涵蓋全台70%左右的區域,北部幾乎全面涵蓋,東部則以花東兩地涵蓋率較高,而南部地區則受限於嘉、南兩地含有大量的地下電台所影響,因此涵蓋範圍在此兩地較低。

  若還有其他相關問題可到「全國路況資訊中心」網站發問,問我是絕對答不出來的。也可以在該網站的Q&A(Link)中找尋。   

  心得 . . . 待日後補上。

(下回,車載資通訊產學論壇之Overview Of Vehicular Networking - 藍崑展教授

*註1:RDS (節錄自奇摩知識+ (Link)) 
  RDSThe Radio Data System)數位廣播系統,在歐洲運用的很廣泛。它的主要作用是這樣:它可以設定一個”頻道的優先權,什麼意思呢?就是你可以設定你比較喜歡的電台頻道:如體育、新聞或軍事等,平常收不到這些頻道,它就是一般的收音機;當你的收音機能收到你所設定的頻道信號時,收音機正原來播的頻道會中斷,轉而播出這方面的訊息,它也不一定要用播放的,也可以從螢幕上顯示;還有一種功能就是即時警告,當有事故發生時(如堵車等),電台會播送訊號,RDS收到就會顯示出來,你就可以走別的路了。一般在歐洲車都會把RDS功能列為標準配備。

*註2:TMC(節錄自奇摩知識+ (Link))
  
TMCTraffic Message Channel的簡稱,在歐洲及日本,當地使用者都已能充分利用TMC所提供的訊息,規劃出最理想的動線並善用各種有用訊息,讓您隨時掌握最新交通路況、天氣、公有停車資訊、浮動油價與好樂迪KTV空包廂數量及優惠訊息五大服務資訊。即時路況報導是利用FM無線調頻系統(Radio Data System)播報即時交通及天氣資訊中的一種通訊應用,一般通稱為RDSRadio Data System/TMCTraffic Message Channel),其提供的服務內容包括:

  (1)目前交通意外所影響的區域、路段與方向

  (2)交通意外或是天氣狀況可能持續之時間

  (3)綜合上述資料所建議之替代行駛路徑,交通訊息的更新頻率為每五分鐘一次。

  RDS/TMC蒐集交通資料之方式大致與衛星廣播相同,均是透過當地交通機構與設置於路邊的SensorCamera進行資料彙整與統計。

*註3:PAPAGO(官網連結)
  
主要用於提供系統導航所用,其中GO阿姨系列的3D街景為其特色。

PAPAGO
(PAPAGO)

*註4:MIO(官網連結)
  
同樣主要為系統導航所用,提供道路虛擬實景,部分產品另附有相片編輯、旅遊電子書等功能。

 MIO
(MIO)

車載資通訊產學論壇 - PartI 全國路況資訊中心

  本次車載資通產學論壇其中一個議題,便是介紹政府交通部運研所的「全國路況資訊中心」:
  
http://e-traffic.iot.gov.tw/,以下大致介紹此網站。

  於系統而言,資料來源主要來自於警廣、高公局以及公路總局,搭配各縣市政府交控中心的資料,統一傳至路況資中做處理的動作,再發布到各個發布中心。其中來自警廣的交通資料是處於隨時連線的狀態,高公局的部分則是每3分鐘做一次撈取的動作,公路總局負責回傳道路坍方或颱風等資訊。資訊內容大多以XML格式來發布,各縣市交控中心傳資料的速度不一,主要傳回路段速率、CMSCCTV影像、事件資訊4項,速率計算是以一般公車的行走節點以及行車速率去算的,並扣除紅綠燈等候時間。

架構圖
(架構圖)

  進入網站時,預設是顯示路況事件頁面,網站除了可查詢道路狀況外,還附有天氣狀況、路徑規畫、地圖列印等。在路段速率部分目前只有國道部分完成,所以進入網站時預設是顯示路況事件tab而非即時路況tab,預計民國100年會完成省道部分的建置(應該是不可能),但國道部分依然有許多區段常常會無資料顯示,個人覺得目前這功能還不是很實用,除非等一般道路的交通速率顯示都弄好了才比較可看吧~至少高速公路速率狀況一直都差不多的。

 即時路況頁面

 (即時路況頁面)

  除顯示全台道路速率狀況外,此頁面還可顯示CCTV道路即時影像(含市區影像,記得是說5000個點)CMS(*註1)、以及與中央氣象局連線的氣象資訊。

道路即時影像 

 (道路即時影像)

  路況方面提供7種道路狀況資訊,包含路障、堵塞、施工等。不過在分類資訊上方的選擇欄位就不太懂是做甚麼用的了,有國道跟縣市可以選擇,估計應該是用在另一個「事件說明Tab」中要用的,以條列的方式顯示出狀況事件,不過在打這篇文章時網站顯示無任何交通事件發生,所以無從確認,待日後補上。

路況事件資訊 

 (路況事件資訊)

  網站除路況資訊外,還提供路線導引功能,要注意的是必須先從(路口、地標、地址)三個選項選擇一項。建議是選擇其一後再用他的「進階查詢」來選擇地點,或是直接在地圖上點右鍵設定起終點,不然依照一般使用者習慣來輸入的話,會出現無資料的情況發生,用起來稍嫌麻煩。像「西門町」直接輸入是找不到坐標的,必須輸入「西門町商圈」才會出現坐標。執行路徑規畫後,下方還會出現路線走法跟各段落所需行走長度(連左右轉都有),好不好用當然就看個人囉~他最佳路徑的規劃,是先由主要幹道為主,直到目的地附近才會轉成小徑規畫。真要說起來,最難看的大概就是路線上的指標了,會讓規畫出的路線長的像毛毛蟲 . . .

(ex.網頁輸入的地址格式為:(臺北市,中正區,大埔街,25,0,11,),後三碼代表巷弄號)

 路徑規畫頁面

(路徑規畫頁面)

 

※總結此段落心得:

  不知道是自己手殘還是他網站JAVASCRIPT寫不好,常常被我按沒幾下就當機或是一直在LOADING畫面卡死,而且我還是用Lab的電腦跑的。既然在桌機上跑這個網站都常常出問題了,移到行動裝置上的效果大概是可想而知,還是說這本來就是讓人在桌機用的?那他幹嘛在車載講座提出來!(/‵皿)~ ╧╧

  自己是沒有EeePCMID之類的東西,所以不能立刻試看看這網站在那上面的執行效果,這部分也在等朋友跟我說使用結果,如果我記得的話,會在幾天內補上在EeePC的使用效果,速率、流暢度、畫面顯示等,如果我沒補完~希望有人可以留COMMENT提醒我,或是有人願意直接跟我說使用結果 . . .

  這計畫是跟UrMAP以及PaPaGo合作的,所以地址的細膩度算是滿高的,與GOOGLE的地圖比較起來的話,不過GoogleMAPAPI比較能結合其他應用,用來作設計還是比較好用,嗯~扯遠了。閒閒沒事試試看用自己家在台中市的2個地址作路線規劃(同一街區),規畫出的路線會顯示我家前面那條路段的頭到路段尾,似乎所有地圖的路線規劃都會這樣,有必要改進嗎?好像也沒必要. . .而且應該沒幾個人像我一樣無聊,也很少會發生要規畫兩個住址在同一街區上的情況。哈哈。

  先到這~其餘想到再補完。

(下回,車載資通訊產學論壇之RDS-TMC

 

*註1:CMSChangeable Message Sign)資訊可變標誌 意即提供用路人最新路況或資訊,有時用來提醒用路人或做宣導用,如果CMS有附帶監視系統即所謂CCTV可能才有監視系統,至於是否有動態錄影就要配合影像處理及壓縮技術,並不是所有CMS都有附帶監視系統。

觸控式螢幕的叮咚

 

前天從實驗室A走觸控式螢幕

昨天用FLEX寫出了 "叮咚" 按鈕 ( 少林跟賤狗提議的,有事找他們 )

現在用手按按鈕可以發出 " 叮~~~~咚 " 的聲音了

不過原本的聲音檔是WAV檔,FLEX先生好像不吃

強制轉成了MP3格式才能 " 叮~~~咚 "

但是!?我的叮咚聲音就變質了...現在好像老阿嬤在叮咚

所以希望那個誰誰誰有好的叮咚.MP3檔的麻煩傳給我一下.

[Term Project] ODF 專題感想

"

  小組名單:

  493512272 許乃元

  493512296 林育佐

  493512337 盧松筠

  493512399 李宗熹

  此次我們的專題是做 ODF,不是什麼滴下式注入系統,而是開放文件格式(OpenDucument Format),為 "OASIS Open Document Format for Office Applications" 的縮寫,是一種用以儲存及交換可編輯文件的文件格式,如:文書檔、圖表、簡報等,一開始是由 OpenOffice.org 所創建的一項開放原始碼計畫,而之後移交給 OASIS 負責,為一種以 XML 為基礎架構的開放性標準文件格式。


  引用 OpenOffice.org 官方網站首頁中所聲明的,OpenOffice.org 是一套跨平台的辦公室軟體套件,能在 Windows、Linux、MacOS X (X11)、和 Solaris 等作業系統上執行。它與各個主要的辦公室軟體套件相容。OpenOffice.org 是套自由軟體,任何人都可以免費下載、使用、及散佈它,而他們也在今年1月提出了中文計畫,並且針對之前版本做重大改良。

  通常一個 ODF 檔案可以是一個以<office:document> root 的 XML 檔案,也可以是一個包含許多檔案跟目錄的 ZIP 檔,現在大部分都採用以 ZIP 基礎的格式,因為它可以包含二進位的資料,而且檔案相對來說比較小。ODF 還可以分成四個 XML 檔案存放,這算是一個 Separation of concerns(將功能分離,類似於模組化) 的好範例,分別是
 content
 styles
 metadata
 application settings

   與目前的情況相比較,相對於網路上或一般文件上針對文字處理的工具,在開放性、創造性以及改革性皆被微軟 office 所壟斷的情形下,將 ODF 定訂為公定的開放性文件標準很明顯的對於競爭上、費用上及資料分享都有很大的影響,因此包括 IBM、昇陽、Google、Novell 及 Adobe 等逾150家業者皆為此計劃的支持者,當文件和服務逐漸的從紙張轉換到電子格式的情況下,這些支持ODF的業者自然期望ODF格式能夠普遍被使用者接受,成為辦公室軟體儲存或管理的標準格式,而不再是被微軟所壟斷。

   由於微軟的 office 檔案格式是不公開的,也就是說 OpenOffice.org 不管怎麼做都無法與 Microsoft Office 100% 相容,這使得人們在推廣 OpenOffice.org 時總會遭遇到極大的困難。但在接獲ODF已通過成文公定的文件標準後,微軟隨即推動了 "ODF Add-in for Microsoft Word" 計劃,讓 Word 可以直接存取 ODF 格式的檔案,目前已推出支援 Microsoft Office XP、2003 及 2007的版本。

  以上是我們專題報告的大致內容。

  而在今年三月的新聞指出,微軟的開放文件格式 Open XML 與 ODF之爭,微軟在美國加州將嘗受敗績,因為加州政府已經提出新法案,要求所有政府機關組織必須將ODF列為文件往來必要格式,此舉無疑又再次給了微軟難堪,看來阿諾州長可能對微軟有很大的意見。

  另外,在中國方面的消息部分,由於中國目前也在推展他們自有技術的開發,因此針對辦公文件格式方面也發展出了一個新的文件標準格式 Uniform Office Format (UOF),中國方面自稱「標文通」。在得知這消息之後,在今年不久前一項昇陽與中國經濟部以及智慧財產局合辦的「標準化中的知識產權」國際研討會中,昇陽的主席 Scott McNealy 在會中就開始呼籲,要求將中國自訂的文件標準格式 Uniform Office Format (UOF)與 ODF 進行整合的工作,但是在經過一個月的會議後,微軟大佬隨即在今年5月宣布支援中國的這個文件標準(UOF),將贊助一項促成 Ecma Open XML 與中國文件國家標準 UOF 相互轉換的開放原始碼計畫,使得一般使用者能以 Ecma Open XML 格式或 ODF 開啟和儲存文件。

  這是再微軟先前釋出了 OpenXML-ODF 轉換軟體之後,又一項整合 OpenXML 與 UOF 文件之間轉換的開發計畫,微軟雖然目前在開放文件的戰爭中佔了劣勢,但隨著這些計劃一個一個的推出與整合,到最後 Office2007 應該仍舊可以保有在文件上的地位,可說是微軟野心似乎還是很大,依然不肯放棄這塊市場上的肥魚。

  相對來說,OASIS一直想將 ODF 的這個統一格式引入中國,據說 OASIS 在半年之前就已經開始在嘗試,但一直沒有更明顯的後續動作。也由於在中國部分,近年來不斷發展國內「自有」標準的政策,尤其在 IC 產業領域特別明顯,這項要素自然使得勸說中國那邊放棄 UOF 計畫更加困難。

  就以旁觀這開放文件戰爭來說,新聞業者首次很神奇的提出良好的見解,他們認為可以先尋求兩兩格式的共存與互通,再考慮合併而建立單一的標準,針對這點來看,的確是可行的,但前提還是要先要求微軟部份放下身段,釋出 Office 系列的原始碼,才能使得目前這些開放格式能有個統一,亦或是就乾脆改成以微軟文件格式為統一,將整個開放式文件移交由微軟所負責,並要求在計畫後釋出公開原始碼以供使用者得以免費取得此格式,並加以修改實做,如此一來戰爭勢必可以快速且和平解決,但主要還是取決於微軟的態度,也因為微軟一直是保持是自以為產業大佬的型態,所以才會讓許多人對於微軟有很深的意見吧!!

  相關來源:

  ODF聯盟WIKI百科openoffice.org官網OASIS官網台灣CNET新聞

 

"

[Term project]補充期末Project - ODF概述

"

  有些地方前一篇文章沒講到,在這裡做些補充,之前引用回自己部落格的文章很難找,所以改成po文形式~

  以下:


  來源1

  來源2

  來源3

  OpenDocument format (ODF),為"OASIS Open Document Format for Office Applications"的縮寫,是一種用以儲存及交換可編輯文件的文件格式,如:txt檔、圖表等,ODF在一開始是由OpenOffice.org所創建的一項開放原始碼計畫,而之後移交給OASIS負責,為一種以XML為基礎架構的開放性標準文件格式。

   與目前的情況相比較,相對於網路上或一般文件上針對文字處理的工具,在開放性、創造性以及改革性皆被微軟office所壟斷的情形下,將ODF定訂為公定的開放性文件標準很明顯的對於競爭上、費用上及資料分享都有很大的影響,因此包括IBM、昇陽、Google、Novell及Adobe等逾150家業者皆為此計劃的支持者,當文件和服務逐漸的從紙張轉換到電子格式的情況下,這些支持ODF的業者自然期望ODF格式能夠普遍被使用者接受,成為辦公室軟體儲存或管理的標準格式,而不再是被微軟所壟斷。

   由於微軟的office檔案格式是不公開的,也就是說 OpenOffice.org 不管怎麼做都無法與 Microsoft Office 100% 相容,這使得人們在推廣 OpenOffice.org 時總會遭遇到極大的困難。但在接獲ODF已通過成文公定的文件標準後,微軟隨即推動了 "ODF Add-in for Microsoft Word" 計劃,讓 Word 可以直接存取ODF格式的檔案,目前已推出支援 Microsoft Office XP、2003 及 2007的版本。

  而目前支援ODF格式的軟體包括有OpenOffice 2.0、昇陽的Star Office,以及IBM的Workplace等。

  附上:ODF聯盟

"

ODF相關

  非常好~剛按下發表就給我當機,只好再來發表一篇,如果這學期因為WECO本身伺服架構不好,導致發文所佔成績偏低,那...大概會想翻桌吧!也不是只有學期末才這樣,從這學期期初就一直是常常會當機的模式,真的會讓人到最後跟想發文...

  抱怨完了~回原本主題,在綠洲又看到ODF相關的解說,所以翻譯一下PO上來:

   OpenDocument Format (ODF)是一種以XML為基礎的文件格式,主要是應用在辦公軟體上,其包含有文字檔、試算表,圖表和圖檔等元素。此檔案格式是建立在各種檔案間已存在的公定標準下,利用這些標準,使得檔案間彼此轉換變的更簡單容易。

  作為OASIS管轄的開放性文件,ODF同時也建立了一種新型態的文件應用,並對以往傳統性文件的彼此不相容提出了解決之道。

  以上,翻譯第二次了...以後再也不想跟WECO有任何關聯了...

XML相關術語大匯集

"

  這是之前我有介紹過的網站上的其中一頁,裡面整理了許多跟XML相關的術語,儘管如此,老師期末所列出的一些術語還是沒有在其中,因此當初選期末專題時有點卡到瓶頸,因為剩下的專題選項所剩不多,許多名詞又找不到~

  另外附上裡面沒有說明的主題名詞,想知道的就自己找囉!

  未列入的主題:MusicML、X3D、CDA、LZX、BPEL、OOXML、ODF、ATOM、SyncML、hCalendar+hCard、KML、JSON。

  § XML台灣資訊網 §  

"

XML相關術語大匯集

"

  這是之前我有介紹過的網站上的其中一頁,裡面整理了許多跟XML相關的術語,儘管如此,老師期末所列出的一些術語還是沒有在其中,因此當初選期末專題時有點卡到瓶頸,因為剩下的專題選項所剩不多,許多名詞又找不到~

  另外附上裡面沒有說明的主題名詞,想知道的就自己找囉!

  未列入的主題:MusicML、X3D、CDA、LZX、BPEL、OOXML、ODF、ATOM、SyncML、hCalendar+hCard、KML、JSON。

  § XML台灣資訊網 §  

"

wimax資訊網

  看最新幾篇文章都在講WIMAX,小弟也跟著去搜尋了一下,找到了這個wimax資訊網,裡面介紹了基本的WIMAX概念以及最新消息,也有研討會的情報,感覺是不錯的網站~介紹給大家。

關於主題-手機聊天室

  雖然說他們是結合了專題來報告的,感覺有點偷吃步,不過能實際做出來也是滿令人佩服的,滿好奇他們這組的下一步動作會先從哪方面開始~

  就現在的網路聊天室而言,還滿常遇到的一個問題是,常會遇到打字很慢的人,當遇到這種人所能做的除了離線落跑就是等待再等待,若將聊天室移植到手機之中,來看手機的鍵盤設定反而比一般電腦鍵盤還要難按,因此除了日本神奇的女高中生外,利用手機進入聊天室的使用者想必會超級跟不上聊天的進度,不知道是不是再這方面會先著手想出一個解決的方法。

  另外就是圖形介面移植手機平台的部份,看報告介紹,目前寵物圖形介面似乎只有用電腦上網的人才能看到,手機使用者只能看到留言訊息,若真的能將圖形介面移植到手機上也會是個不錯的發展。

頁面