2022年10月13日星期四

Test conditions

Battery: X3 battery 1800mAh (model CINAQBT/A)

Fast Charge Hub: model CINSAAQ/A (12V/3A input is recommended)
Power bank: NITECORE NB10000 (not gen 2), Type-C output (max 9V/2A or 12V/1.5A)

Power adapter: Innergie 60C Pro USB-C (which supports 15V/3A and more)

Room temperature: 28°C

Charge 1 battery via power bank

time (min)	0	32	75
NB10000	100%		(>70%)
Battery	0%	80%	100%

NB10000

Initially, 3 LED indicator (full)
Still 3 LED indicator when charging finished

Battery

Initially, LED was flashing yellow (<80%)
LED became flashing green (>80%) after 32 minutes
LED became solid green (full) after 75 minutes

Charge 2 batteries via power bank

time (min)	0	20	46	87	93	137
NB10000	100%	70%				(>30%)
Battery A	0%		80%	100%
Battery B	0%				80%	100%

NB10000

Initially, 3 LED indicator (full)
LED indicator became 2 (between 30% and 70%) after 20 minutes
Still 2 LED indicator when charging finished

Battery A

Initially, LED was flashing yellow (<80%)
LED became flashing green (>80%) after 46 minutes
LED became solid green (full) after 87 minutes

Battery B

Initially, LED was flashing yellow (<80%)
LED became flashing green (>80%) after 93 minutes
LED became solid green (full) after 137 minutes

Charge 3 batteries via power bank

time (min)	0	18	31	75	99	144	164	210
NB10000	100%	70%				30%
Battery A	0%		80%	100%
Battery B	0%				80%	100%
Battery C	idle			0%			80%	100%

NB10000

Initially, 3 LED indicator (full)
LED indicator became 2 (between 30% and 70%) after 18 minutes
LED indicator became 1 (<30%) after 144 minutes
Still 1 LED indicator when charging finished

Battery A

Initially, LED was flashing yellow (<80%)
LED became flashing green (>80%) after 31 minutes
LED became solid green (full) after 75 minutes

Battery B

Initially, LED was flashing yellow (<80%)
LED became flashing green (>80%) after 99 minutes
LED became solid green (full) after 144 minutes

Battery C

Initially, LED was solid yellow (idle)
LED became flashing yellow (<80%) after 75 minutes
LED became flashing green (>80%) after 164 minutes
LED became solid green (full) after 210 minutes

Charge batteries one by one via power bank

time (min)	0	24	33	74	108	149	182	224	239	250
NB10000	100%	70%							30%	0%
Battery A	0%		80%	100%
Battery B				0%	80%	100%
Battery C						0%	80%	100%
Battery D								0%

p.s. After battery LED solid green, the LED would last for 30 seconds. I unplugged the batteries after that.

Charge 1 battery via power adapter

time (min)	0	32	74
Battery	0%	80%	100%

Charge hub is connected to Innergie 60C Pro
Initially, LED was flashing yellow (<80%)
LED became flashing green (>80%) after 32 minutes
LED became solid green (full) after 74 minutes

Charge 3 batteries via power adapter

TODO

2017年6月30日星期五

GnuCash 台幣小數位數

雖然新台幣最小單位是 0.01，以前也有 5 角的硬幣，但現在並不通行，在 GnuCash 中看到所有的數字都多寫「.00」實在很煩(小聲說，其實看久就習慣了)，本文說明如何讓那「.00」不見，畫面更清爽。

基本設定

各個科目顯示幾位小數是可以改的，在「編輯科目」的「最小單位」，把「Use Commodity Value」改成「1」就可以了。每個科目都要一一修改。
但還是有滿多地方會出現「.00」，譬如

各交易的金額雖然寫整數，但 cursor 移上去要修改時，還是會出現兩位小數
科目樹有些欄位還是會有兩位小數
報表

以下說明如何消除那些「.00」

1. TWD 的定義

所有貨幣的定義都在 src/engine/iso-4217-currencies.scm 這個檔案，譬如 TWD 的定義是
( "New Taiwan Dollar" "dollar" "cent" "ISO4217" "TWD" "901" 100 100 "NT$" )

在編譯的過程中，iso-4217-currencies.scm 會產生 iso-4217-currencies.c 的下面幾行

const char *fullname = "New Taiwan Dollar";

gnc_commodity *c = gnc_commodity_new(book,

CUR_I18N(fullname),

"ISO4217",

"TWD",

"901",

100);

這個檔案是 libgncmod-engine 的一部份，也就是說，TWD 的定義最終是寫死在程式執行檔裡，不是在設定檔中。

修改方法

如果是從 source code 開始 build GnuCash, 修改方法很簡單，只要把 iso-4217-currencies.scm 裡

( "New Taiwan Dollar" "dollar" "cent" "ISO4217" "TWD" "901" 100 100 "NT$" )

那行改成

( "New Taiwan Dollar" "dollar" "cent" "ISO4217" "TWD" "901" 1 1 "NT$" )

再重 build 就好了。

或是把 iso-4217-currencies.c 那個 100 改成 1 也可以。

如果是直接安裝執行檔，就比較麻煩了(譬如在 Windows)。我目前的解法是用 OllyDbg 開 libgncmod-engine.dll，找 reference 到 TWD 字串的程式碼位置前兩個 instruction

把 64 (十六進位，就是 100)改成 01。

2. 帳本存檔

程式改完把 GnuCash 開起來，會發現每筆交易的數字都正常了。但是科目樹有的欄位還是錯的，像是

這是因為早在建立帳本時，TWD 的定義也寫到帳本資料檔中了。還要修改帳本資料檔才行。

若是存成舊的 xml 格式，請搜尋檔案中 "TWD" 字串附近的 "fraction" 改成 1
若是存成新的 SQLite 格式，用 sqlite 打開存檔，執行以下指令

UPDATE commodities SET fraction = 1 WHERE mnemonic = 'TWD';

3. 報表

在稍微新一點的版本(我不確定版號，大概是 2.6 開始)，在某些執行環境(譬如 windows)，報表上的新台幣金額還是會出現小數點。

這是因為 GnuCash 產生報表時會用 locale 的設定，若抓不到(windows)就會用預設值 2。

修改方法是改 gnc-ui-util.c 的 gnc_default_print_info() 裡，
- info.min_decimal_places = lc->frac_digits;
+ info.min_decimal_places = 0;

2015年7月5日星期日

The C++ Programming Language 國際中文版第四版勘誤

其實好幾年前，大約是 Modern C++ Design 讀了一半的時候，我就放棄學習 C++ 進階技術了。倒也不是看不懂，那些技術很巧妙、確實能解決某些其他語言不易解決的實際問題沒錯，但覺得用那些技術寫程式也末免太迂迴。

舉個比較簡單的例子：用 static_assert<> 來檢查 compile time 的問題。compiler 不認得什麼是 static_assert，就乖乖的把 template 展開；視 static_assert 怎麼寫的，展開之後可能發現某 class 有問題或是陣列宣告不合語法，於是吐出一堆 template 具現化失敗的錯誤訊息。

我的意思是說，一個很 high level 的目的(也許是 static_assert，也許是判斷某個 type 是不是繼承另一個 type，或判斷 template 參數的個數……)，但 compiler 不認得，寫的人只好用一堆 low level 的東西湊出那個意圖，叫 compiler 去一堆 header 檔裡找 template 定義、template matching、推導、instantiation，層層疊疊，寫的人辛苦，compiler 也花一堆時間照做，若不小心寫錯，還吐出天書一般的錯誤訊息。整個就是事倍功半。簡直是為了解決一個問題結果製造更多問題。
(p.s. static_cast 已經在 C++11 成為語言的一部分了)

話雖如此，無論是工作還是自己寫東西自娛，我還是常常用 C++。這陣子越來越常看到有人用新的 C++ 語法，自己也開始用。雖然還不太懂整個 C++11 C++14，但就看到的部分，覺得新的 C++ 修正了許多原本的不足，也有嘗試改善前面我提到的問題。難怪有看到文章說，很多 C++ programmer 因為 C++11 對 C++ 好感度提升了。

最近看到 The C++ Programming Language 第四版的中文版剛出，就買了一本來看，想比較有系統的學學 C++ 的新東西。目前只讀了前幾章導覽的部份，覺得組織得比第三版好(其實很薄弱的印象，畢竟好幾年前讀的了)。作者 Bjarne Stroustrup 也更強調這本不是給初學者的教材，初學者應該讀他寫的另一本 Programming -- Principles and Practice Using C++。(我前陣子忘了這件事，竟然還推薦一個初學者，還好他沒聽我的話 XD)

第四版翻譯的品質沒第三版葉秉哲的那麼好。文句算通順沒問題，有些譯名不習慣還可以接受，但是錯譯不算少。讀到令人困惑之處再找原文比對，通常會發現是翻譯錯誤。整體來說，翻譯得還可以，希望出版社/譯者能花更多工夫確保書籍的正確性。原本讀中文版是想偷懶節省時間，但我查找原文比對，還做了勘誤表向譯者回報問題，最終可能沒省下太多時間 :(

以下是我自己做的勘誤表(若我有空繼續讀的話，會持續更新)
https://docs.google.com/spreadsheets/d/1d3yOOVuhAHSla6LKQLZ9QHdu1hKgGegaXO7Np5PlIV8/edit?usp=sharing
譯者在出版社的書籍網頁最下面有提供勘誤下載(err, 為什麼不是網頁，為什麼是 docx…)，目前好像都是我回報的 :P (不過譯者並沒有100%接受我的建議)

2015年6月4日星期四

nonogram 漫談 - 3 TCGA2015

之後約三年多沒再改程式，只是有時會想到一些沒機會實作的點子。今年春假時翻了幾篇最近幾年的論文，發現用 SAT solver 來解 nonogram 有好幾個突出的成果，讓我又冒出一些新想法(結合傳統 solver 跟 SAT solver 的用到的技術)，便考慮今年再次參賽。

再來就是了解現在參賽程式的發展。說到這個我就要抱怨一下。TCGA 及 TAAI 辦的比賽(我是指各項比賽，不只 nonogram)某些資訊不夠公開，譬如有時比賽規則細節從略，有時比賽結果只有名次，沒有比數或棋譜/數據，有幾年甚至連名次都很難找到。(今年的狀況似乎還可以)。雖然比賽後其實有結賽報告，但那只有訂閱期刊才看得到，且限於篇幅沒有完整的資料。我並不認為這是故意隱瞞，但我覺得這部分沒做好，其實是會間接影響這領域的發展的。

想像有個無聊的人(我? :p) 或是有個學生，對某個棋類感到好奇，說不定他本來看一看棋譜發現當下的程式不過爾爾，有為者亦若是寫個更強的，或是覺得某個課題有趣想找這幾年的冠軍討論。但實際上他上網查到的只有殘缺不全的資訊，說不定就澆息他的想法了，覺得那是一個自己玩自己的小圈圈。

也許我比較理想化，我覺得這比賽還算是學術活動，雖然各自的程式不公開，還是要盡量「可重現」(別人用一樣的機器、類似的做法，應該要有辦法做出類似的結果)。但實際上就算報名了比賽，可能還是不知道對方用什麼機器，看不到對方跟別人對弈的棋譜。

扯遠了，回到主題。我去信詢問這次比賽的規則及最近幾次的賽況，了解到今年規則大致上沒有差太多，這幾年 nonogram 的交大第一名的程式自 2011 年後也沒什麼改動。雖然我的程式還沒完成，還是先報名了 :) 畢竟對我而言有個寫程式自娛的機會，還到會場去看看這領域的進展，跟一些朋友、老師聊聊，都很有意思，比賽名次只是附帶的。

我也回頭看了一下我舊的程式，TAAI11 時，程式在第 510 題卡了 81 分鐘(直到比賽結束還沒解出來)，應該是程式有 bug 掉到無窮迴圈，而不是單純算得慢。

這回我的程式計畫是，先重構我舊的程式，實作交大論文的 fully probe, FP2, 還有 search heuristic 當作 baseline，然後再開始試驗結合 SAT solver (其實我有做點小實驗，效果還不錯)。程式檔名就叫 baseline，只是沒想到後來光最佳化 baseline 就用掉了我全部的時間。

照著論文實作的好處是，有數據可以對照知道自己有沒有誤解論文。我發現我大方向是對的，搜尋次數是一樣的，但問題出在算一樣的東西我的就是比較慢。用時間複雜度來說明就是，整個演算法是 O(a * b^n * n^c)，這是指數時間演算法，我的 search heuristic 跟論文相同，其他部分也正確，所以 search node 跟論文一樣多，也就是 b 一樣大。但是我的程式比較慢，也許是選用的基本資料結構不同造成 a 比較大，或是一些實作細節的不同 c 比較大……所以我就一路最佳化我的程式，從大約三倍慢一直改進到慢 40%。

這次的比賽結果，交大第一名，1000 題花了 908 秒, 我拿第二花了 1135 秒，第三名 3737 秒，第四名兩小時解了 232 題。只慢 20% 是因為我稍微調整了 choose weight 的參數(比較小的 b，不過我其實不是很有把握)。也就是說我的程式只有一點參數不同，其他部份其他部分跟第一名的程式沒什麼兩樣，這是比較無趣的地方(理想上大家用不同做法，百花齊放，有趣多了)。
(技術細節我在接下來的文章再談)

這次比賽花了我一個禮拜的休假，加上兩個禮拜下班後的時間。我原本都在 linux 上開發，由於比賽要在 windows 上跑，我在前兩天才開始下載 Visual Studio Express 2013，所以程式還沒有針對 windows/vc++ 作最佳化。在賽後我改用 mingw64-g++ 並調整 compiler 參數，還可以快 15%，也就是說跟第一名只差 5% 左右。所以我可以很阿 Q 的說，只要再一個禮拜就可以贏了 :P (我也試了 Intel system studio 2015 free trial 裡附的 intel c++ compiler 15.0，但沒有比較快，不過我跟 intel c++ compiler 參數也不熟就是了)

2015年6月1日星期一

nonogram 漫談 - 2

我跟 nonogram 的故事要從國中開始說起 :)

國中時有同學帶了尖瑞出版社的一本 "解題畫冊"(我忘了當時的書名) 來學校玩，那時還不流行數獨，不過就類似那感覺，每一頁就是一題，用紙筆加上邏輯推理，解出謎底的圖案。印象中那時會跟同學抄題目到自己的計算紙上玩。雖然覺得很有趣但好像沒有一直玩下去，現在回想大概是抄題、解題太累了，而且沒有跟同學競技的快感 (那時還會玩三角殺棋(當時我們叫三角棋)，幾A幾B等等)

後來在某一年(可能是 2001)的 IOI 研習營期中考題，就有老師出了一題叫「海島地圖」其實就是 nonogram ，我那時還去幫忙寫 test data 跟參考解答。後來(應該是 2003)我到建中幫忙出校內比賽的題目，就拿一樣的題目來用。當時題目要求輸出全部符合條件的圖形，我對 nonogram 的理解就是 search 題，不過並不要求大家在比賽時限內寫出任何 heuristic，所以 n 給得並不大，只要能正確的 DFS search 就可以拿到超過一半的分數，若 search 時有稍微考慮不跟相臨顏色的條件衝突，差不多就能拿滿分。程式碼約 100~200 行就可以完成。只是印象中大部分的人都拿不到一半的分數。

後來查資料才發現，IOI '92 那年有題 "Islands in the Sea" 相信就是研習營出題的來源。'92 年的測試資料最大 8*8。另外，ICPC '93 年有一題 "Scanner" 應該也算相關的題目，記得 '97 集訓寫考古題時大家都卡住，只有 lckung 學長成功解出。

大學時出現了一系列 logic 遊戲的網站，我還有一些同學有時會玩玩上面的遊戲打發時間。這些遊戲 (Nonogram, Slither Link, Sudoku, Light Up, Bridges, Shikaku, Nurikabe, Dominosa) 有些還有人發表論文研究，有幾項還成為 Computer Olympiad 或其他類似 conference 的比賽項目。 (Computer Olympiad 每年會辦許多電腦棋類比賽(西洋棋、象棋、圍棋甚至橋牌、撲克)，我偶爾會關心一下比賽了解最近發展的狀況。)

我在 2011 年時才發現 nonogram 2010 年開始有辦比賽，也就開始讀相關的論文跟網路資訊，我發現當時網路上已經有幾個很強的 nonogram solver，但是大部分的論文都沒提到這件事(也許是論文發表的時間差，譬如 BGU 2010 年不錯的成果，論文 2012 投稿，2014 才登出來已經晚了；除此之外，我是覺得有些論文，該怎麼說呢，參考價值不高)。

我當時也覺得比賽規則有很大的問題。也許是想增加競爭趣味，比賽方式是雙方互相出題給對方解。但出題是在事先準備好的，沒有資源限制，所以可以隨機產生大量題目，用大量 CPU 把簡單的題目過濾掉，只要有足夠的計算資源，我相信可以做到比賽時限內沒有人可以解出任何一題 ;)

當時我的做法就是這樣：先隨機產生幾百個題目當種子，然後用程式去解，把解得比較快的題目丟掉，解得比較慢的題目隨機改幾個顏色(黑變白或反過來)當作新的題目。然後跟朋友借一些 CPU 來跑(我忘了多少，大概有數十顆)，跑了也許一個禮拜吧。

當時覺得這比賽參賽者可能不是很強(根據前一年的賽後報告)，比賽規則又不是很公平(或說有漏洞)，所以我就報名參賽 TCGA2011 (6月)，程式取名 Naughty，就是說我是來搗蛋的 :) 從程式開始寫到比賽不到兩個禮拜，事實上比網路上抓得到的 solver 還弱，結果拿第一名。

到了年底另一個比賽 (TAAI2011, 11月)，這回我就幫忙修改比賽規則，改回單純的比賽解題速度，可是也比較無趣 (相較於其他棋類你來我往的廝殺)，往後幾年比賽的規則大致上延用。

不過半年不見，交大的隊伍重組，程式演算法大改進，這回就換我被痛宰了 XD (現在回頭看當年的紀錄，我才發現四年前他們用的電腦比今年比賽用的還快 orz 還好近幾年規則改成統一用同一台電腦跑了)

交大 2013 年也發表了一篇 paper 解釋他們的做法，有興趣寫 nonogram solver 的話值得一讀。

2015年1月11日星期日

OSM vector map - mapsforge

本文介紹 mapsforge 的 map 格式、製作、應用及相關概念。

OSM vector map

在 Android 上 OSM 的 vector map 主要有三個選擇

OSMAnd 雖然 open source 但它的 license 在 GPLv3 之上另外加了限制

Publishing applications using the OsmAnd GPLv3 code to Google Play, Amazon Market or Apple Store should be done with written permission

所以在 app 世界沒有其他人用。

maps.me (以前叫 MapsWithMe)的公司在被併購之後 app 變免費，還宣稱會在 2015 年 open source (公告)。

而 mapsforge 不是 app，它是一個 map engine library (LGPL)，所以幾乎其他支援 vector map 的 app 其實都是用它，像是 OruxMaps、LocusMap 等等。

另外，garmin gps 的地圖檔格式已被研究、公開，也有一些程式或網站可以將 OSM data 轉為 garmin gps 用(教學)。本文不討論 garmin map。

mapsforge

OSM 的資料本來就是點、線座標及文字 tag，已經是「vector」了。只是一般 OSM 資料用的 xml 或 pbf 格式只適合儲存、批次處理，不能 random access, render map。

mapsforge 將 OSM 的資料 preprocess 預先切成一個個 tile (且以 zoom level 區分)，同一個 tile 的資料連續儲存，因此 render 時就能從檔案一次把相關的資料全讀完，省下很多計算(不用考慮資料是不是太遠不用畫；在 low zoom level 的資料也已預先篩選、化簡，也不會資料量太大)。(spec)

不過 tile 裡資料要怎麼呈現、文字的擺放位置，是 render 時才根據 render theme 決定。也就是說，mapsforge 的 data model 是延續 OSM 的設計，mapsforge 並沒有區分什麼是路、房子、河流，它只知道點、線的座標還有 tag，地圖上的顏色、線條樣式都是 theme 裡頭寫的。

不少人會自己製作 map 或 theme 跟人分享，像是

各 map app 的論壇不時會有人分享
OepnAndroMaps 則是專門架站提供世界各地用的 map file
http://download.mapsforge.org/ 也有

map 檔跟 theme 檔是分開的，但兩者的內容要配對。有的人會兩個一起 share，但也常見使用現有的 map 檔，再依各人用途或喜好修改 theme 檔分享。譬如 tiramisu theme(介紹) 好像受到不少好評。

要測試作出來的 map 跟 theme，除了把檔案傳到 Android 用 map app 看之外，也可以用電腦上的 viewer (譬如 atlas)直接看，會比較有效率。

除了 mapsforge 的 map 格式有分版本(向前相容)，mapsforge library 也有分版本，新的 library 版本除了加功能、修 bug 之外，也會支援新的 render theme feature。只是大部分 app 都沒寫他用的是哪一版的 mapsforge library。依 tiramisu theme 網站的說法，現在只有 oruxmap 6.0 及少數程式用 mapsforge library 0.4 (可以用 svg icon)。2014/12 release 的 0.5 開始支援 render theme V4。

等高線

mapsforge 原先只是設計給 OSM 地圖用，並沒有考慮到等高線。但有人就想到，如果把等高線的座標寫成 OSM 資料格式，「偽裝成一般的 OSM way」，就可以用原有的地圖製作工具作成 map 檔，再修改現有的 theme 加上等高線的定義(可能像是「細黑線，某些高度用粗黑線」)，就可以有等高線地圖了。

至於等高線資料哪裡來？美國 NASA 及各國研究單位合作有免費提供全球的高程模型(Digital Elevation Data) 。DEM 的資料內容很單純，就是把全球切成譬如 90m*90m 的方格，每個方格有一個高度數值。等高線便可以透過程式計算出來。

DEM 資料集

目前大家主要是用 SRTMv2 (全球範圍的解析度到 90m，美國 30m)(有些洞，高緯度也沒有) 或衍生出來的版本。
另外有個 ASTER GDEM 析解度到 30m，但品質沒那麼好(一些文章寫的，像是 viewfinder 的 review 或是台灣某些地方「隆起」)。
viewfinder 網站有提供 SRTMv2 的修正或補全
最近 SRTMv3 (30m) 剛公開也包含台灣 http://www.geocaching.com.tw/forum/viewtopic.php?f=14&p=23107 (有部分資料從 ASTER GDEM 來)
順帶一提，台灣政府其實有做解析度 5m 的 DEM，但地理資料受到管制，一般人無法拿到，即便是國外已免費公開的解析度也一樣。

製作 mapsforge 地圖

用到的資料及工具

OSM 網站可下載每週最新的 data，但全球的資料一個檔 26G。geofabrik 有提供每天最新的台灣 OSM data extract。
osmosis 是 OSM data 的資料處理、轉換工具，支援很多格式，還能寫 plugin。
mapsforge 有提供 osmosis plugin MapWriter，可以在 osmosis 讀入 OSM data 之後，輸出成 mapsforge map 檔。
phyghtmap 可以把 DEM 資料轉為 OSM 格式等高線。還內建下載 SRTM 跟 viewfinderpanoramas DEM 的功能。
如果手邊的地形資料不是 phyghtmap 能處理的格式，可能可以用 gdal_contour 轉換。gdal 是處理 GIS 資料常用的 library/tool。

詳細的步驟有教學。

若單純只有台灣 OSM data 的話，大概兩三分鐘就跑完了。若是含等高線(每 10m 一條線)，全台灣一個檔(ram mode)大約要 8GB ram 執行 24 小時(估)。另有 hd mode，可以用少一點 ram，我沒試過。

若覺得全台灣的資料量太大，可以先用 osmosis 切成更小的區域。

台灣的地圖

前面提到的 OpenAndroMaps (OAM) 就可以下載台灣的地圖了。

geocaching.com.tw 的 Jing (也就是足跡遍布全台的圖客 JingGeocacher) 結合 ASTER GDEM 及 OSM data 自製 mapsforge 地圖。通常每個月會更新一次。手機 GPS 登山推廣計畫也有寫文章教學如何安裝、設定。

OAM 跟 Jing 的地圖的差異:

OAM 的等高線距 20m, Jing 的比較精細到 10m。
Jing 的地圖比較大(46mb vs 159mb)
Jing 有另外調過 theme，我沒跟其他 theme 比較過。
OAM 的歐洲以外的地圖更新頻率好像超過一個月

2014年1月31日星期五

OpenStreetMap 登山踏查

畫 OpenStreetMap 地圖一個很重要的活動就是到戶外走訪、搜集資料。Dennis 的投影片Osm資料收集與方法就有一些介紹。我也來分享一下我自己如何進行。

概要

帶著 GPS 記錄器行走(會自動記錄移動軌跡)，行進間看到覺得值得記錄的東西就拍照。也就是說出門時除了走路、拍照，其實並不麻煩。由於數位相機都會記錄拍攝時間，透過GPS記錄就可以知道拍照地點，回家到電腦前再根據搜集到的資料畫圖。

p.s. 畫 OpenStreetMap 的方式有很多種，有的人用紙筆記錄、有的人邊走邊用手機或平板電腦當場編輯，各有優缺點，不同狀況可能適合採用不同的方式。

攜帶物品

GPS 記錄器

可以是智慧型手機、平板、也可以是 GPS 手錶、記錄器等等。
一開始我以為登山專用的 GPS 裝置(我用的是 Garmin Dakota 20, 2009年上市)定位會比手機(定位只是附加功能)準確，但在看了網友的測試及我自己的經驗，我的結論是 GPS 晶片還是不斷在進步，新機可能更好，就算是新手機也可能比舊 Garmin 專用機強。

數位相機

由於只是要記錄景物，所以畫質、顏色什麼的其實不重要，對焦快可能有用一點(比較不會因拍照而停下太久，之後又要追趕隊友)，但差異不大。廣角鏡頭可能不錯。我自己是用一般的口袋傻瓜相機。

備用電池、行動電源、記憶卡

依行程長短而定。GPS 功能還有 LCD 螢幕很耗電，帶著以備不時之需。

一開始準備、設定

有些設定可能在家裡先操作看看，或是翻說明書。

GPS

在登山口前甚至更早一點可能就要把 GPS 打開定位，舊一點的機型或是有遮蔽的情況，定位可能要數分鐘。若太晚開起來，一開始的軌跡會沒記錄到。

我會把 GPS 的記錄間隔設為每秒記錄一次。(這會比較耗電)

數位相機

相機的時鐘很可能不準，要校正(到秒)，可是調整相機時間很麻煩。我覺得最簡單的方法是，在 GPS 定位完成後，用相機拍 GPS 機的(看得到秒數的)畫面。之後回家根據拍攝時間及畫面內容比較就知道要修正幾秒。

無論是 GPS 或是數位相機，螢幕都是最耗電的元件之一。建議可以調整螢幕亮度、螢幕待機省電的時間。有些相機甚至可以關掉 LCD 螢幕用觀景窗拍照(或是盲拍，反正取景不重要? 我自己沒這樣玩過)。

行進間

祝旅途愉快 :)

要記錄、拍些什麼呢? 簡單的原則是，你覺得標在地圖上有用的景物。除了重要的景物，也要拍四周的樣貌，才知道相對位置。除了要記錄的景物之外，也可以拍一些有的沒的，之後在畫地圖時可能可以幫助回憶。

實際要記錄的東西可以參考

Dennis 的投影片 24-27頁「要記錄什麼」有列一些
可以畫的東西很多，上官翻譯的我們標什麼說明(一般畫OSM地圖)優先順序為何
我參考「我們標什麼」，列了登山踏查的優先順序

小技巧

在遠方看到景物或叉路就先拍一張，很接近時再拍一張。這樣既補捉到四周的樣貌，也記錄了實際的位置。
有時轉身拍照，回家後忘了那是哪個方向的照片。一個方法是多拍幾個方向的照片，另一個方法是伸一隻手指向前進方向。

結束後編輯

回到家將 GPS 軌跡還有相片傳到電腦上。

修正相片時間

首先要修正相片的拍照時間，很多軟體都有這種功能，我習慣用的是 jhead。

譬如相機記錄的拍照時間是 9:44:47，但拍到的 GPS 畫面是 9:42:31，就表示相機快了 2 分 16 秒。就可以執行

jhead -ta-0:02:16 -ft *.jpg

將全部的相片時間往前調 2:16。其中 -ta 表示要調整多少拍攝時間， -ft 表示將相片的檔案時間也改成拍攝時間。更多參數及功能請自行參考 jhead 的網頁。

編輯

我使用的 OSM 編輯器是 JOSM，它可以修剪、合併 GPX 檔。也可以把圖檔或是目錄拉到 JOSM，在地圖軌跡上顯示拍照的地點。

我就不在這詳細介紹 josm 操作了，可以參考OpenStreetMap教學。

p.s. JOSM 其實也有修正相片時間的功能，但它主要是依軌跡位置估時間來修正。我還是喜歡自己用 jhead 直接依時間差修正。

安全第一

一些爬山該帶的東西別忘了(飲水、雨具、手機)，出門前最好讀過其他人的旅遊記錄、地圖。為免 GPS 收訊不好或運作異常，最好也帶著紙本地圖、指南針。
注意如果用手機當作 GPS 記錄器，可能會把電力耗盡，導致無法打電話。

其他

這是我整理的，畫登山地圖比較常用到的 OSM Hiking tags。

2013年6月28日星期五

如何在網頁上放 OpenStreetMap 及 GPX 軌跡

本文分享兩個主題

如何放單純的地圖(可互動操作)
如何在網頁上放地圖並顯示 GPX 軌跡在地圖上

如何放單純的地圖(可互動操作)

連到 http://www.openstreetmap.org/
點選畫面最上面的 "Export" 功能
用滑鼠拖拉地圖區域
選擇格式

OpenStreetMap XML Data, 這是 XML 資料檔
Map Image (shows standard layer), 這是下載成圖片, 有 png,jpg,svg,pdf 格式
Embeddable HTML, 網頁的 HTML 語法 --- 選這個，系統就會給你一段 <iframe 開頭的 html 碼

譬如這段 HTML


<iframe frameborder="0" height="350" marginheight="0" marginwidth="0" scrolling="no" src="http://www.openstreetmap.org/export/embed.html?bbox=118.05,20.8,124.63,26.26&layer=mapnik&marker=23.97120,121.21765" style="border: 1px solid black;" width="425"></iframe><br />
<small><a href="http://www.openstreetmap.org/?lat=23.53&lon=121.34&zoom=7&layers=M&mlat=23.97120&mlon=121.21765">View Larger Map</a></small>

會產生這樣的地圖:

View Larger Map

如何在網頁上放地圖並顯示 GPX 軌跡在地圖上

這比較複雜一點，我的方法是用 leaflet 這個 library 來畫地圖。 leaflet 可以加 plugin，配合 leaflet-gpx，就能畫 GPX 軌跡。

我參考作者的 demo，簡化之後：

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.1/jquery.min.js"></script>
<script src="http://kcwu.csie.org/~kcwu/geo/leaflet.js"></script>

<script src="http://kcwu.csie.org/~kcwu/geo/leaflet-gpx/gpx.js"></script>
<script src="http://kcwu.csie.org/~kcwu/geo/osm-gpx.js"></script>

<style type="text/css"> @import url('http://kcwu.csie.org/~kcwu/geo/osm-gpx.css');</style>
<section id='gpx_container' class=gpx ></section>
<script type="application/javascript">
    simple_gpx($('#gpx_container'),
            "http://kcwu.csie.org/~kcwu/geo/gpx/20130518 鷹仔尖.gpx",
            { title: '20130518 鷹仔尖.gpx', height: 400 });
</script>

上面這段 HTML code 可以做出下面這樣的地圖

使用說明：

一般使用只要改 simple_gpx 那三行就夠了，剩下不用動。
用到的檔案只有 osm-gpx.js 是我寫的，於 public domain 釋出。其他檔案是各 project 自己的(BSD或MIT授權)，可自由使用。
若同一頁會用多次，gpx_container 要改成其他名字(不能跟其他的重複，不然會錯亂)。前兩行(jquery.min.js 跟 leaflet.js)總共只要寫一次就好。