敝人在 2013/08/04 於臺北國際會議中心舉辦的 COSCUP 2013 發表的一場演講，分享過去一年狂熱的從事登山運動中，使用的開放原碼軟體與公開資料等經驗。
開放街圖 (OpenStreetMap) 是一個由全球羣眾所共享、共治與共享的草根性地圖圖資，與傳統圖資的的差異性在於你可以主動輸入地圖資料庫，並在顯示時決定那些資料要顯示出來。例如開放接圖有志工輸入了高壓電塔，你可以在地圖上看到整條高壓電塔線路走向，提供了更多路線的參考資訊。又例如山友常常走過一些日據時代或原住民部落遺址，那些因為政治權力變遷而被取消或被統治者改名的地名，也可以在開放街圖重新被顯示出來，而不至於遭到遺忘。
開放街圖使用開放的授權，可以免費做各種運用。在這份簡報中，我介紹如何透過開放原碼軟體與工具，進行登山行程的規劃與分析，以及如何將開放街圖的資料匯出成 Garmin 可以使用的圖資檔，以便進行海外行程的時候，可以有基本的登山圖資作為參考。(目前使用 DEM 圖資精度只有 90m)
進一步瞭解 Open Street Map 請參考 2012 開放街圖研討會。
2013 年 8 月曾經在 COSCUP 分享過以開源軟體與開放街圖規劃登山行程，那時介紹利用開放原碼軟體的 Viking, JOSM 等，可很方便規劃登山行程，特別是 OpenStreetMap 不限制圖資類型的特性，上面的資訊十分多元。像是許多景點、地形、告示排、高壓電杆等，都可以再匯出成 Garmin 圖資檔案時，加以保留。OpenStreetMap 的圖資豐富程度甚至不輸商業圖資。
不過從稍早的使用經驗發現，由於 OepnStreetMap 查找地名時，是利用 Nominatim 資料庫。而 Nominatim 資料庫是彙整資料庫的 Key:name 而來。早期並非所有的山嶽名稱都已經登錄於 OpenStreetMap, 以至於實務使用時，常常無法查找出山嶽名稱。而查找地名是電子地圖最基本的功能，無法搜尋就無法順利找到等高線圖、或是週遭路徑，絲毫沒有可用性。因此建立鄉、鎮、市、區、知名地名是提高 OSM 可用性，最重要的工作之一。
於是我決定大量匯入山嶽資料，目標是至少補齊百岳、小百岳 (兩個版本) 的山嶽頂點的資料。參考資料是利用台灣登山補給站的山友小花 (莊錦豐)、大鵬大哥 (7777) 、 millerliu 等等山友合作，實際踏查所整理出來的基石資料庫。2013 年 10 月陸續整理將原本的 Microsoft Excel 轉成 CSV 檔案，台灣共有四千七百多座三角點，以及將近七千五百座的基石。由於基石中不少不是山頂，於是程式只將 “山”, “岳”, “尖”, “峰”, “嶺” 結尾的山名上傳。總共新增或調整了 3192 筆山名。
“Oepn Street Map Batch edting via API” 是 2013 年 11 月 SotM Taiwan 2013 開放街圖研討會 時，臨時整理出來投閃電講的簡報。
目前已知問題
優先待辦事項
2013/12/23 的時候，開放街圖社群有一場線上討論會，與 kcwu 討論批次匯入資料的規則，為了留下紀錄供社群未來參考，特別再發一次佈告.
如果您發現任何開放街圖上的山嶽資訊錯誤或是疏漏，歡迎指教。
大約是 2008 年的時候，為了 OpenStreetMap 活動，跟著 KaLUG 團購，一起買了 HOLUX M-241，當時大部分行動裝置並沒有內建 GPS，只有某些高單價的 PDA 有全球定位系統功能。相對 M-241 在當時的市場性價比很高，使用 MTK 技術，很驚訝居然到目前為止仍持續銷售。
實際使用上經歷一些技術問題
後來又陸續買了 Garmin Dakota 20, Nokion AW100, 智慧型手機 iOS, Android 等等包含 GPS 功能的裝置來紀錄軌跡。
這篇文章分享一些個人對於衛星定位系統的理解，希望可以幫助其他朋友採購的作為參考依據。
這幾年的 GPS 裝置的入手價格越來越低，參與 OpenSteetMap 的門檻也越來越低。有些朋友想購買新的 GPS 裝置，來紀錄踏查軌跡，到底購買的時候要考量哪些產品條件？
以下是我認為構成一個好產品的評估要件
這些條件取決於產品定位與設計。當然，準確性是最主要的評估要件，而硬體本身就是最大的侷限，從技術面來分析，大約可以分成下面幾項
以下逐一討論。
從過去 GPS Receiver Chip 通常是一棵獨立的元件，到現在行動裝置流行的市場，衛星定位系統已經逐漸變成整合進 SoC 的基本功能。衛星定位系統 (Satellite navigation) 遠在約 20,000km 以外的衛星軌道，定位訊號廣播穿送到地表後，強度約在 -125dBm to -130dBm.
在接收到衛星傳送的導航資訊之後，接收器會得到以下的資訊
在訊號抵達地表成功判讀前，有許多原因會造成誤差，其中天氣與量測環境是最容易影響收訊的因子
這些 RF 誤差需要再處理，像是常見的因為建築物或地面造成訊號反射誤差，可以用 Narrow Correlator Spacing 來處理，大氣效應產生的電離層誤差也可以透過韌體來做修正。
然評估晶片效能，優先考慮的是靈敏度 (Sensitivity)，感度越高，越能處理微弱的訊號，在室內或遮蔽時有顯著的差異，另外新型晶片設計也可以抑制多重路徑誤差，提高準確度。
衛星系統會發出數種無線電訊號頻道，這些頻道各帶有不同的資訊。要完成定位功能，只需要 L1, L2 頻道。L1 頻道中帶有捕獲碼 aka (C/A, Coarse/Acquisition Code) 與測距碼 (P碼)，若支援 L2 頻道之資料，則可計算出電離層全電子含量（Total Electron Content, TEC) 所造成的延遲，或是使用於 OPUS 等 GPS post-processing service 系統提高定位準確度。
但受到美國軍方管制，一般民用定位系統只支援 L1 (1575.42Mhz±5MHz, GLONASS 1602±8MHz)。但即便無法對 L2 解碼，民間定位系統仍可以分析載波 (carrier wave) 的方式進行即時動態測量 (Real Time Kinematic correction)，估算大氣效應誤差。因應民用需求，2005 年後，新的 Block-IIR-M GPS 衛星會送出 Civilian L2 (L2C) 訊號，但要到 2016 年後 Next Generation Operational Control System (OCX) 才正式啟用。
上述系統談的是美國 NAVSTAR Global Positioning System (GPS)，在 2013 年四月前，全球定位系統只支援 NAVSTAR，但現在市場已經有 Russian 的 GLONASS 系統可用。另外在 2020 年還有中國的北斗衛星導航系統、歐洲的 Galileo 系統。現在新款的晶片也可以支援 Multi-GNSS，市面上的手持產品有 Garmin eTrex 等，至於手機產品如 Qualcomm Snapdragon 400 等也同時支援 GPS 與 GLONASS.
更新頻率 (Update rate /Fix Rate)，這是指從感應晶片傳來的定位頻率有多高， 通常是一秒 1 點到 10 點間 (1-10 Hz)，例如 M-241 可程式化成 1 到 5Hz. 一般登山步行一秒一點很夠用，但是如果你用來紀錄賽車或無人飛行器軌跡，就會發現精度不足囉。
另外一個值得考慮的是晶片可以支援的處理頻道數量，理論上只要三個衛星就可以計算出平面定位，取得四顆衛星能取得 3D 定位。也就是說，裝置最低需要同時處理四個 L1 頻道訊號。但是在成功取得定位前，裝置必須搜索所有可能訊號，以找出最接近的衛星，在首次定位前，同時間能夠處理的衛星訊號數越多，首次定位也就越快、越省電，定位之後也能有效率的鎖定衛星訊號。以前只有美國系統，加上地表角度，天空最多同時可以看到一打以內的衛星，所以大概只需要十二組頻道。但是若加上俄國等系統，你也就需要更多的「處理頻道」。
簡而言之，處理頻道的益處是減短定位時間、減少因遮蔽失去訊號的機會、提高省電。但必須認識的是，處理頻道是很容易誤解的銷售詞彙，各家廠商定義不同。要注意產品規格上說的處理頻道是支援 L1, L2, 那些衛星系統、哪些輔助定位系統。千萬小心那些灌水的數字。
除了晶片性能外，另外一個嚴重影響接收能力的是無線射頻接收設計，衛星訊號在抵達晶片前，會通過天線、射頻前端模組等，然後才會轉成中頻進到數位處理的階段。
由於全球定位系統的頻譜位於 VHF 頻段，與 ANT、電信網路、藍牙或無線網路不同，使用獨立的接收天線，在小型的裝置上常見使用平板天線 (patch antenna)，專業一點的手持裝置則可能選用四臂螺旋式天線 (Quadrifilar Helix Antenna)，看起來像是傳統黑金剛的大型天線，收訊效能比平板天線好。
不同的天線設計造成優劣有別的增益效果，不過技術演進使晶片感度大幅提昇，處理訊號反射誤差等等能力提高，在開闊環境效能可能十分接近，但是若是大樓林立的都市環境或樹林中，才會看出明顯差異。有些手持式衛星定位系統甚至保留外接接頭，可以外接主動式天線來提高收訊效果。例如裝於汽車上，為了避免車廂金屬屏蔽，可以拉線到車輛外面，但必須注意天線的線路會因為長度增加增加衰減。
通過天線進入射頻前端模組時又可再分成以下幾個元件來評估。
通過天線，進入 RF Front end 後會依序進入上述元件進行訊號增強、過濾、轉換，但這些元件皆已經高度模組化，使用者很難從外觀去判斷性能差異或是進行客觀的評估，畢竟缺乏測試設備，也難以獨立的對每個元件進行測試，但是只要其中一個元件設計失誤，就會影響使用效能。特別是整合到電路板上後造成的訊號干擾問題，在在考驗製造商的工藝技術。
前提是製造商願意重視數位定位的性能。由於目前在智慧型手機，許多使用者的用途都是在室內打卡、查詢附近路徑，大部分的時候只要壟統的位置資訊即可滿足，更重要的是電話通信的訊號必須良好。也因此衛星定位的天線的優先值總是被排到最後，而且依照市場需求，外型是消費者採購的優先考量，為了配合機構設計，天線可能會移到勉強可用的位置。也因此，有些手機必須手持螢幕朝向臉部才能夠成功定位。
甚至有些產品是沒有經過嚴謹測試就上市了。像是 2012 年推出的 ASUS Eee Pad Transformer Prime，大膽採用金屬外殼，結果導致 GPS 功能無法接收訊號失效。
金屬會屏蔽電波訊號，請不要再弄清楚手機天線位置前隨便安裝金屬製造的外框阿。
談完了基頻處理的硬體，接下來來談談韌體。全球定位系統有許多可以縮短定位時間或提高定位精準的技術，這些技術並非全部在韌體中，也可能以軟體導航實作，許多技術也需要依賴硬體的資訊才能完成。以下逐一討論
Assisted-GPS 或 A-GPS 是第一個最容易讓人混淆的的名詞了，最基本的概念是不從衛星抓取衛星星曆 (Almanac) 與星曆表 (Ephemeris)，而是透過 IP 網路或離線取得可用的星曆資料，甚至透過其他技術預先取得大致位置，再利用此粗估位置推算可見衛星，避免緩慢的猜測行為，如此就可加速第一次定位的時間。
若沒有預先快取的星曆資料，就必須等待定位時透過衛星訊號下載，如此會增長第一次定位時間。若關機一段時間，星曆資料已經過期，也必須重新下載 (cold start)。
容易令人混淆的是在電信網路協定中，除了使用 TCP/IP 最多採行的 OMA 協定 “Secure User Plane Location” (SUPL) aka Mobile Station Based 外，還有另外一種 Mobile Station Assisted, Control Plane Protocol 則是透過基地台計算行動電話位址，然後將位址資訊傳送回手機。這兩種技術是完全相反的。
除了透過電信網路的協定外，另外一種作法是網路輔助定位 (network-assisted positioning)。在 Android 的 GPS HAL 中，你也可以發現有 XTRA 支援的 API，可以透過網際網路下載星曆資料，然後再透過其他的 Geolocation 系統透過 WiFi ESSID 或 Cell ID 取得約略位址，餵回給 GPS 以加速定位速度。然而 XTRA 是 Qualcomm 的技術，其他晶片廠商各有不同的作法，如 MTK 則叫做 EPO (Extended Prediction Orbit)。在有線上資源的加持下，手機在首次定位的速度常常贏過手持式 GPS 裝置。像是 Garmin 的裝置，若你拜訪另外一個國家，它常常會只利用上次使用的快取搜尋衛星，導致非常第一次定位非常久。
協定與方式不同，但是都是透過線上網路取得星曆與粗略位置。也有產品是使用離線星曆的方式，像是我手上持有的 Nikon AW100 三防相機，就支援離線 aGPS，Nikon 的星曆只有七天，每七日得重新下載進 SD Card，並從相機選單中更新資料至衛星定位模組。
全球衛星導航增強系統 (GNSS Augmentation System) 是利用差分全球定位系統 (Differential GPS, DGPS) 技術，簡單講是在地面設立數個參考基站，由於基站位置是固定的，因此可以透過差分改正（Deviation Correction) 推算大氣延遲、時鐘漂移 (clock drift)。這種增強系統又分為衛星式系統 (satellite-based augmentation system, SBAS) 與陸地系統 (Ground-based augmentation system, GBAS).
衛星式系統又稱為 WADGPS, wide-area DGPS，是將陸地基站的資訊再透過衛星廣播出去。其中比較知名的是歐洲 European Geostationary Navigation Overlay Service (EGNOS)、日本的 Multi-functional Satellite Augmentation System (MSAS)、美國的 Wide Area Augmentation System (WAAS)，像 WAAS 為例子，可以定位到平面 1 公尺、垂直 1.5 公尺 的精確度。
由於使用的頻段一致，可以以韌體實作不需要額外的無線接收硬體，不少產品支援 WADGPS。至於陸地系統 (Ground-based augmentation system, GBAS) 使用的頻譜不同，一般民用消費性產品並不支援。
另外一個有顯著差別的是慣性導航系統 (Inertial navigation system)，由於定位時時常會通過林木遮蔽處或隧道等環境，此時會遺失衛星訊號，部份系統的作法是在重新取得定位前，不予紀錄。但是也有作法是利用利用輔助感應器 (Sensors) 的情報來做航位推算 (Dead Reckoning, deduced reckoning)。
一般在定位系統或智慧型手機上常可看到以下感應器
這些感應器可以提供高度、方向、加速度、角速度、速度等移動資訊，透過這些資訊即可以慣性推算運動的位置。當然準確度是很可疑的，但是可以作為暫時遺失訊號的備用機制，彌補無法錄記軌跡的問題。部份民用衛星定位系統支援慣性導航功能。
市面上的產品大致可以分為三類
若要購買專門的器材，第一優先依照使用需求購買，市面產品多樣，有適合方便跑步紀錄的手錶、自行車等專用產品，產品大小對於運動類型有很大的影響，某些自行車專用可以順便紀錄踏頻、輪圈，都已經整合妥當，使用起來也比較方便。特別注意某些舊款產品能收的處理頻道較少、或是沒有數位羅盤功能，這都會造成定位較慢或不容易使用。像是 HOLUX M-241 就沒有數位羅盤，功能中的行進方向是透過軌跡計算出運動方向。
如果會進行兩天以上深山的行程，可能會進入濃霧、大雨的惡劣氣候中，而且無法當天撤退，筆者建議購買防水的手持式衛星導航系統，最好是附有四臂螺旋式天線的產品。因為在山中，必須用到衛星定位系統就是視線不良，無法透過地圖判讀與目標定位的時候。特別是天候狀況不佳、攸關性命時，更不想依賴可能進水損壞或只有特定角度收的到訊號的裝置。
若是輕鬆且避開惡劣天候的行程，手機可以取代大部分的 GPS 功能，而且性能強大，撥看地圖效率遠比傳統手持定位系統好。無論是 MTK 平台或是 Qualcomm，衛星定位功能皆已整合，Qualcomm 平台宣稱可以精準至 2 公尺 (應搭配 WADGPS) 精確度與省電比起兩三年前大幅提昇許多。但是購買時，仍須注意產品的無線接收設計，如果以性能為優先考量，就別考慮好看的金屬外殼機種吧。
使用上必須注意的是手機有數種定位方式，可以透過網路 (WiFi, Cell Id) 或是 GPS 訊號，但由於 GPS 訊號往往定位較慢且耗電，許多開發者會使用預設的網路定位方式，這會造成切換電信基地台或收到其他無線網路基地台時，產生漂移的問題，也因此我們會看到迷路的悲劇。若要導航使用，建議使用專門的軟體，像是 OruxMaps，功能強大也可以預載離線地圖，以免沒有網路可存取線上圖資系統。
除了參考本文寫的各項要點外，在購買的時候，規格上常常會寫一些令人困惑的精確度，例如 Garmin Dakota 20
<10公尺,95%、RMS、Typical，無S/A干擾下，單機定位
這是指，這個測量有 95% 的信心度，RMS 指大約有 63%-69% 是在十公尺之內的精確度。無 S/A 干擾指無美國的誤差干擾 Selective availability，這項干擾措施已經於 2000 年 5 月停止，單機定位指沒有利用 DGPS 的定位增強系統定位。這個測試應該是在開闊區域進行，若進入如在深谷中，由於收到訊號的角度太窄，更容易產生計算誤差，要小心地形所造成的誤差，不能只看表面規格。很遺憾，市場上沒有手機在規格上標明衛星定位精確度。
另外則是紀錄軌跡的精度功能，其實一般通用的 GPX (GPS Exchange Format) 檔案格式可以包含精度情報，例如定位的類型 (fix) 是 2d, 3d 還是 DGPS, 收到幾顆衛星 (SAT), 精度因子 (Dilution of precision, DOP) 等。定位時可能產生的錯誤太多，就算可以收到數顆衛星資訊，推算過程中必定產生誤差，精度因子是透過衛星的位置算出可能的錯誤範圍，藉此可以得知該軌跡點的可信賴度。
仍而一般戶外休閒用手持衛星追蹤裝置並未提供此資訊，另外在手機，如果直接使用標準程式界面，精確度也會被轉換成以公尺為距離的誤差。能夠取出完整資訊的只有 NMEA 格式，但 NMEA 需要再次被處理過才好分享給其他軟體使用。
無論是使用手機或專門導航系統，記得要多帶電池。多日行程也請攜帶紙本地圖與指北針。電子產品有可能失效，而多個小事故累積起來往往會產生悲劇。
經過連續四次的每月線上技術會議 (Webinar #1, #2, #3, #4) 後，二月決定移師台北外出走走，mcdlee, Louis Liu 兩位資深志工特地從高雄一天來回台北參加此次活動。2014/02/15 的台北象山 Mapping Party 總共有十六位朋友參加，所幸未因雨取消活動。
Mapping Party 的主要目的是希望帶領一些新朋友熟悉繪圖工具，因步道仍溼滑，本次活動不行攀岩路線，依照體能分成兩隊，一隊走四獸山步道，另外一隊則走南港山稜線步道。由於規劃的時間有限，並未針對原地圖標示 tag:fixme 的未明路線的進行踏查，主要仍行大眾路線，並沿路紀錄需繪記的地標。並於約下午兩點回到 Mozilla Space 進行現場繪製與經驗分享。
本次修改主要是沿途道路的情報更新，新增黃蟬園路線與位址、修正高壓電塔路線、改善松山家商一帶的資訊、調整四獸山區域的林木線，每次一點點的小更新，都會讓地圖更加完善。以下是本次活動的編修紀錄
以下跟 Google Map 的圖資比較
很明顯開放街圖在山區的詳盡度大勝 Google Map，雖然涵蓋的路線仍尚未覆蓋全台百岳或知名路線，道路品質也尚未能夠進行導航規劃，但登山之人行步道與道路的識別度已高於非戶外專用的圖資。比起 Garmin 等台灣商業圖資，在市區的詳盡度仍有很大的改善空間。
相較於幾年前，開放街圖的資料已經大幅提高。但仍須志工投入，無論是使用或是回報問題或是成為繪圖志工。就像 2014 年冬季奧運的所在地 – 索契一樣，集結眾人的力量完成詳細度大勝商業圖資的免費地圖！
如果您有任何操作上的問題，歡迎參加以下的活動或透過線上網站發文，志工們都很樂意回答您的問題。
歡迎加入台灣開放街圖社群!
觀看嘉農的時候，總會有些細節想弄清楚，例如
這些情報都在地圖上，台灣政府許多機關藏有許多寶貴圖資，各縣市、中央單位不只保存每一階段的量測成果，許多更早以前的紙本圖資也已經被數位化。像是中央研究院、人社中心地理資訊科學研究專題中心的台灣百年歷史地圖系統，即藏有日治時代堡圖、地形圖等。臺北市都市發展局的臺北市歷史圖資展示系統也提供了寶貴的歷史圖資。
很可惜的，有更多的寶貴圖資被藏在政府機關中，許多圖資的品質比商業圖資更佳，即便有像是國土資訊系統或中華民國交通部公路總局資訊室 Safe Taiwan 單位積極整合，但卻因為授權不明，造成民間難以存取使用。
前陣子發掘了一些潛在的資訊，整理於 台灣開放街圖 社群筆記中。
其中一個發現是中央研究院嘉義百年歷史地圖 WMTS 服務，它包含了五筆重要的歷史地圖
為了方便使用，我做了一份線上疊圖，並標註幾個電影中重要的景點，歡迎指教。程式碼可於 github 免費下載。
因為發展中國家，往往缺乏基礎建設，天災發生時往往缺乏可用的最新數位地理圖資。每次有災難發生的時候，開放街圖（Open Street Map）的 Humanitarian OpenStreetMap Team (HOT)[1] 會組織志工小組，分工補足當地圖資，提供需要現場數位圖資的外地救援團隊[16]。
有錢出錢、有力出力， 美國國務院 U.S. Department of State’s Humanitarian Information Unit[2] 也這樣鼓勵。
很可惜的台灣社群因為政治人物蔡英文[3]轉發林雨蒼[4]的文章，鼓勵新手加入，以至於引起一些政治立場不同的人[10][11][12][13][14][15]攻擊[5][6]與消費[7]。
像 是聯合新聞[7]中的專家在 2010 年的時候消費過開放街圖社群對於「海地大地震」[15]的急難地圖，今年卻站在反面立場不建議志工加入 HOT Project，不知道是不是記者報導的解讀錯誤。可以知道是這位「專家」這麼多年已來帳號還是只有一筆已經被刪除的編輯紀錄[8] (當然也很有可能用了分身帳號，以匿名繪製某些地方法規禁止的地圖，像是中國) 否則按照交了會費就是專家的邏輯，我每年繳稅，所以我應該是治國的專家。
而所謂的專業，就是資深圖客協助撰寫入門手冊、改進協同工作流程、開發自動稽核工具。無論是事故還是日常畫圖，新手加入總是難免會犯一點錯，像是無意重開已經被志工稽核過得工作圖區，倒不是刻意搗亂。郵件論壇協調人出來抗議之後，其他圖客也著手協調衝突與協助新手。
本次事件的相關紀錄會被整理在 OpenStreetMap Taiwan hackpad[9] 上。
[1] Humanitarian OpenStreetMap Team http://hot.openstreetmap.org/
[2] MapGive http://mapgive.state.gov/
[3] 蔡英文 Tsai Ing-wen https://www.facebook.com/tsaiingwen/photos/a.10151242056081065.442660.46251501064/10152651639131065/?type=1&theater
[4] 林雨蒼 – 動態時報相片 https://www.facebook.com/photo.php?fbid=10206334564859959&set=a.4811161873909.2192213.1142107210&type=1
[5] 張中一 – 把這兩則放在一起 你就會希望 林雨蒼去吃屎 害了多少無辜的人 https://www.facebook.com/chongyie/posts/10153273865887162
[6] 變態箱民與不笑熊 – 動態時報相片 https://www.facebook.com/1472939446282503/photos/a.1472954112947703.1073741828.1472939446282503/1588347498075030/?type=1
[7] 鍵盤救災？ 專家籲開放街圖讓專業的來 https://video.udn.com/news/309347
[8] OpenStreetMap | schee 的修改集合 http://www.openstreetmap.org/user/schee/history
[9] 2015-Nepal-HOT-Activation-FAQ-in-Tawain/2015尼泊爾地震救難行動FAQ – osmtw.hackpad.com https://osmtw.hackpad.com/2015-Nepal-HOT-Activation-FAQ-in-Tawain2015%E5%B0%BC%E6%B3%8A%E7%88%BE%E5%9C%B0%E9%9C%87%E6%95%91%E9%9B%A3%E8%A1%8C%E5%8B%95FAQ-T23YYSb39zE
[10] 你這麼好騙，你家裡人知道嗎？ http://goo.gl/prlPJF
[11] 變態箱民與不笑熊 http://goo.gl/54TAEx
[12] 台灣藍蛆 http://goo.gl/8qn4sq
[13] 藍白拖的逆襲 http://goo.gl/reIGPR
[14] 藍色小精靈 http://goo.gl/Iycm7V
[15] Haiti Qake2010 Bar Camp Canberra2010 http://www.slideshare.net/sabman/haiti-qake2010-bar-camp-canberra2010
[16] 伊波拉爆發時 BBC 對 HOT 幾位參與者的訪談，英國紅十字會也表示，這些地圖讓援助團隊更容易安排資源配置，拯救了生命: https://www.youtube.com/watch?v=d50Rgt5ej0w
去年在 OpenStreetMap Taiwan Webinar 的題目「自己的圖磚自己刻」之後，注意到其實從頭到尾創建一個圖磚伺服器，要安裝、設定的軟體相當多，要設定資料庫、匯入海岸線 Shp、安裝 mapnik 相關的軟體、寫好 style sheet 等。為了簡化所有的程序，方便入門 2015 年已經先以 Docker 建立初版圖磚伺服器，這個伺服器將資料庫建立、匯入、軟體安裝等等合而為一，入門開發者只要三十分鐘內就可以配置好一個伺服器開始嘗試開發。就算不是 Linux 的開發者，也可以透過 Docker Machine 或其他虛擬機方式設定 docker 開發環境。
不過由於當初把所有的軟體擺在同一個映象檔 (docker image) 中，導致不容易抽出再做延伸的利用開發。 從「自己的圖磚自己刻」講者吳政璋 (小璋丸)的筆記中，可以初步理解要完成一個圖磚 (slippy map) 伺服器所需要的軟體堆疊 (Software stack) 大概可分為編輯後的原始資料、後台資料庫、繪圖輸出 (rendering) 以及前端視覺。
最近嘗試進一步的改善 Docker images 的實踐方式，將每個軟體元件拆分成獨立的 image，以便互相疊加應用。由於 Open Source geospatial software 的發展迅速，迭代頻繁，在過渡時期，偶爾會發現新版的函式庫的 Python binding 已經故障，反而是 node.js 的延伸開發迅速，反之新的技術實踐無法搭配舊伺服器使用。透過 Docker 技術可以很快的「解決」這些軟體版本的相依問題，直接搭配正確的 Linux Distro 版本使用，方便一個軟體服務同時使用新舊科技。希望可以陸續把 Linux 上 常用 Open Source geospatial software 也整理出來，方便進階開發者使用。
目前已經完成 PostGIS, osm2pgsql, mapnik, mod_tile, tilestache, gdal 以及幾個常見的 featured tiles. Docker images 都已經發布到 Docker Hub 上的 OpenStreetMap Taiwan 群組中，原始碼發布於 Github Group中，歡迎試用。
以下分享一些入門的實踐典範，可以供一般 GIS 從業人員或軟體開發者簡便利用開放街圖資料。
首先，對於一般 GIS 資料處理人員，利用 OSM 最初步的工作就是建立一個 Database Replication. 設定 OSM 資料庫並與最新的資料保持同步，並接取到桌面的軟體上進行處理。首先，你需要 PostgreSQl/PostGIS 與 osm2pgsql，其中 osm2pgsql 已經設計成每個十分鐘會抓取一次最新的資料，並匯入資料庫中。
操作的指令可以參考 osmtw/osm2pgsql 的說明，基本上只需要兩個指令
osmtw/osm2pgsql 會負責下載最新的 OSM PBF 檔案，並匯入 osmtw/postgis 資料庫。大概只要十分鐘內，就可以建立好包含最新台灣圖的資料庫，並可以透過 qgis 連上進行查詢，並做後續處理。
有了資料庫之後，接下來是做出 Slippy Map Server，線上即時產生圖磚。從這裡開始，就可以像是疊積木一樣，依照需求配合不同的軟體來搭建。
常見的組合有有 Mapnik/Cascadenik/Carto/Millstone 搭配圖磚處理服器如 mod_tile/Tilestache 輸出成 Raster Image，或是直接以 Mapnik API 輸出成圖。網站伺服器則可以用 nginx/apache2.
透過 Docker Compose 可以很容易的組成所需的軟體結構。依照 OpenStreetMap 標準的圖磚為例子，包含傳統使用 Mapnik xml style, Cascadenik XML 的 OpenStreetMap 標準圖磚，以及使用 Carto CSS style 相當簡潔漂亮的 Mapbox OSM-Bright。前端界面則配合 LeafletJS 做出使用者界面，方便切換幾個不同的底圖。網站服務器則用 mod_tile+apache2. 相關的程式碼與操作請見 github 。
另外一個例子則是小璋丸手刻自創的鬼島地圖，他使用 Cascadenik 語法產生樣式，並以 tilestache 產圖以及 uwsgi 作為網站伺服器。
這幾個樣式大多是僅透過 SQL 取出 PostGIS 中的圖徵，然後配上 stylesheet 產出。有時候會需要做一些資料的前製處理後，才能搭配輸出到圖中。例如等高線圖與地勢圖，就可以從 DEM 資料中計算得出，這個時候可以用 gdal 等工具將原始資料轉成 TIF 或是 SQL，再套疊到地圖上，這樣就可以做出地勢顏色與等高線圖等效果。
最後，光是做出 Slippy Map / Raster Image 其實是很空洞的平面地圖，許多地圖的使用者往往希望可以取得特定 POI 的詳細資料。這個時候就需要搭配向量圖磚來豐富地圖上的資訊量，雖然像是 Mapzen, Mapbox 商業公司已經提供現成的接口可用，但是常常比不上自己下 SQL 語法來的有彈性。
我們可以透過 OpenStreetMap 圖資與 TileStache 來輸出支援 GeoJSON、TopoJSON、MapBox Vector (MVT) 等格式。請參考飲水地圖 vector tile server 的實做方式，從資料庫中搜尋 amenity=’drinking_water’ 的 POI ，並以 LeaftletJS 將資料繪製到地圖上。由於他使用本地資料庫，所以會比飲水地圖官方網站透過 overpass 撈取資料快速許多。
OpenStreetMap 從 2012/09/12 後的資料，是使用 ODbL (Open Database License)[1] 散布。ODbL 條款[2][3][4]有寬鬆的授權模式 (permissive license)、 Copyleft 授權等特性，這些特性影響到利用 OSM 為基礎開發的其他作品是否也該以 ODbL 授權方式 (條款 4.4 節) 再次散布，或是只要聲明資料來自使用 ODbL 的 OSM 資料庫 (條款 4.3 節)。
而作品的區分方式分為
例如把 OSM 輸出成圖檔或是紙本地圖，這即是「產製作品」。如果是直接改造原始資料庫，則為「衍生作品」。
給行動裝置用的向量圖資 (Garmin img 或 MapsForge[9]) 是一個模糊的地帶，因為實際上地圖並非以圖檔格式 (raster graphic) 散布，而是將原始 OSM 資料庫轉換成另外一種資料庫型態散布。但是由於這些向量圖檔的主要用途仍是離線顯示地圖，在 OSM 社群的討論[8][9]上，是被認可為「產製作品」[6]。除非新增額外的資訊到資料庫或增修其向量圖檔，或將其作為資料庫使用，則會被視為「衍生作品」[11]。
所以如果你散布的是未經過增修的向量圖資則請按照 4.3 節規定，在授權處說明
並請於輸出註明 “© OpenStreetMap contributors” [12]
[1] Open Database License – OpenStreetMap Wiki – https://wiki.openstreetmap.org/wiki/Open_Database_License
[2] Open Database License (ODbL) v1.0 | Open Data Commons – http://opendatacommons.org/licenses/odbl/1-0/
[3] 20121120-ODbL-1.0非官方正體中文翻譯 | Lu-six Person’s Notes – http://lucien.cc/?p=2358
[4] 20121120-DbCL-1.0非官方正體中文翻譯 | Lu-six Person’s Notes – http://lucien.cc/?p=2360
[5] 20121018-從開源軟體到開放資料－論 Open Database License v1.0 | Lu-six Person’s Notes – http://lucien.cc/?p=2348
[6] Licence/Community Guidelines/Produced Work – Guideline – OpenStreetMap Foundation Wiki – http://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Produced_Work_-_Guideline
[7] Open Data License/Produced Work – Guideline – OpenStreetMap Wiki – https://wiki.openstreetmap.org/wiki/Open_Data_License/Produced_Work_-_Guideline
[8] [OSM-legal-talk] Garmin maps and license – https://lists.openstreetmap.org/pipermail/legal-talk/2016-February/008382.html
[9] Selling routable OSM maps for garmin – OSM Help – http://help.openstreetmap.org/questions/48251/selling-routable-osm-maps-for-garmin
[10] 台灣 MapsForge 圖資檔案 – osmtw.hackpad.com – https://osmtw.hackpad.com/%E5%8F%B0%E7%81%A3-MapsForge-%E5%9C%96%E8%B3%87%E6%AA%94%E6%A1%88-tcm2Owggcqb
[11] Legal FAQ – OpenStreetMap Wiki – https://wiki.openstreetmap.org/wiki/Legal_FAQ#3c._If_I_make_something_with_OSM_data.2C_do_I_now_have_to_apply_your_license_to_my_whole_work.3F
[12] Legal FAQ – OpenStreetMap Wiki – https://wiki.openstreetmap.org/wiki/Legal_FAQ#3._Using
無國界醫生組織 (Doctors Without Borders/Médecins Sans Frontières) 在七月份發表了一個新的手機軟體 MapSwipe，這個軟體的功能是讓志工可以透過手機協助預分析衛星圖 (pre-screen satellite imagery)，協助醫療團隊判斷哪些偏遠地區的群聚部落，以便派人前往提供疫苗接種等醫療服務。
MapSwipe 是一個開放原始碼軟體，使用方式非常簡單，透過後端系統將衛星圖切好豆腐，透過手機介面讓志工選出地圖上可能的道路或建築物。這個計畫可以與 OpenStreetMap 的 Humanitarian Team 的 Missing Maps Project 合作，在大型災害發生時，透過最新的衛星圖資料，讓志工可以快速的區分出尚存的建築物。然後再發布於 HOT Task Manager 上，由後續的圖客 (Mapper) 接手進行細部的地圖繪製工作。可以爭取時效由全球的志工，為地面隊伍提供更新過得地圖情報。
然而，這是使用工人智慧進行衛星圖，利用大量的人力來做地圖判讀。
大型的科技公司如 Facebook ，為了達成他們的連結全世界的遠景，也必須找出人口分布，這是傳統的人口統計無法提供的資訊。於是他們與衛星影像公司 Digital Global 合作，利用 machine learning 的影像處理技術找出人造建築，來推算人口分布度。Facebook Connectivity Lab 的技術文章說明了技術的概念。
至於非營利組織與學術界，只好利用開放的資料。類似的工作有 Arnhold Institute for Global Health 的 Senior Data Analyst, Patrick Doupe 使用 LANDSAT7 的衛星圖，計算預測特定區域的社經狀態。初期的程式碼已經發布在 github 上。
Standford 大學的研究學者 Marshall Burke 與 Stefano Ermon 的團隊，則是更進一步的藉由分析白天和夜間的衛星影像來建立模型，因為電力的基礎設施可以反應出當地的經濟水平，然後再以地面的基礎設施作為 filters，將模型轉移成預測貧困地區 (中文)。透過這套技術，可以以衛星影像取代過往利用大量人力普查的成本，長期的觀察偏遠區域的發展現況。然而，衛星資料仍有其侷限性，研究團隊也在考慮如何蒐集行動電話的 metadata作為原始數據. 論文中以 R 3.2.4 與 Python 2.7. 實做的程式碼與配置教學已經放到 github 上。
這些技術使用的都是 convolutional neural network，有別傳統的 Geographic Object-Based Image Analysis 技術，有更多應用場景。
像是快速搜索衛星圖中的特定影像特徵。
Terrapattern 提供了一個普羅大眾都可以輕易使用的反向搜尋引擎。透過 OSM 標籤分類衛星圖像，以 Deep Convolutional Neural Network 訓練，但他的目的不是自動區分出建築物的類型。而是讓使用者可以快速透過 Cover Tree 的依據影像特徵快速搜尋地景，最好用來搜尋哪些不容易出現在地圖上的設施，像是廢氣泳池、冷氣機組等等。同樣的技術也可以用在受災區域的空照圖，可以很快的辨識出毀損的建築與橋樑道路等。程式碼是以 MIT 授權發布，網站上的資料也很有參考價值。
本文開始提到的以工人智慧方式檢測衛星影像，以便加速急難救助時候的繪圖速度，其實也可以透過人工智慧的技術加速處理。Stanford 的同學 Lars Roemheld 在他的學習課程 CS231n: Convolutional Neural Networks for Visual Recognition 的報告，詳細的描述了他嘗試的方法，以及碰到的問題。
Development Seed 的 Anand Thakker 在 2016 的 SoTM US 的演講 Skynet 則成功的展示如何利用 Machine Learning 找出道路。他提到、雖然 OSM 圖資中已經有許多的道路可以作為訓練資料，但是由於道路的寬度並未正確得標注，所以仍需要一些調整後才能正確的訓練出模型。細節請參考投影片、測試資料與程式碼。
光是標注出路線只完成了一小份工作，人工智慧與衛星影像並無法提供路名。
Facebook 在某些區域，已經開始使用 OSM 當作地圖基本資料，作為打卡的基礎地圖，Sadi Khan, Yin Wang, Luke Walsh 等幾位 Facebook 工程師在 SoTM US 上分享了他們針對埃及所進行的一些實驗，預測可以增加 20%-30% 道路網絡，並開始測試從 POI 取出路名，然後讓使用者回報選擇正確的路名，進一步提高資訊的完整度。雖然已經匯入部份部份路網，但是由於程序問題且品質不佳，已經回退修改。
其他的社群實驗還有 Geometalab 的 Samuel Kurath 做的 Crosswalk-Detection，用於偵測馬路上的斑馬線，據說目前已經有了 98% 的準確率。
在開放街圖社群已經有社群將技術用於改善圖資品質。專門做專業登山地圖軟體 Gaia GPS 的 TrailBehind, Inc，利用 TensorFlow 開發自動偵錯工具 DeepOSM，利用衛星影像識別道路，並與現有的圖資對照是否正確。這是最早將類神經網路技術利用於 OSM 的計畫之一。
深度學習/機械學習的進入門檻越來越低，主要的線上雲端服務供應商包含 Amazon, Microsoft Azure, Google 都陸續推出適合類神經網路計算使用的 GPU 伺服器。可以很方便的取得計算資源，進行一些實驗開發。
除此之外，DigitalGlobe, CosmiQ Works 與 Amazon 合作推出了 SpaceNet 資料集。這些圖資來自 DigitalGlobe 的 WorldView-2 商業衛星，50 cm 的高畫質圖資，包含八個波段多光譜影像 (8-band multispectral data)。以及 220,594 組建築物圖像可以作為人工智慧訓練資料。
從 Development Seed 的分享，社群已經開始將技術用在完善 Dar es Salaam 路網或是與 World Bank 合作。但是這些新技術在 OSM 社群中引起一些政治衝突，OSM 社群一直都是由志工徒步踏查從無到有畫出來的，這些志工很珍惜透過聚會所建立的社群，只須要宅在家裡的鍵盤畫圖活動一直都不太受到歡迎。
而現在到達了一個 機械化編輯 (Robot mapping) vs 人力編輯 (Craft mapping) 的十字路口。
作為一個實用主義者，我個人相信機械化編輯可以大幅降低成本的維持高品質的圖資資料，而人力編輯可以相輔相成的專注於提供本地知識。
2016/09/09 台灣政府內政部發布開放全臺及澎湖地區的20公尺網格DTM，這真是政府開放地理資訊之一大里程碑！
在此筆資料發布之前，台灣政府已經陸陸續續發布了相當多以 WMS、KML、GeoJSON 等格式的地圖資料集，特別是七月底發布的經建版地形圖數值檔 （比例尺為2萬5千分之1、5萬分之1及10萬分之1），一舉將原本每幅圖檔收費150元(非加值型)、600元(加值型)改成以政府資料開放授權條款散布！
內政部部國土測繪中心的「經建版地形圖數值資料檔(比例尺為二萬五千分之一、五萬分之一及十萬分之一)」前經「105年行政院資料開放諮詢小組第2次會議」列為甲類資料，並經本部105年7月26日台內地字第1051306149號令修正發布「國土測繪成果資料收費標準」第2條附表附件2，開放資料供免費下載使用，授權條款採用行政院「政府資料開放授權條款－第1版」
這批 2016/07/28 釋出的圖檔包括二萬五千分之一經建版地形圖計262幅、五萬分之一經建版地形圖計80幅及十萬分之一經建版地形圖計7幅，共計349幅。
不含等高線圖層，但是包含水系、道路、行政界線、鐵道、高壓線、建築區等圖層，及圖例、中文註記等向量圖層。
雖然這批經建版地形圖數值檔的部份圖檔年代久遠，座標系統部份因為製圖時偏好，選用了 TWD67(119分帶)、TWD67(121分帶)、TWD97(121分帶) 等等不同的座標系統，格式也是需要私有軟體 AutoCAD 2013/2014 的 AC1027，實務上仍需要整理之後才有使用價值。
但是這項開放政策代表政府機關終於願意改變預設立場，將此圖資所能帶來的歲入財源，換取開放資料活化應用的經濟價值。而這種預設立場是過往法條的規範所造成的，例如規費法第7條與第8條明定：「為特定對象之權益辦理下列事項，應徵收行政規費；交付特定對象或提供其使用下列項目，應徵收使用規費。」，在「特定對象」的授權前提下，依據規費法所定義的各種政府資料管理辦法就會變成
以至於降低各種資料再度利用的可能性。如果今天這筆資料沒有以政府資料開放授權條款發布，我也無法依照測繪圖資供應收費基準透過購買加值型授權後，將資料初步處理後開放給 OSM 社群再產製程其他格式的地圖。
這不是一夜之間發生的事情，前前後後有來自不同的非營利組織的許多專家、學者與政府官員開會交流。
以開放街圖社群為例子，社群代表早在 2014 年中開始與行政院接觸，前前後後開了不少次會議。
這些會議的主題基本圍繞著
目的是逐一針對釋出資料的可行性等等討論。
最初的會議相當令人挫折，很多時候會由於雙方對於期待「開放」的程度不同，討論難以有交集，加上具體需要調適的繁複法規，以及對於變動政策後難以預期的民意反應等等，往往讓進度難以快速推進，所幸一直有積極的政務官支持推進。
即使有最高層級的官員支持，從願意採納意見到實際釋出資料，還要好長一段時間。
這些工作包含要調適法規，包含釋出的資料必須仍在個人資料保護法、著作權法之下，以及行政罰法、規費法等等都會影響各機關的支持度。法規不甚完備，加上政府機關的缺乏積極動機，維持資料正確與即時性需要透入預算與資源，但是政府機關往往並非資料利用的受益者，公開資料只會帶來違法的風險。
其實內政部100公尺網格數值地形模型資料是最早開放的資料，但是 100 公尺的精度缺乏實用價值，且早在 2011 年就有學者建議國安單位應該逐步開放更高精度的 DTM 資料。許多使用開放圖資的用戶使用 NASA Shuttle Radar Topography Mission (SRTM) 的 DEM 資料，它的理論精度是 1 arc/second (30公尺)，但由於它是插點處理，仍有缺陷。但是那是一般研究單位或是 OpenStreetMap 可以拿到的免費資料，也因此許多拿 OpenStreetMap 為底圖做戶外運動的使用者會拿 SRTM 作為等高線地形圖的參考資料。
作為一個以登山為主要應用的開放街圖使用者，在 2014/07/27 在行政院開的第一次會議上，我就提議將數值地形模型優先開放。
第一次會議後足足過了兩年，終於等到這筆20公尺網格DTM數值地形模型。
這批資料的 HDR 資料顯示是 2006 年測製，由財團法人成大研究發展基金會使用 5M 網格資料疏化重製 20M 網格資料。座標系統則是 TWD97 / TM2 zone 121。DTM數值地形模型 不只是可用於產製等高線 (Contour lines) 與彩色暈渲圖 (Hillshade map)，尚可用於工程模擬、地形查詢、立體地形圖、坡度計算等等。
以目前台灣的登山社群而言，可以立刻用於取代原本的 SRTM 地圖資料。
例如地圖產生器在 v4.02 即已經使用此數據作為地形高度查詢的參考資料。
也可以用於產生 Mapsforge 離線向量圖資，目前台灣社群已經長期供應的有 Jing 的 ASTER.OSM、綠野遊蹤 等離線圖資來源。這些圖資將可以用於手機的 OsmAnd、Locus Map、OruxMaps、綠野遊蹤等軟體。
也可以產製成 Garmin 裝置所需的地圖格式，台灣有 ASTER.OSM 與 台灣登山地圖 – Taiwan TOPO 等。
由於這批資料的座標系統是 二度分帶（TWD97，中央經線121度），為了使用方便，我將原始的 GeoTIFF / ASCII gridded XYZ raster datasets 一律轉成 WGS84，以方便再度後製使用。
目前轉好的格式有
相關格式的圖資以及轉換的命令語法，請於此下載 http://goo.gl/Wku11y
如果有圖資應用上的問題，歡迎到 OpenStreetMap台灣 社群討論。如果有手機使用此版圖資的問題，可以洽詢手機GPS登山推廣計畫及其經驗交流聯誼會，或是別讓自己迷失（手機GPS應用）以及正在籌備成立的福爾摩沙山難預防協會。
此資料集以 CC0 授權。使用者利用此資料，受有損害或損失，或致第三人受有損害或損失，而遭求償者，不負任何賠償或補償之責。
目前已知的幾個問題，一是外海部份由於有負數高程，導致海岸線出現方框或人工痕跡。另外無論是分幅雲林縣資料或不分幅全台資料，在 (120.682650, 23.608483) 與 (120.682283, 23.604167) 兩處有高達六千公尺的奇怪外星建築。
與 SRTM 比對發現可用性高很多。以往 SRTM 圖資精度不足，使許多河谷的等高線錯誤，容易將河谷誤判為稜線。
以下與 2001 的經建三版兩萬五千分之一紙圖比對。可能很多山友會在登百岳的時候購買上河文化的地圖，或是在爬中級山的時候，使用地圖產生器印出經建三版的紙本地圖，然後用膠帶防水貼好帶上山。
透過內政部這次釋出的資料搭配 OSM 的山岳路線，山友將可以搭配使用產生出具備高即時性，使用便利的手機或專業手持衛星定位裝置離線地圖。
感謝這一路以來，努力謀求共識的各位政府機關、專家朋友們！
This is a lightning talk I shared during SoTM Asia 2016 at University of the Philippines Diliman.
If you can read Chinese, please read my post – 使用 Docker 玩轉開放街圖
Google’s I/O 2016 的演講[1]提到會支援 Raw GNSS measurements，開放開發者取得 pseudoranges, dopplers and carrier phase 等資料。
過去，這些資料是在 GPS basdband processing 就已經計算處理好，對於一般軟體開發者而言通常直接使用 LocationManager 取得最終的定位資料，而非衛星訊號數值等資料。
對於需要做 GPS 效能調校的硬體、韌體工程師，通常透過 Android HAL API 測試 GPS 訊號。在 Android 中最低階的協議是透過 NMEA sentence 協議取得衛星訊號數值，但是這其實還不夠低階到包含如 pseudoranges 等資料[5][6]。這些 raw data 資料只來自使用該晶片商獨家的 binary protocol，而沒有標準的 API 可用。
Google I/O 的講者 Steve Malkos 的演講 (37分30秒)[7] 其實只提到會拿到原始 GNSS 測量資料。但是他還沒有分享具體的設計會長什麼樣子，另外最大的改變是 GPS, Wi-Fi, Cell 等 Connectivity API 會被從較高階 API 移到底層的 Sensor Hub (low power domain)，這樣可以更省電且有效的計算位址資料。
查了一下 android-n-preview-3 的 codebase，目前 libhardware 的 HAL Interface[2][3] 還沒有改變，上層的 Location API[4] 也還沒有跟著新的設計異動。
繼續期待。
[1]: http://gpsworld.com/google-opens-up-gnss-pseudoranges/ “Google opens up GNSS pseudoranges : GPS World”
[2]: https://android.googlesource.com/platform/hardware/libhardware/+/android-n-preview-3/include/hardware/gps.h “include/hardware/gps.h – platform/hardware/libhardware – Git at Google”
[3]: https://android.googlesource.com/platform/hardware/libhardware/+/android-n-preview-3/include/hardware/sensors.h “include/hardware/sensors.h – platform/hardware/libhardware – Git at Google”
[4]: https://developer.android.com/reference/android/location/GpsSatellite.html
[5]: https://en.wikipedia.org/wiki/Pseudorange
[6]: https://en.wikipedia.org/wiki/Doppler_effect “Doppler effect – Wikipedia, the free encyclopedia”
[7]: https://www.youtube.com/watch?time_continue=2251&v=OEvycEMoLUg “Making Android sensors and location work for you – Google I/O 2016 – YouTube”
之前介紹過 Google 在 Android 7 (Nougat) 中推出 GNSS measurements API ，由於這個功能受限於硬體韌體設計，暫時只有某些晶片才能支援，包含了 Exynos、Qualcomm、Broadcom BCM4774、Intel WCS2x00 等。預計今年之後會出現越來越多支持 GNSS Measurements API 的手機。
開發者網站提供一個參考列表，包含市面上幾個旗艦手機的對於 Pseudo-range and pseudo-range rate、Navigation messages、Accumulated delta range or carrier、Hardware (HW) clock 等支援現況，也提供了範例程式給開發者參考。
歐洲的全球衛星定位系統 Galileo ，前後也辦了兩次黑客松，參與者 Lukasz Kosma Bonenberg 博士分享一些應用發想，像是 Differential GNSS/RTK、窮人的衛星訊號干擾偵測、窮人的地震感應器、或是用 GNSS Shadowing 改善都市叢林的定位。他也將相關的程式碼發布到 github 上。
依照最近的實驗研究，智慧手機的天線與接受器設計明顯比不上專業的量測儀器，即使有良好的衛星訊號，量測結果仍有一個數量級的差距。但是與過往只有五公尺到十公尺的精確度，已經可以作到公尺等級的精確度。如果硬體設計上可以解決 duty cycling 的侷限，便有機會透過手機做出精度到公分級的低成本 RTK 測量儀器，適合一些不介意耗電速度的使用場景。
另外一個值得一提的是，由於近幾年 GPS、Galiao、QZSS 等支援 L5/E5 10Mhz 訊號的衛星總數到達了三十顆，相較於 L1 1Mhz 的定位訊號，10Mhz 在都市叢林中造成的多重路徑傳播影響較小。GPS L5 訊號是一個刻意保留的頻道，更不容易受到干擾。結合 L1,L2 雙頻定位可以作到更高的定位精度。
L5 從 Block IIF satellites 之後的新型衛星開始送訊號，第一台是 2009 上線的USA-203。之前支援 L5 的衛星數量不夠多，其覆蓋率未到大眾可用的商業規模。早些時候只有一些專業的量測工具提供 L5 訊號支援，但是 Broadcom 率先針對智慧型手機推出支援 L5 訊號 BCM47755 晶片，受惠於足夠的衛星訊號，可以大幅改善智慧手機的定位精度。預期其他的競爭對手的產品應該可以逐步趕上，希望在 2018 年看到更多支援此功能的的手機硬體產品。
