基于Android 的軌跡分析應用設計與實現

肖雷鳴， 卿粼波， 馮 田

（1 四川大學 電子信息學院， 成都 610065； 2 四川大學 建筑與環境學院， 成都 610207）

0 引 言

在衛星定位技術與移動互聯網軟硬件技術的高速發展背景下，人們出行時產生的海量軌跡數據以各種方式被獲取并保存下來。 這些軌跡數據都記錄了移動對象長時間的位置變化，其反映出的移動對象人群的移動與活動特征、興趣愛好和社會習慣等豐富的時空特征信息，引起了城市規劃、社會學等多個領域研究學者的關注。 至今，研究者們已利用采集到的軌跡數據進行了大量的研究，挖掘出了軌跡數據在許多領域的應用價值［1-3］。 例如，軌跡數據已用于通勤［4］與職住空間分析［5］、交通路線的優化與設計［6-7］、城市交通狀態的劃分與識別［8］、城市綠道系統效用評估［9］、識別城市功能區［10］、商業選址［11］、個性化推薦路線［12］、道路推薦［13］、交通熱點分析［14］等方面。

大量對軌跡數據的研究，使軌跡數據的分析方法形成了一定的研究范式。 研究者們通常將軌跡處理研究分為軌跡信息采集與軌跡分析兩個步驟。GPS 嵌入式設備采集的軌跡數據［15］與信令數據［16］是研究者常用的數據來源，但由于前者造價昂貴，后者數據精度較低、獲取渠道存在限制等原因，且隨著本世紀以來Android 操作系統的迅猛發展［17］，借由地圖平臺營造的位置定位信息服務，致使研究者們更多地選擇自主設計相關軟件來持續獲取定位信息［18］。 在軌跡數據分析方面，有研究者使用基于時間序列的聚類算法識別軌跡的停留點［19］、高頻點與異常點［20］以及打車熱點［21］等軌跡語義點；也有研究者利用判別分析［22］、支持向量機［23］等方法［24］識別軌跡中不同的出行方式，以及利用隔離機制進行軌跡異常檢測［25］、利用軌跡信息測算持有者的運動能量消耗［26］等方法對軌跡進行分析。

盡管研究者們對軌跡數據的采集與分析流程已較為熟悉，但縱觀現有研究，仍普遍存在以下3 個問題:

（1）軌跡采集與軌跡分析的割裂:采集端（GPS嵌入式設備、Android 設備）與分析處理端（PC 服務器）的分離導致無法對軌跡進行實時分析，同時也提高了實驗環境的搭建成本。

（2）軌跡分析算法與實際應用的割裂:研究多針對單一語義進行分析（停留點、出行方式等），研究成果無法整合，非專業人員復現難度大，投入應用難度更大。

（3）缺乏易用的實時可視化系統。

基于上述原因，本文開發了一款集軌跡采集、軌跡分析（多語義）、軌跡可視化、軌跡分享四種功能為一體的軌跡分析應用。 該應用基于Android 平臺與百度地圖SDK 開發，能持續采集使用者的經緯度、速度、室內狀態、POI 等軌跡信息；同時，通過嵌入在軟件內部的相關算法（時間切片、停留點識別、語義分段等）對軌跡進行分段，計算出軌跡停留點、出行方式、起始時間、總時間、總距離等重要語義信息；此外，設計分享模塊將分析結果以Excel 表格形式分享，便于研究者二次分析。 本文開發的軌跡分析軟件，實現了對軌跡的實時采集、多種語義分析、可視化與保存分享，具有實時、集成、易用的特點，適用于各領域有軌跡采集與分析需求的相關人員。

1 系統設計

1．1 需求分析與模塊設計

從目前軌跡研究中采集困難、分析片面、程序復雜、實用性弱四個角度進行需求分析。 采集軌跡數據時，用戶需要實時查看定位數據以確認數據的正確采集或者進行軌跡的調整；軌跡采集結束后，用戶需要即時得到分析結果，包括軌跡的時間、距離、速度、出行方式等詳細信息；用戶需要借助可視化界面對出行軌跡進行判斷；在得到分析數據后，用戶希望保存或分享原始數據與分析數據，便于后續研究。根據上述需求設計了四大功能模塊，如圖1 所示。由圖1 可知，對這4 個模塊的研發功能，擬展開闡釋分述如下。

圖1 軌跡分析應用模塊設計Fig． 1 Design of trajectory analysis application module

（1）軌跡采集模塊:在地圖上能實時查看持有者的位置、速度、室內狀態、附近POI 等信息；同時保存采集到的單點定位信息。

（2）軌跡分析模塊:對單點定位信息進行分析。通過軌跡切片、停留點識別、切片整合、語義分段等算法對長時軌跡進行分段，并獲得每段軌跡的用時、距離、出行方式等詳細信息。

（3）軌跡可視化模塊:在地圖上可視化長時軌跡。 根據持有者不同的出行方式，以不同的顏色可視化軌跡片段，并添加始末點和停留點的點標記，點擊標記能查看距離和用時等信息。

（4）軌跡分享模塊:分享模塊設計了保存與分享兩大功能，能保存定位信息與分析結果至Excel表格，并支持一鍵分享至微信和QQ。

1．2 軟件服務流程

軟件的服務流程如圖2 所示。 用戶打開App后，軟件自動加載地圖界面；點擊開始定位即可進行軌跡定位（定位過程中用戶能在地圖上查看當前的定位信息，也可以退出App 界面，系統則會自動在后臺采集定位信息）；點擊結束定位，軟件自動進行軌跡分析、可視化以及保存分析文件，最后，用戶可以選擇是否分享文件。 整個操作過程中，使用按鍵少，操作簡便。

圖2 軌跡分析應用服務流程Fig． 2 Service process of trajectory analysis application module

2 關鍵模塊實現

2．1 地圖與定位模塊

地圖與定位模塊是App 的基礎模塊。 此模塊提供用戶可視化與交互界面，用戶能實時查看所處位置，獲取地址、GPS、速度等詳細信息。 地圖模塊中添加監聽按鈕用于開啟與結束定位，實現軌跡采集與軌跡分析的功能。

模塊調用百度地圖 SDK 中的MapView.getMap（） 方法獲取基礎的地圖可視化界面，地圖界面擁有基礎的縮放查看功能；然后，通過基本參數的設置與監聽注冊，獲取定位服務；獲取定位服務對象后，通過setScanSpan（） 等方法設置定位時間間隔等回調參數；最后，在回調函數中使用相應的get方法獲取所需的定位信息；圖3 為定位模塊的方法流程圖。 此外，當前時刻回調的定位信息會儲存至動態Stringbuffer變量中，使用TextView.setText（）方法將儲存的變量值以文本框的形式添加到地圖界面，如圖4 所示。 同時，自定義Point類來描述當前時刻定位點，自定義的靜態List ＜Point ＞變量pointlist儲存所有時刻的定位信息，用于后續的軌跡分析模塊。

圖3 定位模塊方法流程Fig． 3 The method flow of the positioning module

圖4 定位信息Fig． 4 Positioning information

2．2 軌跡分析模塊

軌跡分析模塊是軌跡分析應用的核心模塊，對定位模塊儲存的連續單點定位信息進行分析，得到軌跡的用時、距離、停留點、出行方式等信息。 軌跡分析模塊細分為軌跡切片、切片識別與整合、語義分段與輸出規范化四個部分。 各部分的功能劃分如圖5 所示。

圖5 軌跡分析模塊Fig． 5 Trajectory analysis module

2.2.1 軌跡切片

即便定位模塊單點定位信息的采集頻率足夠高，但對于時間跨度較大的軌跡，單點GPS 定位信息很難有效地描述軌跡的狀態。

問題1使用連續的單點定位描述長時軌跡，描述結果整體性差。 例如，當一段長時間的步行中有多次短暫停留（幾秒左右），這一段步行軌跡就會被描述為大量的步行軌跡片段與停留軌跡片段。

問題2使用采樣間隔較大的單點定位來描述長時軌跡，相當于對連續的單點定位進行抽樣，而使用單點定位信息來描述連續的軌跡會產生較大的誤差。

針對上述存在的問題，為保證軌跡分析的整體性和低誤差，本文提出使用軌跡切片的方法對長時軌跡進行分析，將整個軌跡片段按固定時間尺度進行切分，然后進行整體分析。 切片大小（切片包含的單點定位個數）為clipsize，由本小節問題1 可知，clipsize值不宜過小，此外clipsize值根據采集的軌跡時長靈活設置（本文系統測試時長為30 min 內，測試中clipsize的值設置為60，即軌跡分析的精度以1 min為單位）。

軌跡切片如圖6 所示，長時軌跡被切片為固定長度的片段，一個軌跡切片中有多個定位點，切片和單個定位點具有獨立的屬性，其中單點定位的pointlogi、pointlati、pointspeed、pointindoor等屬性由定 位 模 塊 的getLatitude（ ）、getLongtitude（ ）、getSpeed（）、getUserIndoorState（） 等方法獲取，切片的屬性（clipspeed、clipindoor、clipvehicle等）由單點定位屬性計算得到。keypoint為切片的第一個單點定位索引。

圖6 軌跡切片Fig． 6 Trajectory slices

2.2.2 切片識別與整合

軌跡切片后，利用切片包含的單點定位的屬性對切片的速度、室內狀態、出行方式等屬性進行識別。 這里給出研究闡述如下。

（1） 速 度:clipspeed由 從pointlist中 獲 取 的pointspeed計算得到，即:

（2）室內狀態:當每個clip 中clipindoor的數值大于clipsize／2 時，clipindoor設置為1（1 表示室內，0 表示室外）。

（3）出行方式:停留與非停留兩種狀態。 當切片識別為非停留狀態時，其出行方式由clipspeed（單位為m／s）確定，在采集的社會實驗數據［27～29］的范圍內可將出行方式劃分為步行（0 ＜clipspeed≤1.4）、 自行車（1.4＜clipspeed≤5）、 汽車（5＜clipspeed≤8.3），地鐵（clipspeed ＞8.3） 四類。

停留狀態的識別是出行方式識別的關鍵部分。停留點類型如圖7 所示。 由圖7 可知，停留點分為靜止型停留點和徘徊型停留點兩類。 在識別停留片段時，存在以下情況:

圖7 停留點類型Fig． 7 Stop point types

情況1使用速度判別停留點時，會漏判徘徊型停留點。

情況2使用距離閾值判別停留點，當運動速度較快時，存在切片內大量定位點速度為0、但仍有定位點超出距離閾值，導致靜止型停留點誤判為運動軌跡片段的情況。

為同時保證2 類停留點的準確識別，本文提出使用速度和距離聯合判斷停留點，判別算法如下:

算法1 聯合速度與距離判斷的停留點識別

for（intpoint ＝keypoint；point - keypoint ＜clipsize；point ＋＋）｛

if（（pointlist.get（point）.speed）＝＝0）

i ＋＋； ／ ／統計速度為零的定位點

if（GetDistance（pointlist.get（point）.pointlist.get（keypoint））＜30）

j ＋＋；／ ／統計處于距離閾值內的定位點

｝

if（i ＞＝clipsize／2‖j ＝＝clipsize）｛／ ／聯合判斷

clipvehicle＝“停留”

clipspeed＝0.0；

｝

程序中，point為單點定位在pointlist中的索引，i為速度為0 的point個數，j為小于距離閾值的point個數，距離閾值設置為30 m，代表停留時所允許的徘徊范圍，可根據實際需求設置。

切片識別后，為進一步分析與輸出，將判別屬性相同的切片進行整合。 切片整合示意如圖8 所示。

圖8 切片整合Fig． 8 Slice integration

2.2.3 語義分段

在實際測試中，行駛速度較高的交通工具在行進過程中，速度不會穩定地保持在某段大小范圍內，通常會因為不同的路況導致暫時的低速行駛，從而導致出現機動車運動軌跡被誤判為步行、自行車的情況。

針對上述誤差，提出使用已判別后的軌跡片段的語義進行二次分析的方法。 語義分段算法的部分核心代碼如下:

算法2 語義分段算法

for（inti＝0；i ＜cliplist.size（） - 1；i ＋＋）｛

if（cliplist.get（i ＋1）.id-cliplist.get（i）.id ＜2）

／ ／連續值小于clipsize的2 倍則視為短時軌跡

cliplist.get（i）.semantic ＝″timetooshort″；

｝

for（inti＝0；i ＜cliplist.size（） - 1；i ＋＋）｛

if（cliplist.get（i）.semantic ＝＝″timetooshort″）

if（cliplist.get（i ＋1）.semantic ＝＝ ″timetooshort″）

c ＋＋；…；／ ／變量c為短時軌跡連續出現的次數

else｛

／ ／加權平均前c段短時軌跡的速度

clip.speed ＝getavespeed（i -c，i，cliplist）；

／ ／二次判別出行方式

clip.vehicle ＝getavevehicle（clip.speed）；

／ ／重新統計連續短時軌跡數量

c＝0；…；

｝｝

首先，標記出高速運動片段及其鄰近的短時軌跡片段的語義屬性（semantic）為短時（timtooshort），然后使用getavespeed（） 方法對連續的標記軌跡做均值處理，使用getavevehicle（） 方法重新判斷速度和出行方式屬性，同時考慮到速度為零的片段對速度均值的影響較大，停留片段將不被標記；語義分段的示意圖如圖9 所示。

圖9 語義分段Fig． 9 Semantic segmentation

2.2.4 輸出規范化

通過自定義Output類將每段軌跡的停留、出行方式、速度、室內外狀態等屬性信息存入實例中，并通 過 自 定 義 的getallDistance（ ） 函 數 與getspendTime（） 函數計算各段軌跡的始末時間與總距離，通過Output實例的各類屬性規范描述每段軌跡的信息，為后續的軌跡可視化及軌跡文件生成與分享提供易用的輸入數據。

2．3 軌跡可視化模塊

軌跡可視化模塊的功能為將軌跡分析模塊得到的結果呈現在地圖上。 在繪制地圖上不同交通方式的軌跡以不同顏色繪制，且添加了停留點點擊窗口用于呈現相關信息。 點擊后的可視化結果如圖10所示。 可視化使用百度地圖SDK 組件，可視化之前將會獲取軌跡段的始末索引信息，使用mBaiduMap.addOverlay（） 方法將非停留軌跡片段所包含的point繪制在地圖上，實例化PolylineOptions（） 對象設置繪制的粗細與顏色；對于停留的軌跡段，將其對應的point存儲至一個數組中，同時通過mBaiduMap.showInfoWindows（） 方 法 批 量 繪 制 點 標 記， 創 建InfoWindow.OnInfoWindowClickListener監聽對象，重寫onInfoWindowClick（） 方法來設置點擊后彈出的信息窗口，顯示的內容為Output類的對象。

圖10 軌跡可視化Fig． 10 Trajectory visualization

2．4 保存與分享模塊

保存與分享模塊的功能主要由自定義FileUtil工具類中的writeToExcel（） 方法與ShareUtils 工具類中的ShareWechatFriend（） 方法實現。 在App 文件目錄下的files 目錄中創建.xls 文件。 第一個sheet表單，命名為“GPS 信息”，用于寫入pointlist 列表中存儲的單點定位信息，第一列的表頭信息與Point 類的屬性對應，保存的文件格式如圖11 所示；第二個sheet 表單命名為“分析結果”，用于寫入outputlist中保存的分析結果，第一列的表頭信息與Output類的屬性對應，保存的文件格式如圖12 所示。

圖11 單點定位信息保存格式Fig． 11 Single－point positioning information save format

圖12 軌跡分析結果保存格式Fig． 12 Trajectory analysis result save format

以微信分享為例，在自定義的ShareWechatFriend（）方法中，使用packageManager.getInstalledPackages（）方法獲取PackageInfo參數，根據PackageInfo的值判定是否安裝微信客戶端， 然后使用FileProvider.getUriForFile（）方法使保存在本地的.xls文件能提供給外部應用，最后使用setPackage（PACKAGE_WECHAT）與setAction（Intent.ACTION_SEND） 方法調用微信，加載出分享頁面，并分享創建的xls 文件。 分享頁面如圖13 所示。

圖13 分享頁面Fig． 13 Share page

3 系統測試

3．1 App 開發環境

本文開發的軌跡分析應用是一款在Windows7操作系統環境下，使用Android Studio 3.1.23 集成開發環境進行開發的軟件，其中Android SDK 開發工具包版本為API 29，適配Android 10.0（Q）平臺。 軟件的基本功能與核心算法全部使用Java 語言編程實現，軟件的可視化界面設計主要使用XML 語言與Java 語言完成設計。 開發中，Java 語言使用的開發工具包版本為jdk 1.8.0_301，保存與輸出的數據使用xls 文件格式存儲，使用Redmi Note 7 手機進行調試與測試，軟件輸出的所有結果都由測試機實測產生。 Release 版本的APK 文件大小在15 Mb 左右。

3．2 GPS 定位精準度測試

本文軟件使用百度定位SDK 采集單點定位信息，雖然定位信息已用相應的格式保存至Excel 表格，但是無法直觀地判斷采集的定位信息是否合理，因此設計了對比實驗，對軟件GPS 定位的精準度進行測試，測試方法如下。

使用谷歌GPS 定位手表采集的定位數據與軌跡分析App 采集的定位數據進行多次比對，并可視化兩者的軌跡路線圖。 GPS 手表的可視化使用谷歌專用的“GPX”軟件完成，軌跡處理App 定位數據的可視化由自主設計的可視化模塊完成；繪制二者的速度曲線進行對比，如圖14（a）、14（b）所示。

從圖14 中的速度曲線圖可看出，兩者采集的單點GPS 數據準確度基本一致，證明App 采集的單點定位數據的可靠性。

此外，由圖14（a）可知，0.6 ～1.2 h 的高速時段是一段客車的運動軌跡，但由于軌跡速度曲線并不穩定，容易出現類別誤判為停留點或者其他交通工具；圖14（b）中的紅色虛線部分，GPS 手表甚至出現速度異常片段。 上述現象表明，利用單點定位信息作為軌跡分段的依據是存在較大誤差的，這也是本文對軌跡進行切片與語義分段的一個重要原因。

圖14 精準度對比Fig． 14 Comparison of accuracy

3．3 軌跡分析測試

根據出行的距離，軌跡分析測試分為短程測試與長程測試。

3.3.1 短程測試

短程測試步驟如下:打開App→點擊開始定位開始采集定位信息→查看可視化軌跡→點擊結束定位→保存與分享文件。

本例短程測試的軌跡路徑為:教學樓停留-步行至食堂-食堂用餐-步行尋找共享單車-等待共享單車解鎖-騎車返回教學樓門口-步行進入教學樓。測試流程如圖15 所示。 軌跡采集過程中，軟件可退至后臺運行，整個操作過程只需點擊3 次按鈕。

圖15 短程測試Fig． 15 Short distance test

3.3.2 長程測試

由于測試人員在測試過程中不可避免會乘坐高速移動的交通工具，而此類交通工具的速度往往是不穩定的，因此增加長程測試來驗證語義分段算法處理此類軌跡的有效性。 測試結果是一段乘坐機動車的出行軌跡，由于存在紅綠燈、堵車等情況，機動車的速度不夠穩定。 將未使用語義分段的分析結果（圖16（a））與使用語義分段的分析結果（圖16（b））全部保存至本地進行對比，可以看出，使用語義分段算法后，將交通工具識別為自行車的軌跡片段歸化為了汽車。 最終的分析結果與實際相符，驗證了語義分段算法的有效性。

圖16 長程測試Fig． 16 Long distance test

4 結束語

本文基于Android 平臺與百度地圖SDK，開發了一款集軌跡采集、軌跡分析、軌跡可視化、軌跡分享四種功能為一體的軌跡綜合處理系統，能實現對軌跡進行實時采集并分析軌跡的多種語義信息，還可支持可視化與軌跡分享；App 可用于輔助解決通勤分析、職住協調、道路優化等問題，但由于研究時間的局限性，App 中仍有一些不足之處，其功能也有待進一步開發。 今后可優化或添加如下功能:

（1）實時繪制軌跡功能。 在軌跡分析App 中，可視化模塊是在用戶停止定位后可視化整段軌跡的，不夠直觀。 今后可將可視化模塊升級為實時繪制模塊，這樣在采集定位信息的過程中就開始繪制軌跡，能使用戶更直觀地了解到當前的軌跡動向，帶來更好的交互性。

（2）語義分段優化。 語義分段還不夠精準。 在遇到復雜的軌跡路線或者苛刻的定位環境（地鐵站內）會導致語義分段生成的結果不夠精準。 今后可考慮將附近POI 類型或者車道信息納入語義分段的判斷條件中，以進一步提高軌跡分析的準確度。