系統架構

圖 4-1 系統架構圖

如圖 4-1 是實際所開發出的系統架構。此系統主要分為兩部分：Server 端 和 Client 端。而 Server 端為主要為 Search Engine、Data Analysis、Analysis Management 以及 Common Management。

I. Data Analysis：於臺北市政府公開資料進行更新且把獲得的檔案轉換為 RDF 正規化格式，根據資料不同進行每兩或三分鐘執行抓取動作，且將當 下所得到之即時資訊儲存到資料庫中，進一步處理且分析。

II. Search Engine：其中細分為四大部分。

i. Reduce Size Analysis：首先從 Client 端發出請求和情境資訊進行

分析，判斷有無符合觸發規則。同時 Reduce Size Analysis 會將 Common Management 整合發出要求資訊進一步條件分析且判斷。

ii. Arrive Time Analysis：從 Client 端發出請求和地理環境及時間情境 資訊進行分析，利用捷運行駛即時資訊進行計算，判斷捷運多久 會到達以及此路線是否為使用者目前會到達的列車。

iii. Information Integrator：把 Reduce Size 所分析出的結果和 Arrive Time Analysis 所計算出的結果進行四份檔案的相互整合鏈結，四 份檔案分別為：「停車場地理環境資訊」、「停車場動態車位」、「微 笑單車站點資訊」以及「捷運資訊」，四份檔案已事先處理為 RDF 格式不同檔案。

iv. Query System：此為 Linked Open Data 之 Query 介面，能把上述的 步驟經過處理的檔案進一步做存取和搜尋的動作，由於所有的檔 案已事先處理轉換為 RDF 格式檔案，Query System 可以利用 SPARQL 做資料存取的功能。

III. Common Management：此為進行管理常用站點，也可以透過使用者新增刪 除的需求進一步做資料存取的動作。

IV. Analysis Management：根據從使用者操作時所接收的時間及站點的資訊進 行分析，接著至資料庫中抓取與其對應的數據進一步做處理，給予合適推 薦。

V. Data Table：為了存取從臺北市政府開放資料和經過分析的數據所做的資料 庫欄位。

VI. Rate Analysis：此分析為將存取至資料庫中的微笑單車使用數據以每三十分 鐘為基準，把三十分鐘以內所獲得的數據進一步分析且將運算得出的結果 儲存至資料庫中，提供之後參考使用。

VII. JSON Converter：為了開發上的方便和降低流量之因素，在進行傳輸資料 時候把資料包裝為 JSON 送出。

Client 端，指的是使用者操作的 Android 行動裝置，其主要功能是瀏覽停車 場、微笑單車以及捷運資訊、偵測所處停車場與拿取分析的數據並推薦以及一 日遊規劃行程的安排，利用四個單元處理以上的事件：Common Operator 、 Parking Analysis、Query Request、Data Analysis Request Operator。

I. Common Operator：為常用站點操作單元，透過此單元能讓使用者針對常用 站點進行一系列的查詢、新增以及刪除的動作，主要為整合使用者的操作 行為和相關站點的資訊傳送至 Server 端給予合適處理。

II. Parking Analysis：使用者若操作有關停車場和微笑單車跨資料集之應用 時，此時系統將分析出使用者目前的位置是否為停車場。

III. Query Request Operator：為搜尋請求操作單元，透過此單元能整合使用者 目前地理情境資訊，也包括預設條件或者使用者自行的範圍條件，把整合 出的結果資訊回傳至 Server 端給予適當的搜尋做處理。

IV. Data Analysis Request Operator：為數據分析請求運算單元，若使用者預期 至 Server 端請求指定微笑單車的站點目前使用狀況以及合適的推薦，此時 會蒐集時間情境資訊和從行動裝置要求站點的資訊，將兩筆資訊整合並發 送至 Server 端來分析數據以及進行合適的推薦資訊，接著從 Server 端接受 到的結果呈現在使用者的螢幕中。