個人積分：34分
文章編號：1036696
個人積分：147分
文章編號：1036734
r5299jerome wrote:
igogo與大輿圖資...(恕刪)
但新版圖資用在舊版軟體，模擬導航的路徑確實跟新版一樣，也證實圖資是放在igogo的資料夾內，igogo是旅遊業團體開發的旅遊導航系統這點說的沒錯，但也是必須配合圖資才能發揮效用。
MIO圖資與igogo可說是一體的，可以說：igogo就類似圖資的景點搜尋的外掛＠＠！也就是利用igogo的座標直接連結圖資做導航。
現在要跟您釐清的是，圖資的存放資料夾位於何處，因為有人問我才貿然回應，我並不是說igogo與大輿圖資的相關性，而是MIO268圖資放在igogo的資料夾內，當然…igogo也能搭配其他圖資來使用(如果其他導航軟體廠商肯這樣做)，但目前MIO268有沒有換圖資，我只是依常理推斷，我也沒有向各位保證，畢竟我並不是MIO內部人員。
而常理推斷是：廠商為了讓新版與舊版導航軟體往後能一起更新，因該不會為了更新版本而換了圖資，除非想讓舊版軟體斷了後路，大家想想，還有MIO138這玩意兒，MIO公司大家可想而知，連更新個圖資就花了大半年，怎可能多出一種圖資來搞垮自己？除非廠商已把其他圖資相容性作了大幅修改，讓其他圖資相容於新版與舊版軟體上。
個人積分：34分
文章編號：1037181
個人積分：6分
文章編號：1037811
把看到的一些分享出來，我是IT人，但導航軟體不在行，若不對請大家包函指正。
【iGoGo 景點資訊】
研究了一下【228 版】與【前版本】有淺淺的心得如下：
iGoGo 是一套景點管理系統，依各縣市內建各景點的導覽資訊及景點位址。他是一套獨立系統，但提供幾個對外 Interface 供與外部系統連結並提供景點資訊，這套 iGoGo 為了能跨各家導航軟體，因此這套系統並不儲存 MAP 資料，但是，他存放些什麼資訊呢? 他存放景點的文字說明資訊、景點的 GPS 座標值及簡單微小的風景圖片。依此方式設計，iGoGo 是一彈性很大，因他可跨平台，也是一很強大的商業景點管理系統，可儲存大量的景點相關資訊。
主導航軟體透過連結呼叫，執行 iGoGo 。當使用者選定【檢視地圖】時，iGoGo 透過 external interface，reply interface id、景點名稱及其 GPS 座標值給主導航軟體並同時結束 iGoGo 執行。當使用者選定【設為目的地】時，iGoGo 透過 external interface，reply interface id、景點名稱及其 GPS 座標值給主導航軟體並同時結束 iGoGo 執行，當主導航軟體 receive replied message 後直接依起點、終點位置進行路徑規劃。
因此，我前面提及可將 228 版的 iGoGo copy 至之前版本來使用的原因，即是不管 iGoGo 是何版本，其景點管理資料庫架構是一樣的，所以，只要將景點管理資料庫的資料及其索引值更新即可。
所以，iGoGo system 貢獻在系統 loading 應很微小，可是，大家有發現嗎？若將 228 版 copy 至原來的版本上使用，當資料量多時，Mio 268 反應就有差了，基本上這情形不應該發生，因為他只是一個簡單資訊瀏覽系統，若有這情形，有兩種可能原因，一是資料索引值沒有最佳化，另一是 hardware spec 過低。若是第一種原因那問題很好解決，但若是第二種原因的話，我只能說 Mio 268 可丟到海裡餵魚去，這也是我前面提到的不安的第一個因素。
【iGoGo 景點資訊】的檔案資料架構
依各縣市存放各縣市景點資料
【iGoGo 景點資訊】 執行時可能的資料架構
1. (可能性最高)用一維陣列存放
縣市別、景點名稱、景點分類一、景點分類二、景點座標值、描述、景點圖片
2. 用二維陣列存放
第一個維度是縣市名稱
第二個維度是景點名稱、景點分類一、景點分類二、景點座標值、描述、景點圖片
3. (找死)多維陣列
第一個維度是縣市名稱
第二個維度是景點分類一
第三個維度是景點分類二
第四個維度是景點名稱、景點座標值、描述、景點圖片
依 iGoGo 目前的資料量採 架構 1 較有效率, 不過記憶體的處理在陣列使用上要很小心,
否則效能會大打折扣。
個人積分：1分
文章編號：1037830
個人積分：6分
文章編號：1038078
下面將 iGoGo 的檔案架構貼上來給大家參考：
1. 下面是228 版, 與之前的差異是舊版的『 iGoGo.exe』 及 『iGoGo.ini』 是放在『My Flash Disk\MioMap\iGoGo』。另外，主程式有修改並重新 compile 過』。
2. 下面是 iGoGo 的旅遊景點目錄
3. 下面是每一縣市的旅遊景點資料庫。其中 poi.idx 是景點索引檔，poi.mpf 是旅遊景點主檔。
各位如果要 copy 新的旅遊景點資料庫, 可以先將舊版的 iGoGo_Mitac 更名成 iGoGo_Mitac_Old，然後將 228 版 的 iGoGo_Mitac 目錄直接複製到舊版的 iGoGo 目錄，
不過，我要強調的是 iGoGo_Mitac 並不是 Mio MAP 的 MAP 圖資檔, 這點大家別誤解了。
iGoGo 旅遊指南 講完，接下來我們就簡單的剖析 重點 Mio MAP，待續....
個人積分：34分
文章編號：1038103
個人積分：86分
文章編號：1038174
個人積分：6分
文章編號：1038525
有人知道 Mio 268 的 Hardware Specification 嗎？我查了 MITAC 網站及其所附的相關資料都查不到，不知有哪位仁兄可以告知？感謝！
但是，依我看來的結論，CPU 規格我不知道，可是 memory 應是 64MB Flash ROM + 64MB SDRAM。我查了一下其他家 memory 的規格，似乎這樣的規格目前是大宗的主流！高檔一點的才有 128MB Flash ROM + 64MB SDRAM，對否？若對的話，怎麼 GPS 的 memory 這麼少啊！
Flash ROM 一般是儲存硬體的韌體，process run 時所用的記憶體一般都是 RAM 或 記憶卡(or HD)，應不會有人拿 Flash ROM 當 RAM 用吧。
說到這，不知有沒有人看出 MITAC 的問題在哪？我真的已經把我推導出的原因點出來了，若我說對了，MITAC 不曉得會不會給我麼什麼樣的鼓勵？
再談 Mio MAP 前, 我先談談【iGoGo】performance 差的原因，相信下面若是真因，那至此 MITAC 應可推導出他們【228 版】performance 差的原因！各位知道 iGoGo 旅遊景點資訊的總量是多少嗎？請看下圖解答：
答案是 61 MB 左右，這是何等大的檔案啊，為什麼會這樣？大家可以想的出來嗎？原因是 MITAC 患了個錯，什麼錯？那個錯就是 MITAC 沒有把『景點的圖片』抽離出來而成一個一個圖檔，等 user 點選時再 open graphic file。依 iGoGo 目前系統的設計，iGoGo 是把景點的所有資訊包含圖片全部湊在一起，而 iGoGo system design 又在一開始執行 iGoGo 時，一次的把景點資料全讀進來，要命啊，Mio 268 才 64MB SDRAM，景點資訊就吃了 61MB，剩下的就分給 Mio MAP 及其他 process 用, 這樣 64MB 夠嗎?若不夠這時會動到什麼? 那就是 SD 卡的暫存區，SD 卡的速度，一定比不上 RAM ，在這樣 page I/O 頻繁下，各位在使用 228 版的 iGoGo 一定會感覺到頓一下頓一下，畫面的切換就沒那麼平順，這時各位若又用 228 版的 Mio MAP，各位就可以想像那速度又會有多慢。所以，原因抓到，怎麼解？那就是把圖片抽離，景點資料庫放的只是圖片 LINK 的 information，相信如此 iGoGo 景點資訊的總量一定會 down 到小於 10MB 以下，這樣再執行 iGoGo 會不會比較快，當然是像飛的一樣快！而不會有重拖的感覺！另外，坦白說，user 看圖的機率應不高，所以，要不要這樣做？當然是一定要的囉！
好啦！下課啦！相信講到此，MITAC 應可很快就解掉 228 版 performance 差的問題，靜待 MITAC 的佳音！
個人積分：653分
文章編號：1038898
