分析空位

1. 每隔固定時間，執行此Process。

2. 向台北市政府公開資訊平台讀取即時停車場空位資訊。

3. 納入預測模型。

圖片 3-14 活動圖 – 分析空位

第 4 章 系統開發與實作

4.1 系統架構

圖4-1

這是實際開發的系統架構。系統分兩部分，Server端及Client端。Server端主要有三個部分：Search Engine、Context Rule Management。

I. Search Engine：可細分兩部分Query System & Parking Info Integrator。

i. Query System：就是Linked Open Data的Query介面，可以讓我們存取「警察局資訊」、

「消防局資訊」、以及「停車場資訊」等台北市的公開資料；本應用僅會利用到「停車

圖片 4-4-1 系統架構

場資訊」。因為所有的資料已經事先處理成RDF格式，所以Query System是使用SPARQL 進行資料存取。Query System也會整合Context Rule資訊，以提供情境感知服務。

ii. Parking Info Integrator：實作時，停車場資訊會分成兩部分：『停車場描述』、以及『停 車場空位預測個數』，一個停車場會有24個停車場空位個數，例如上午9點空位預測個 數為X、上午10點空位預測個數為Y…。實作時會先依據給定的時間，擷取正確的空位 資訊，再利用Parking Info Integrator整合出完整的停車場資訊(包含完整的停車場描述以 及該時的空位預測值)。

II. Context Rule Management：用來管理使用者的情境規則，並且將這些資料整合至Search Engine 處理。

III. Available Analysis：其功能是分析空位資訊。該系統會持續向台北市公開資料要求目前的空 位資訊，並且將預測模型結果儲存在Available.rdf。

IV. JSON Converter：為了降低流量的大小、以及顧及開發上的方便，在傳輸資料前，會將資料 打包成JSON再送出。

III. 提供背景查詢並推撥：Android 系統有提供一個功能：『Service』，即便在 Application 主體 沒有開啟，也可以在手機背景執行一段程式。在這裡我使用 Service 的功能，在背景執行一

個計時器(timer)，每隔一段時間，便執行「主動查詢」的功能。主動查詢分成兩個部分：情 境規則搜尋、Google Calendar Event 搜尋

i. 情境規則搜尋：將使用者目前所在的區域與時間傳送至 Server，此時會將情境規則納入 Query System，判斷是否有符合使用者區域與時間的情境規則，如果有符合，再 Query 該區域與該時間的停車場資訊，傳回給使用者。使用者 Device 收到 Query 結果，會啟 用 Android 的另一個功能：『Notification』，把該則訊息以提示的方式，呈現在螢幕上 方的通知列，以達到主動推撥的效果。

ii. Google Calendar Event 搜尋：先讀取使用者的 Google Calendar 資訊，並過濾出可用的 Event 資訊，將該 Event 的區域、時間資訊上傳至 Server，交由 Query System 進行搜尋，

搜尋結果傳回使用者 Device，一樣利用『Notification System』通知使用者，達到主動 推撥的功能。

4.2 類別圖(Class Diagram)

這是Server端的Class Diagram，為了將各個資料模組化，所有使用的資料都有加以封裝。

1. DataSet：最基本的資料結構，儲存著很基本的資訊，例如：ID、Type、以及Name。其功能 只有基本的Setter與Getter。

2. OpenDataSet：繼承自DataSet的資料結構。就如第三章所說，我們會使用Location資料當做不 同公開來源資料的樞紐，也就是說，所有的公開資料理應都會具有Location的訊息，於是在 這資料結構新增了兩個參數：Address和Area。

圖片 4-2 類別圖

3. 為了讓橋接SPARQL Query的結果，所以建立了一個getInstance的操作，讓此物件可以具 Query的結果，建立對應的物件，所有的子類別也都會繼承這項操作。

4. ParkingGarage：繼承自OpenDataSet，且額外增加了記錄停車場資訊的參數，例如：Latitude、

Longitude、TotalCar(車位總數)、AvailableCar(空位個數)。

5. FireDepartment：繼承自OpenDataSet，額外增加聯絡資訊，包含Tele、Fax。

6. PoliceStation：繼承自OpenDataset，額外增加隸屬資訊。

7. Context：繼承自DataSet，且額外增加因應本研究的情境感知服務所需要的資訊，包含：

CtxArea(預計要停車的行政區域)、CtxParkingHour(預計要停車的時間)、Priority(該筆情境規 則的優先權)。

8. Context Management：用來處理情境規則的類別，不記錄額外的資訊。Context Management 與Search Engine有相依性，因為Search Engine會使用到Context Management的操作；Context Management一次可能會有0到多個Context Object。

9. Search Engine：用來處理SPARQL Query的類別，不記錄額外的資訊。Search Engine各自可 能會有0到多個PoliceSation、ParkingGarage、以及FireDepartment Object。

Client端基本是所有的Data都需要從Server端獲取，其資料架構也沿襲Server的設計。

4.3 循序圖(Sequence Diagram)

以下針對各個Activity實作的Sequence進行解說。

4.3.1 瀏覽停車場

此活動是由使用者所驅動。使用者選擇變數，也就是『區域』以及『時間』，Device就會送出查 詢訊息。為了不要造成使用者使用不便，以及維護Device的畫面順暢，查訊的動作是採取「非同步」

的方式。Search Engine會依據『時間』，整合出有「該時刻空位資訊」的停車場訊息，然後依據『區 域』進行查詢。把結果回傳給Android Device，Device便會重整畫面，呈現使用者想看的停車場資訊。

圖片 4-3 循序圖 – 瀏覽停車場

此時使用者可以點選任一停車場，觀看詳細的停車場資訊及地圖資訊，並且可以啟動Google Map導航 功能。

4.3.2 查詢情境規則

此活動由使用者驅動。使用者欲瀏覽目前所有設定好的情境規則，於是向Android Device送出要 求，Device便會向Context Management要求目前所有的規則。為了不要造成使用者使用不便，以及維 護Device的畫面順暢，查訊的動作是採取「非同步」的方式。Context Management收到要求，便直接 將目前所有的情境設定回送給Device。Device收到，更新使用者畫面，呈現所有接收的情境規則，讓 使用者瀏覽。

圖片 4-4 循序圖 – 查詢情境規則

4.3.3 新增情境規則

此活動由使用者驅動。使用者輸入新的情境規則(『時間』及『區域』)，Device便會像Context

Management送出「新增要求」。Context Management新增該筆規則後，會回傳「確認訊息」，Device 確認到底是否新增成功，一旦確認，會顯示成功訊息，並且向Context Management要求目前的所 有規則，呈現在螢幕上。如果新增失敗，則會顯示失敗訊息。

圖片 4-5 循序圖 – 新增情境規則

4.3.4 刪除情境規則

此活動由使用者驅動。使用者選擇要刪除的情境規則，Device便向Context Management發出請求。

Context Management依照要求刪除該則規則，並回傳「確認訊息」。Device確認刪除成功，會顯示成

圖片 4-6 循序圖 – 刪除情境規則

功訊息，並且向Context Management要求目前的所有規則，呈現在螢幕上。如果新增失敗，則會顯示 失敗訊息。

4.3.5 主動搜尋 – 情境規則搜尋與推播

此活動由Android Device開始，是由持續在Android背景執行的『Timer』所驅動。啟動後，利用 Android提供的Sensor，配合Google Geocoding API，獲得使用者目前的『時間』及『區域』 ，上傳給 Search Engine進行判斷。Search Engine會依據『時間』，整合出有「該時刻空位資訊」的停車場訊息。

接者Search Engine會向Context Management要求目前的情境規則，以便進行情境感知搜尋。用獲得的 情境資訊：『地區』、『時間』作為key，檢查所有設定的情境規則，是否有任一則符合使用者的情 境資訊，如果有符合，就會依據該情境進行Query。例如一則情境規則為：「13點時，大安區」，而 獲得的使用者情境正好符合這兩項，則會找出位於大安區的停車場，並且包含13點時的空位預測資訊。

不論是否有符合的情境，都會把結果回傳給Device。Device判斷回傳結果是否有包含推薦的停車場資 訊，如果沒有，就不做進一步的行為；如果有，則會將利用Notification通知使用者。使用者如果看到，

可以點擊通知，瀏覽所推薦的停車場、甚至進行導航。

圖片 4-7 循序圖 – 主動搜尋(情境規則搜尋與推播)

4.3.6 主動搜尋 – Calendar Event 搜尋與推播

圖片 4-8 循序圖 – 主動搜尋(Calendar Event 搜尋與推播)

此活動由Android Device開始，是由持續在Android背景執行的『Timer』所驅動。啟動之後，會 去讀取使用者的Google Calendar，並且判斷是否存在有效的Event。如果沒有，則不做進一步動作；

如果有，就會擷取Event的『地區』、『時間』資訊，上傳至Search Engine判斷。Search Engine依據『時 間』，整合出有「該時刻空位資訊」的停車場訊息。接者就針對『地區』，取得該『地區』的停車場，

並且將結果回傳。Device收到回傳，利用Notification通知使用者。使用者如果看到，可以點擊通知，

瀏覽所推薦的停車場、甚至進行導航。

4.4 實作畫面

4.4.1 瀏覽停車場與導航

使用一進入 App 就是停車場瀏覽畫面，點擊畫面左上角可以選擇時間以及區域。

圖片 4-9 瀏覽停車場/選擇時間與區域

使用者點擊其中一個停車場，可以觀看該停車場的訊息。點擊右上方的『NAVI』，可以呼叫Google Map進行導航。

圖片 4-10 觀看停車場訊息，並且啟動導航

4.4.2 瀏覽、新增情境規則

使用者可以瀏覽目前所設定的情境規則。點擊有上角的『ADD』，可以新增情境規則，確認規則

之後按『COMMIT』即可完成新增。

圖片 4-11 瀏覽情境規則，新增情境規則

4.4.3 系統主動推薦

依據情境規則或是Canledar Event，推薦合適停車場。推薦結果顯示在系統通知列(Notification)。

點擊通知可進行瀏覽。

圖片 4-12 系統主動推薦，瀏覽推薦

第 5 章 結論與未來發展

5.1 結論

本研究為了能讓台北市政府公開資料能靈活運用，激發更多的價值，採用 Tim Berners-Lee 於 W3C 所制定的鏈結開放資料分類鑑定準則，使用 RDF 去描述來自不同單位、不同種類的資料，並且建立

Linked Open Data Diagram，讓資料的格式更加統一，使得開發者能更容易運用，並且藉由彼此的鏈 結，資料交互運用。本研究以『地理資訊』做樞紐，讓資料即可以相互連結，實現了跨資料及的搜尋，

Time-based、以及 Event-based 的情境應用。當科技不斷的進步，人人身上都有高強運算的智慧型手 機，開發者的應用也應該能繼續往使用者面相延伸，藉由理解使用者的情境，提供對應服務，讓應用 更具有智慧。

5.2 未來發展

本論文使用台北市政府公開資料提供的部份資料(包含台北市停車場資訊、台北市警察局名稱及 地址)、以及台北市政府消防局各單位通訊錄)，建立對應的 Linked Data Diagram，並且開發 RDF

Interface，提供應用程式作為開發平台。雖然所蘊含的資料種類以及資料個數並未特別多，但是已經 能夠充分感受到透過資料 RDF 化、建立 Linked Data Diagram 所帶來的力量以及潛力，例如存取方便、

格式不再混亂、多元存取…等等。未來可以將更多台北市政府所提供的公開資料，進一步正規化，建 立一個更完整的台北市 Linked Data Diagram，讓更多的資料，以更容易的方式讓市民運用。除此之外，

也期待藉由台北市政府公開資料的鏈結效果，可以跟其他縣市政府單位的開放資料進行連結，建立一 個全國公開資料的資料網路。甚至，期待本研究的 Linked Data Diagram，能夠跟網路上更多的 Lined

也期待藉由台北市政府公開資料的鏈結效果，可以跟其他縣市政府單位的開放資料進行連結，建立一 個全國公開資料的資料網路。甚至，期待本研究的 Linked Data Diagram，能夠跟網路上更多的 Lined