地理空間資料網路服務:WMS和WFS

1.網路地圖服務(Web Map Service, WMS)

網路地圖服務(Web Map Service, 以下簡稱WMS)是OGC對於地圖查詢的服務,其原始的設計理念是希望從擷取網路中所散佈的資料庫地理資訊及屬性資料,以產生客製化的地圖,且地圖一般是以JPEG、GIF或PNG等格式儲存,此外並支援SVG (Scalable Vector Graph)及WebCGM,是表現地理資料的圖形視覺化最直接的工具。WMS的規範即是客戶端向伺服器端要求圖資與伺服器端如何對客戶端表現圖資的標準化方法。WMS伺服端是透過http和使用者互動,因此使用者是透過URL傳送CGI(Common Gateway Interface)參數和WMS伺服端互動。符合OGC WMS規範的CGI應可接受三種請求和回應,分別為Metadata(詮釋資料)、Map(地圖)和FeatureInfo(圖徵資訊)。也因此WMS定義了三項基本標準操作為GetCapabilities(能力取得)、GetMap(地圖取得)和GetFeatureInfo(圖徵資訊取得)。

(1)GetCapabilities(能力取得) (必要的):此操作之功能為讓客戶端取得伺服器端的詮釋資料,而回覆客戶端的是該服務內容的詮釋資料,為一以XML編碼的文件;所提供給客戶端的資訊包括WMS server所支援的WMS操作,提供資料的詳細內容(如圖層名稱、標題、樣式、空間參考系統等)等。

(2) GetMap(地圖取得) (必要的):此操作之目的在於請求伺服器生成一幅具有確定地理位置座標範圍的地圖,但按照WMS的規範,這個操作需要明確地指定出操作本身遵循的WMS規範的版本號,如WMS 1.1.0或WMS 1.1.0,以及需要顯示的圖層、對應的座標範圍、請求地圖的大小和格式等。

(3) GetFeatureInfo(圖徵資訊取得) (選擇性的):所支援的情況為,當某一圖層定義或繼承「可查詢」(queryable)的屬性,其值等於1(true)時,客戶端便可依使用需求所取得的地圖資料,獲得相關的圖徵資訊、屬性資料等。典型的做法範例為,當使用者取得查詢的地圖後,點選圖上某點(I,J)以取得更多的資訊,而基本的操作提供了客戶端指定像素、所調查的圖層以及最後輸出的資料格式(可支援格式包括txt文件形式、html網頁格式及GML圖徵表示)。

2.網路圖徵服務(Web Feature Service, WFS)

OGC的WFS是描述、展現圖徵資料的運作方式,讓伺服器端和使用者能在圖層上溝通,獲得圖層底下各圖徵的資訊,其核心協定為GML,是資料交換流傳的重要方式。如同WMS,使用者可透由URL傳CGI參數和WFS伺服端互動;亦可透過XML文件遞交操作請求。這個OGC的介面提供了標準的圖徵資料庫擷取方式,以及如何讓使用者在網際網路或內部網路中製造、更新或修改GML圖徵資料,當客戶端傳送一個查詢的訊息給OGC的WFS時,伺服器可以GML提供地理圖徵資料以回應客戶端,因此WFS被視為GML資料的伺服器。WFS以http作為分散式的計算平台處理圖徵資料,所支援的操作包括了插入、更新、刪除和查詢。最基本的WFS應支援GetCapabilities (能力取得)、DescribeFeatureType (描述圖徵型態)和GetFeature (圖徵取得)三項操作,即僅提供「唯讀」的操作。而Transaction (執行)和LockFeature (鎖住圖徵)不是必要的,其中Transaction (執行)提供使用者互動性操作,如新增(insert)、更新(update)、刪除(delete)圖徵,其各項操作說明如下:

(1)GetCapabilities(能力取得) (必要的):藉由此項操作,伺服端會產生並回傳一個XML文件說明WFS伺服端所能提供的服務。該文件說明WFS提供服務何種型態的圖徵,使用者可以對提供服務的圖徵進行何種的操作,其文件規格與前面提過的WMS文件規格的定義大致相同,所差異者在於,WMS文件結構是由DTD(Document Type Definition)所定義,而WFS的文件結構則由Schema定義。

(2)DescribeFeatureType(描述圖徵型態) (必要的):此操作包含了零至數個型態名稱(type name)以描述圖徵型態的編碼。當使用者端提出此項請求時,WFS伺服器會產生一個文件,以描述WFS提供服務的圖徵型態結構。預設輸出為XML綱目( Schema)文件,藉由這項資料可以用來驗證由WFS伺服端所回覆的GML圖徵資料,或使用者在執行圖徵交換操作時所輸入的GML圖徵資料。除XML綱目( Schema)格式外,亦可支援其他格式,但必須於能力(capabilities)文件中言明。一般而言,XML Schema文件僅能描述單一名稱空間下的圖徵元素,此時WFS伺服端可產生一個包裝綱目(wrapper schema)以引入多個綱目(schema)以描述來自不同名稱空間的圖徵。

(3)GetFeature(圖徵取得) (必要的):使用者端提出GetFeature (圖徵取得)要求時,可指定圖徵中欲擷取的屬性資料。該操作包含了一個或多個元素的描述,用以定義欲查詢何種圖徵型態、欲輸出的屬性,及在何種空間或分空間的限制下應用此一屬性。

(4)Transaction(執行) (選擇性的):此功能係用以描述資料圖徵的修改操作,使用者透過WFS提供的transaction(執行)服務,可新增(insert)、更新(update)、刪除(delete)圖徵,當Transaction的操作完成,WFS將產生一XML文件以指出transaction(執行)的完成狀態。其中,假如服務支援LockFeature的鎖定操作時,可透過的應用指定鎖定的圖徵以進行transaction(執行)的操作。

(5)LockFeature(鎖住圖徵) (選擇性的):在Transaction(執行)的期間對一個或多個圖徵執行鎖定的要求,以確保當某個圖徵在執行transaction(執行)時,不會被其他使用者存取並修改。

參加「高程資料流通共享標準制度規劃建置作業」專家會議的心得

目前成大洪榮宏老師幫內政部制定一系列關於國土資訊系統的標準制度,包括「資料標準共同規範」、「詮釋資料標準」、「行政界線標準」、「地籍資料標準」、還有本次的「高程資料標準」。

就Open GIS的理念而言,資料標準是為了資料流通,但OGC制定的GML雖然有豐富的地理語彙可使用於地理資料的標示,但因GML Schema或者說XML Schema較為彈性架構,使得同樣的資料有可些有不同的地理資料模型產生,在這裡的case,是這麼多的資料標準下,若有一個共同的資料標準模型,有助於程式開發的人有一個設計的準則,也使得後續處理元件開發才能環環相扣,所以看到這一系列的標準,心中的疑問是這些標準的有無共通模型,而這個模型是一個更高等級,或是說更抽象等級的資料模型,用來限定這些資料標在一定的範圍與邏輯思考,然而,答案是否定的。「資料標準共同規範」看起來只規定限用ISO的標準和XML技術,另一方面,各個分項資料之間交由各個權責單位來負責,也無相互的溝通機制,當然使用GML已經是共同標準,但後續可能要為了處理不同層次的GML文件,所花的efforts恐怕也不少,這是一個還沒發生的問題,可是未來可能發生。

這個專家會議果然來的都是高程資料的專家,但是專家似乎對於資料模型(Data Model)不是很了解,針對的都是資料的專業知識,至於application schema應該長的如何,好像沒有人有太多的想法,反而把焦點放在資料的生產過程和資料的轉換問題。但interoperability的重點應該把焦點放在application schema是否能夠充份解釋data model,以致於資料交換上不產生落差,資料生產的精度和方法,以致於資料轉換的問題,事實上不是這裡的重點,這部份都放在metadata來解決就好了!!所以主要的問題還是在於認知的問題,資料交換的議題是在於某一單位所釋放出來的資料是否能被其它單位無隔閡、無障礙地讀取或使用,資料精度是資料品質的問題,資料模型才是資料交換過程中決定交換的關鍵。