誠懇的呼籲希望有大大能出面寫一個程式能將PAPAGO和MEM的地標作一整合!!

版上有大大將一些商店和測速照像機的PAPAGO地標整理出來...

而MIO網站上也有將一些風景名勝地標整理出來..MEM可以用..http://www.mio-tech.com.tw/downloads/default.htm

如果能將兩組地標能互相轉換的話..那真的是太完美了..可以造福廣大的市井小民...

覺得以版上臥虎藏龍的態勢..寫的一小小的程式轉換應該不會太難!!
問題是!誰會去花白工,幫這些商業軟體附加功能?
出了問題不問官方卻到處上網問網友! 這就是現代人處理問題的思維?! 怪怪!

superlee wrote:
問題是!誰會去,幫這些商業軟體附加功能?


這不叫花白工吧!
你想想,板上這麼多人幫 PAPAGO 作美化
常有人搞到三更半夜,為的就是幫商業軟體美化
然後跟板上朋友分享!

一些景點分享的網站提供的景點下載多少也有兩三套軟體專用
是不是花白工,見仁見智吧!
如果真有朋友做出來了,記得跟我分享一下!
角度不同 看法不同

>>這不叫花白工吧!
>>你想想,板上這麼多人幫 PAPAGO 作美化
>>常有人搞到三更半夜,為的就是幫商業軟體美化
>>然後跟板上朋友分享!

我稱這為個人興趣,為的是讓自己爽!不管是成就感的爽..還是自己用的爽..就是一個字..爽..
分享..是一種美德..重要的是..也得要自己爽..這跟白工還是黑工沒關係..
誰會不爽的專門在幫商業軟體做美化然後又分享出來?有..他們自己公司員工..但似乎美術不夠強..要不然就是..俗語叫心不甘情不願..

>>一些景點分享的網站提供的景點下載多少也有兩三套軟體專用
>>是不是花白工,見仁見智吧!
>>如果真有朋友做出來了,記得跟我分享一下!
景點分享的網站..部分..有其商業利益的考量..能夠滿足越多不同族群的客戶..自己才能夠賺到越多的錢..這是我的見智..
當然網路上也有很多能人異士願意無私的奉獻,而我相信也有人應該做出來了,剛去看了一下格式,覺得SYC的似乎還OK..另外那個POI就可能要再深入研究一下了..所以..還是多等等看吧..看看這個版上是否真的有龍有虎的 很簡單的做出來 不然就辜負了臥虎藏龍的名聲?還好我只是一個無名小卒..不需要為了名聲強出頭..
又還好我只用mapsource..沒那麼多煩惱..
話說回來..MIO GPS最近有不少新的專利正在申請中..動作還蠻大的..雖然在跟他們內部的工程師meeting的過程中..發現有些是騙吃騙喝的..但有幾個人的還真的不錯..
Vedfolnir
如果我有能力,我也願意來改,可惜力不從心啊!
就是這樣.喵.^_^現役NISSAN TEANA 250XL =180匹+23.2kgm/rpm
>>版上有大大將一些商店和測速照像機的PAPAGO地標整理出來...
>>而MIO網站上也有將一些風景名勝地標整理出來..MEM可以用..http://www.mio-tech.com.tw/downloads/default.htm
>>如果能將兩組地標能互相轉換的話..那真的是太完美了..可以造福廣大的市井小民...
>>覺得以版上臥虎藏龍的態勢..寫的一小小的程式轉換應該不會太難!!


剛好我正在寫一個這樣的轉換程式, 打算在過完年後po上來的, 沒想到己有同好先提出, 只好提前曝光(程式還沒編譯完成, 請先看內文解解饑吧:)).... (先聲明, 我不是任何一家導航軟體廠商的員工, 也沒有任何商業利益行為, 就如同樓上的鄰居所說, 這只是個人興趣啊! 不要要求太多囉... 這些POI檔的格式, 都是一個byte一個byte去找出規則研究出來的, 主旨在方便不同品牌的使用者之間交換地標檔啦!)

目前第一版的程式主要在轉換PAPAGO v7與MEM v8兩者間的POI檔. 有pc版及ppc版.
希望之後改版時, 能把RoadEasy及MobileMap的格式也加進來.
由於這些內容都是 "實驗" 而來, 可能與原廠商所設定的內容有些許的差異. 因此本著Unix的精神, 歡迎大家一起來研究, 分享給大家啦...

另外, 在沒有任何商業利益的情形下, 本文及程式僅作為研究及自行使用. 若影響內文所提到各廠商權益時, 請版主大人自行定奪, 該刪就刪吧.

不過, 在實作階段發現, 各家的座標系統仍有部份差異, 目前正在找尋這些差異的校訂方法.

先大略說明各個檔案的poi格式好了, 這樣方便眾家高手開發更便利的地標轉換程式:
=========================================================
MEM v8
-------------------------------------------------------------------------


以上圖為例 (用UltraEdit開啟MEM的POI檔):
00h-02h, 是儲存這個POI檔裡共有多少筆資料, 本例為02 00 00, 即兩筆資料. (附註, 02 00 00 = 02*16^0 + 00*16^1 + 00*16^2 = 2 (大概一個poi檔最多可以存放256^3筆資料)
03h, 這個 01 不太清楚是幹什麼用的. 暫時先不管.
從04h-13h是第一筆資料的檔頭
04h-07h, 代表第一個航點的 TM2.Y. 本例的 74 76 2A 00, 依前例計算方式, 換算成十進位是 2782836.
08h-0Ah, 24 00 00, 代表第一個航點的資料 (如名稱, 地址, 電話...等) 從第24h位置開始記錄 (亦即本例的 04 0A 77....)
0Bh, 00, 表資料結束位元 (以下沒有特別註記的, 都是同樣意思, 當成分隔符號看就對了)
0Ch, 72, 代表第一個航點的類型 (本例72為 "我的最愛". 從70-7F共16個, 分別代表"導航點"到"其它航點"等16種不同的類型)
0Eh, 5C, 代表第一個航點資料的長度 (本例5C, 表示第一筆資料的內容, 從24h開始, 長度5Ch, 也就是到7Fh (可由24h+5Ch-1h=7Fh得到驗證))
10h-13h, 代表第一個航點的 TM2.X. 本例的 91 85 04 00, 依前例計算方式, 換算成十進位是 296337.
從14h-23h是第二筆資料的檔頭
:
24h-25h, 暫時還不知道是什麼, 不過, 好像沒什麼影響!?
26h-2Fh, 一直到 00 00 為止, 存放第一筆資料的名稱. 由於它採UniCode方式儲存文字, 因此每二個位元表示一個字 (無論中英文). 本例中, 77 6D 85 60 27 59 13 6A, 代表四個中文字 "海悅大樓"
30h-4Fh, 一直到 00 00 為止, 存放第一筆資料的地址. 本例中, F0 53 .. .. 5F 86 00 00 , 代表十五個中英數字. 請有興趣的同學試試看吧.
50h-6Dh, 一直到 00 00 為止, 存放第一筆資料的電話. 本例中, 28 00 30 00 .. .. 39 00 00 00 , 代表十四個中英數字.
6Eh-7Fh, 一直到 00 00 為止, 存放第一筆資料的備註. 本例中, 4E 00 .. .. 2E 00 00 00 , 代表八個中英數字.

而從80h起, 長度8Ah的資料, 就是第二筆資料的內容. 因此80h+8Ah-1=109h, 也驗證了這個POI長度為109h, 檔案長度正確...

先吃飯去了, PAPAGO的POI檔案解析, 等會兒再來po...
這..............學長,你太強了啦!...........
感謝學長鼎力相助,感謝........謝謝謝謝謝謝謝謝謝.........

不過我有一件事很好奇,想請問一下前輩。那就是ASCII字碼前輩是怎麼比對出來的?因為有時候自己也想學一下修改ASCII字碼(因為要翻釋成中文的關係……),就是不知道要怎麼找出字碼和程式內文字的相關性?不曉得前輩可不可以露兩手教教我們這不成材的學弟呢?謝謝......感謝中.........

看到這堆碼 忽然想到以前國小時 為了玩遊戲 沒日沒夜的在改遊戲的日子
整天都活在一堆蟲跟0~F的世界中..雖然對玩遊戲的本質好像本末倒置了..
感謝Cupid大大~期待後續的解析中...

另,個人見解的提外話,純佔用版面寫寫感想,自言自語中..我對所謂的分享精神..無法抱持著樂觀態度..雖然本人是支持..但在所謂的專利權陰影下,我又不曉得所謂的分享精神能否長存?雖然軟體目前還是以著作權的方式,存活在法律的保障下,但在美國又好像可以單純的保護某程式碼片段?我是沒深入研究啦,純粹個人觀點!換句話說..不就等於以後共享軟體所能使用的資源會越來越少?難道真的還是得一廠獨大?有錢的稱大老?呵呵..
續 POI 檔案格式解析
=========================================================
PAPAGO v7
-------------------------------------------------------------------------

以上圖為例 (用UltraEdit開啟PPGV7的POI檔):
00h-3Fh, 是PPGV7的POI檔頭. 每一個POI檔都一樣, 應該是註明這個POI檔所產生的原始PPG是何版, 如本例為PAPAGOV7 052004.
接下來, 和MEM不同的是, PPGv7採用未壓縮的資料庫模式. 也就是說, 每一筆資料的長度是固定的. 這對程式開發人員來說比較容易處理, 但對使用者而言, 無形中就浪費了許多儲存的空間. 而MEM則採用不固定長度的記錄方式. 當輸入的資料 (名稱, 地址, 電話, 備註) 越詳細, 則該筆資料越長. 以本例而言, 同樣只存二筆地標資料, PPG就需要260h的長度 (含檔頭), 而MEM只需要110h.

從40h-14Fh是第一筆資料的內容 (PPGv7每筆資料長度固定為110h, 由(LOF()-40h)/110h可算出資料總筆數). 如本例的LOF()為260h, 總筆數則為(260h-40h)/110h=2
40h-43h, 代表第一個航點的經度. 本例的 64 B0 3E 07, 依前例計算方式, 換算成十進位是 121548900, 表示此地標在E121度54'89.00"
44h-47h, 代表第一個航點的緯度. 本例的 5E 1A 7E 01, 依前例計算方式, 換算成十進位是 25041502, 表示此地標在N25度04'15.02"
48h-c5h, 代表地標名稱 (每二個位元表示一個中英文數字, 如本例的 7763, 4B90... 也是UniCode, 高低位元要互換-> 6377=捷, 904B=運, 以此類推)
c6h-c7h, 結束位元, 等同分隔符號, 無義.
c8h-147h, 代表地標的備註 (每二個位元表示一個中英文數字, 如地標名稱的解釋)
148h, 2C, 表示地標的類型 (本例為旗標) (28:家人, 29:我的最愛, 2A:機密, 2B:未知, 2C:旗標, 2D:測速照相機, 2E:其它點)
149h, 01, 表示是否播放語音 (00=不播放, 01=播放)
14Ah-14Fh, 00 00 00 00 00 00, 一筆資料結束.

----------------------------------------------------------------------------
同理, 第二筆資料是從150h-25Fh, 第三筆資料是260h-36Fh (本例圖只有二筆資料), 以此類推.
續 地標轉換的差異性探討
=========================================================
資料欄位及地標類型
-------------------------------------------------------------------------


由上圖可知, 在不同的系統中, 各家工程師所定義的地標類型及資料欄位都不盡相同.
PPG: 名稱, 類型, 備註.
MEM: 名稱, 類型, 備註, 地址, 電話.

我個人的想法是, 若由PPG->MEM時, 則直接將MEM的地址, 電話欄位留白即可. 而地標則以上圖的顏色方式來對應.
由MEM->PPG時, 若MEM的地址及電話有內容, 則寫入PPG的備註欄內. 超長的部份則裁去不取. 而地標類型中間一堆白底的, 則對應為PPG的 "未知" 類型.

=========================================================
座標格式的差異性
-------------------------------------------------------------------------
舉PPG的第一個地標來看:
PAPAGO是以經緯度做為儲存格式 (64 B0 3E 07, 5E 1A 7E 01) (E121度54'89.00",N25度04'15.02"),
而MEM是以UTM做為儲存格式(91 85 04 00,74 76 2A 00) (296337,2782836)

因此在做座標格式換算時, 需將TM2.XY與WGS84.EN做一次轉換.
關於座標轉換, 討論區內已有許多先進談論, 在此不多做贅述. 可自行參考
文章分享
評分
評分
複製連結

今日熱門文章 網友點擊推薦!