誠懇的呼籲希望有大大能出面寫一個程式能將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做一次轉換.
關於座標轉換, 討論區內已有許多先進談論, 在此不多做贅述. 可自行參考
關閉廣告
文章分享
評分
評分
複製連結

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