個人積分：69分
文章編號：14303786
個人積分：30分
文章編號：14304177
個人積分：5089分
文章編號：14305781
個人積分：95分
文章編號：14306366
個人積分：210分
文章編號：14310981
個人積分：95分
文章編號：14315562
個人積分：5089分
文章編號：14316404
十一郎0507 wrote:
果然類似的事情~部份...(恕刪)
純討論大家就不用太激動了.
但不管是papago或是papago或是mio的做法
都各有利弊
就算是用POI的方式
也是有利有弊
像部份tomtom user 自認為mapshare會比較好的說法
只能說看不到別人的優點罷了
如果以單純的這件風災事件來說, 的確 Tomtom MapShare & MIO 的做法是最好的, 因為只需要 download 非常小部份的更新資料, 就可以達到規劃路線時, 自動去迴避這些斷橋的路段.
至於 Garmin POI 的做法, 只能說是 Nuvi 系列不得已的做法, 此部份在之前 Timber 兄有提到, 部份 Garmin 的機種是有迴避區域或是迴避路段的功能, 但可惜的是 Nuvi 系列沒有此功能, 而 POI 僅能設定警示半徑, 並不會影響到路徑規劃的結果.
真正要提到 Tomtom MapShare, 小弟並不覺得其他家 PND 廠商在實作類似的功能上會有什麼很高的困難度, MapShare 最主要是在 PND 上實作出一個 UI 界面, 讓 User 可以 Pick 路段, 然後做一些修正的指示 (改變方向, 封閉道路, 改變路名, 改變轉彎限制等), 另外就是實作一平台, 讓 Tomtom User 去 share 這些修正的資料, 但不要忘了, 當你 Pick 某路段時, 事實上這些路段在系統裡面都會有一個 ID 去識別它, 所以在 route engine 規劃路徑時, 它也同時去check 是否有修正的資料, 也就是 MapShare database, 如果有就引用.
而各家 PND 在實作 TMC 時, 小弟覺得難度比上述的 Tomtom MapShare 還高, MapShare 你引用的是 Tomtom 自家圖資, 但 TMC data 裡面是運研所提供的資料, 不但要把運研所對於全台灣各路段的 ID, 對應至自家的圖資, 上面 TMC event 提到的事故原因, 事故公里數, 還要再推算出來真正對應到自家圖資是那個 '路段ID', 實際上是更麻煩的.
但各位想想, 現在每一家 TMC 都已經實作出來了, 對於此次風災斷橋封路, 只是把 TMC 做一些功能的擴充而已, 簡單的講, 這些封閉路段不必引用警廣 TMC data, 而是自己造出來的 TMC event & data 就好, 再 '餵' 給系統而已.
MIO 真正要做到最強, 它根本就不用 User 去 download 任何修正資料, 它的 TMC 是自己在傳送的, 它只要把這些斷橋的資訊, 透過自家的 TMC 編進去就好. 光是這個強項就可以大作廣告了.
ps: 小弟只會動口寫程式而已, 至於上面所提到的 '實作', 都只是自己的空想而已.
FB: Pctine
個人積分：556分
文章編號：14323686
個人積分：0分
文章編號：14324371
個人積分：5089分
文章編號：14324431
