連結感測器資料(Linked Sesnor Data): 從氣象測站到連結資料

緣起

會進行這個Linked Sesnor Data的試作有一些緣由,把時間拉回2013年8月1日在環保署召集的「環境資源資料開放專家諮詢會議」,開會目的除了討論環保署資料開放平台,更是在於討論紫外線測站資料來當開放資料五顆星的範例。太酷了! 環保署願意進行開放資料5顆星的示範是一件很棒的事! 不但有助於環保署所屬開放資料品質的提昇,也可以刺激其它政府部會對於開放資料品質的關注。但會中業務單位所簡報的那個「紫外線測站的五顆星開放資料」是問題多多,對於OWL/RDF有了解的人,其實不難發現簡報中的那份RDF是有問題的,況且把資料編譯為RDF格式充其量就是4顆星等級,怎麼可以說是5顆星呢?再者,所謂的5顆星開放資料是要連結什麼呢!?

這個問題後來成為與會專家要給予的答案。資料集與資料集要連結,這之間就必需要有某一些關連,也就是所謂的context,以致於資料集中的某一個entity可以與另一個entity以某種形式相連,在普遍的做法就是用owl:sameAs來表達在不同資料集中的二個entity是一樣的,以我有限的所知,資料集之間的context可以由三個特性來思考: 地理空間(Geospatial)、時間的(Temporal)、和主題屬性的(Attributiive),以環保署開資料平台中的紫外線測站資料為例,有可能連結的部份看來只有地理空間的特性了! 就資料特性而言,若環保署要做Linked Open Data (LOD),建議應該朝向Linked Sesnor Data,就是把所有測站以OGC的Sensor Web Enablement (SWE)W3C SSN Ontology 二者來表達環保署中的測站,而測站所產生的資料則是以Linked Observation Data 來詮釋。

 

IMG_20140103_121214從Sesnor nodes組成sensor network,然後以OGC SWE來架構Sensor Web,所以容易再以W3C SSN Ontology表達

 

IMG_20140103_121156Linked Sesnor Data, Linked Observation Data, and Geonames

 
很遺憾的是,他們並沒有採納這些意見,在環保署開放資料平台上線後,12月初無意間看到,那個有問題的說明己經在環保署開放資料5顆星的頁面上,而有問題的RDF資料也提供下載。這種做法給了二個不好的示範,首先,在專家會議中,本人就不認為那是對的說明和對的RDF資料,但這些內容和資料還是上線了,好吧! 意見也給了,那專家會議的用意什麼? 另一個是比較嚴重的問題是,把錯誤的LOD說明和資料放在一個政府公署開放平台的網頁上,很容易就會誤導其它人,對於LOD的理解,開放也得開放「對」的資訊,是吧! 身為市井小民所幸可以透過平台「意見回饋」反應機制,向環保署說明,那份說明的LOD頁面和RDF資料有問題,哈! 意見回饋比專家會議有效耶! 環保署在一週後拿掉在資料開放平台上的那些LOD資料,所以大家己經看不到了,接著承辦這項業務的人員也來拜訪,並帶著修改的RDF來討論。的確,修改後的RDF,使用了標準語彙,如Dublin Core,但看起來就是一份單純由表格轉為RDF的文件,這不見得有錯,但語意的表達是相當弱的,對於紫外線測站詮釋,也就是紫外線測站所表達出的概念是什麼?並沒有辦法得知。

或許,你心中油然而生一個問題,「疑!那些LOD的資料,在網頁看起來都像是表格一樣,那資料轉成這樣有什麼問題?」嗯! 那些LOD的資料背後其實都有一個ontology來表達資料的語意,只是放上網頁為了瀏覽方便而表現成表格的形態,利用標準語彙也是在確保資料語意不被誤解,但ontology中,概念的結構和邏輯的規範可以使資料語意更為完備,並可以進一步達到邏輯推理,當然目前我們只需要達到將資料本身概念充份地表達,在這個紫外線測站的案例中,如同前面所說,還是採用W3C SSN Ontology來表達紫外線測站才是比較恰當的方式。

從建構知識本體(ontology)開始

這筆所謂的紫外線測站基本資料所記述的資料相當有限,主要項目如下:

  • 紫外線測站的中英名稱
  • 紫外線測站所在的縣市鄉鎮
  • 紫外線測站的空間座標和住址
  • 紫外線測站的發佈機關

這筆有限的資料能表達出的內涵確實不多,若只根據這些項目編出的ontology應該也很空洞,對於一個用來表達紫外線測站的ontology而言,不僅僅是要表述地理空間的描述,更重要是要表達什麼是紫外線測站和紫外線測站觀測什麼。根據W3C SSN Ontology 對於感測器(Sesnor)的描述和定義,可以重新想想,要如何重新表達這筆紫外線測站資料:

  • 紫外線感測器本身是用來測量紫外線(Ultraviolet)的
  • 紫外線觀測是以紫外線指數(UV Index)
  • 紫外線感測器是裝在中央氣象局的氣象站或環保署的空氣監測站
  • 無論是氣象站或空氣監測站都有空間座標、地址、和所在行政區域

W3C SSN Ontology 這份報告附有很多案例是可以依循的,其中對於Linked Sesnor Data 就有一個案例,對於紫外線測站資料,不就是一個很好拿來模仿的案例! 對於感測器(Sesnor)的描述和定義,這個案例中主要使用W3C SSN ontology和DUL(DOLCE Ultra Light) ontology,此外也描述感測器(Sesnor)觀測能力和裝在氣象局的事實,更重要的是這樣表達的感測器(Sesnor)是可以被連結(link)。根據這個架構,可以設計一個ontology來解釋這筆紫外線測站資料,而這個ontology 不單單只有紫外線測站的ontology,而應該是感測器知識本體(sesnor ontology),且可以應用在任何不同的感測器上,我習慣先用畫圖把需要的class和individuals先勾勒出來,以便後續ontology的編輯。

uv_ontology根據W3C SSN 和 DUL設計的紫外線感測器ontology

 
與寫程式類似,ontology的編輯可以用文字編輯器,但也有一些工具輔助,一般常用的工具為Protégé,根據上面那個畫好的圖,這個UV sesnor ontology 很快就能完成。
 

Linked Data: 讓自己可以被連結,也可以連結別人

一一解釋UV Sesnor Ontology中類型(class)和個體(individual)會是冗長的說明,為了有效率的說明UV Sesnor Ontology中的知識表達,以下是擷取部份段落來做解釋:
 

Solar501A (亂瞎掰的)感測器本身是用來測量紫外線(Ultraviolet)的,安裝於台北氣象站的系統平台上,且有量測紫外線指數(UV Index)的能力,而紫外線指數有15個等級,每一個等級就是100焦身/每平方公尺,例如8就是測到紫外線800-899焦身/每平方公尺。紫外線指數又可以分級為低量級、中量級、高量級、過量級、和危險級,下面案例只顯示紫外線指數8-10是過量級。

 

###  http://lod.tw/ontologies/weather-station/uv#Sensor_Solar501A

:Sensor_Solar501A rdf:type ssn:SensingDevice ,
                           owl:NamedIndividual ;

                  ssn:onPlatform :Platform_for_Taipei_Weather_Station ;

                  ssn:hasMeasurementCapability :UV_Index_MeasurementCapability .

###  http://lod.tw/ontologies/weather-station/uv#UV_Index_MeasurementCapability

:UV_Index_MeasurementCapability rdf:type ssn:MeasurementCapability ,
                                         owl:NamedIndividual ;

                                ssn:inCondition :UV_Sacle ;

                                ssn:forProperty :Ultraviolet .

###  http://lod.tw/ontologies/weather-station/uv#Ultraviolet

:Ultraviolet rdf:type ssn:Property ,
                      owl:NamedIndividual .

###  http://lod.tw/ontologies/weather-station/uv#UV_Sacle

:UV_Sacle rdf:type ssn:MeasurementRange ,
                   owl:NamedIndividual ;

          ssn:hasValue :UV_Index_0_interval ,
                       :UV_Index_10_interval ,
                       :UV_Index_11_interval ,
                       :UV_Index_12_interval ,
                       :UV_Index_13_interval ,
                       :UV_Index_14_interval ,
                       :UV_Index_15_interval ,
                       :UV_Index_1_interval ,
                       :UV_Index_2_interval ,
                       :UV_Index_3_interval ,
                       :UV_Index_4_interval ,
                       :UV_Index_5_interval ,
                       :UV_Index_6_interval ,
                       :UV_Index_7_interval ,
                       :UV_Index_8_interval ,
                       :UV_Index_9_interval .

###  http://lod.tw/ontologies/weather-station/uv#UV_Index_8_interval

:UV_Index_8_interval rdf:type DUL:Region ,
                              owl:NamedIndividual ;

                     :hasMeasurementPropertyMaxValue :UV_Index_8_max_value ;

                     :hasMeasurementPropertyMinValue :UV_Index_8_min_value .

###  http://lod.tw/ontologies/weather-station/uv#UV_Index_8_max_value

:UV_Index_8_max_value rdf:type DUL:Amount ,
                               owl:NamedIndividual ;

                      DUL:hasDataValue "8.99"^^xsd:float ;

                      DUL:isClassifiedBy :Hecto_joule_per_square_meter .

###  http://lod.tw/ontologies/weather-station/uv#UV_Index_8_min_value

:UV_Index_0_min_value rdf:type DUL:Amount ,
                               owl:NamedIndividual ;

                      DUL:hasDataValue "8.0"^^xsd:float ;

                      DUL:isClassifiedBy :Hecto_joule_per_square_meter .

###  http://lod.tw/ontologies/weather-station/uv#Very_High_Risk

:Very_High_Risk rdf:type ssn:FeatureOfInterest ,
                         owl:NamedIndividual ;

                rdfs:label "過量級"^^xsd:string ;

                ssn:hasValue :UV_Index_10_interval ,
                             :UV_Index_9_interval ,
                             :UV_Index_8_interval .

 

台北氣象站的系統平台是台北氣象站的一部份,台北氣象站是中央氣象局的一部份,而台北氣象站和中央氣象局都是一種組織(Organization)。

 

###  http://lod.tw/ontologies/weather-station/uv#Platform_for_Taipei__Weather_Station

:Platform_for_Taipei__Weather_Station rdf:type ssn:Platform ,
                                               owl:NamedIndividual ;

                                      ssn:attachedSystem :Sensor_Solar501A ;

                                      DUL:hasLocation :Site_Taipei_Weather_Station ;

                                      DUL:isPartOf :Taipei_Weather_Station .

###  http://lod.tw/ontologies/weather-station/uv#Taipei_Weather_Station

:Taipei_Weather_Station rdf:type :Weather_Station ,
                                 owl:NamedIndividual ;

                        rdfs:label "Taipei"^^xsd:string ,
                                   "台北"^^xsd:string ;

                        DUL:isPartOf :Central_Weather_Bureau_Taiwan ;

                        DUL:hasLocation :Site_Taipei_Weather_Station .

###  http://lod.tw/ontologies/weather-station/uv#Weather_Station

:Weather_Station rdf:type owl:Class ;

                 rdfs:subClassOf DUL:Organization .

###  http://lod.tw/ontologies/weather-station/uv#Central_Weather_Bureau_Taiwan

:Central_Weather_Bureau_Taiwan rdf:type :Government_Organization ,
                                        owl:NamedIndividual ;

                               rdfs:label "中央氣象局"^^xsd:string .

 

台北氣象站是在台北氣象站場址(site),這個場址是一個地方(Place),有一個WGS 84 XY座標的參考點(reference point),且這個場址有一個地址(Address),這場址也在一級行級行級區的台北市之中和二級行政區的大安區之中,且大安區也在台北市之中,而台北市在台灣之中。

 

###  http://lod.tw/ontologies/weather-station/uv#Site_Taipei_Weather_Station

:Site_Taipei_Weather_Station rdf:type DUL:Place ,
                                      owl:NamedIndividual ;

                             geo:hasGeometry :Reference_Point_Taiepi_Weather_Station ;

                             vcard:hasAddress :Address_Taipei_Weather_Station ;

                             :is_in :Daan_District ;

                             :is_in :Taipei_City .

###  http://lod.tw/ontologies/weather-station/uv#Reference_Point_Taiepi_Weather_Station

:Reference_Point_Taiepi_Weather_Station rdf:type geo:Point ,
                                                 owl:NamedIndividual ;

                                        wgs84_pos:long "121.55834"^^xsd:float ;

                                        wgs84_pos:lat "22.036934"^^xsd:float ;

                                        geo:asWKT "Point(121.5583420000, 22.0369330000)"^^sf:wktLiteral .

###  http://lod.tw/ontologies/weather-station/uv#Address_Taipei_Weather_Station

:Address_Taipei_Weather_Station rdf:type owl:NamedIndividual ,
                                         vcard:Address ;

                                vcard:street-address "公園路64號"^^xsd:string ;

                                vcard:locality "台北市"^^xsd:string ;

                                vcard:country-name "台灣"^^xsd:string ;

                                vcard:region "大安區"^^xsd:string .

###  http://lod.tw/ontologies/weather-station/uv#Daan_District

:Daan_District rdf:type lodtw:2nd_Administration ,
                        owl:NamedIndividual ;

               :is_in :Taipei_City ;

               owl:sameAs freebase:Daan District ,
                          geonames:Daan District .

###  http://lod.tw/ontologies/weather-station/uv#Taipei_City

:Taipei_City rdf:type lodtw:1st_Administration ,
                      owl:NamedIndividual ;

             :is_in :Taiwan ;

             owl:sameAs freebase:Taipei ,
                        geonames:Taipei ,
                        wikidata:Taipei ,
                        depedia:Taipei.

 
眼尖的你不難的不發現,上述的每一個「類型(Class)」和「個體(individuals)」都是以URL方式呈現,如http://lod.tw/ontologies/weather-station/uv#Taipei_City; 且上一段中的台北市和大安區都己經以owl:sameAs分別連結到DBPediaGeonamesWikidata、或Freebase,如UV sesnor ontology中的Taipei_City是以owl:sameAs連結http://rdf.freebase.com/ns/m.0ftkx, http://sws.geonames.org/7280290/, http://www.wikidata.org/entity/Q1867, 和http://dbpedia.org/resource/Taipei。與一開始所做的分析一樣,在這筆資料中地名是最有可能拿來連結其它資料的實體(entities)。

最後,想強調的是,編寫這個UV Sesnor ontology用意在於讓更多人了解什麼是LOD,並期待能引發更多LOD的討論,而能有更多更正確的LOD資料。

地理資訊的相互操作性 (Interoperability of GI)

相互操作性(interoperability)是一個系統的能力或系統的組成,可以輕便地提供資訊和應用程式間相互配合中過程的控制(Bordie,1992;Zhang等人,2003),可區分出二種型態的相互操作性,對於程式而言,資料的相互操作性代表使用資料格式範圍的能力,對資料集(dataset)而言,程式的相互操作性是資料可被不同型態程式所使用。要達成資料的相互操作性可透過二個方法,即為資料庫整合和標準化。現今資料庫整合已有成熟的方法,一個最基本的方式是提供使用者一個全部的可獲取資訊來源的目錄,其目錄中的每一個來源是被相關的詮釋資料所描述,包含表現方式、比例尺、最後修改日期和資料品質等級等,但資料庫整合的缺點是缺乏彈性、一致性和可複製性;第二種達成相互操作性的方法是透過標準化,標準資料模式的定義成為系統之間相互關連的點,且可被運用的特徵,使資料在異質系統間交換(Devogele等人,1998;Zhang等人,2003)。

相互操作性是系統或系統中元件的能力,可以便利地提供資訊和內部應用程式協同過程的控制,例如,有二個地理資料庫X和Y。X資料庫以「服務R」傳送需求(request)到Y資料庫,若要能使此二資料庫達到相互操作性,R必需是X和Y資料庫相互彼此了解的規範,才能使Y資料庫因而可以回覆給X資料庫一個S,而S是相互彼此間了解的資料格式(Brodie,1992;Bishr,1998)。在這個過程中,有二種相互操作性可以被分出來,對程式而言,相互操作性是指程式有能力處理廣泛地資料格式:對於資料集而言,相互操作性則是指資料可被使用在不同型態的程式中(Laurini,1998)。在加強元件式(component)資訊系統之間合作的系統智能(intelligence)中,相互操作性更可被勾勒出特性,此智能是在元件式資訊系統之間且不需要詳盡且精確的知道什麼資料是可用的或如何需要的資源的情況下,即能提供服務、尋找資源、協同及實行複雜的功能(OGC,2002)。

interoperability

同時,Bishr (1998)進一步地認為地理資訊系統的相互操作性可分為6個等級,如圖所示。最低等級的相互操作性依賴簡單的網路協定即可完成,在這個等級的使用者通常只可以下載未經處理的檔案(flat files),遠端的GIS根本幫不上忙,這個等級的很好的交流案例是TELNET,在這其中使用者登入到遠端系統,也就是主機,不用多餘的網路協定的知識即可達成,但這個等級的主要問題是使用者為了連上主機,必需有運作遠端機器的操作知識。第二等級則是進步到更高等級網路協定,其中使用者可以連結到主機且緊密地互動而不用它的操作系統。FTP協定是這個相互操作性等級最佳案例,在FTP中,使用者可使用FTP所屬的指令來連結主機和與主機互動。在這個等級使用者只可以在系統間轉換資料檔案。在這個等級中,主要的缺點是使用者必須對所轉換的資料格式有良好的知識背景,了解什麼樣的檔案格式需要什麼樣的轉換工具。

更進一步地,第三等級的相互操作性為空間資料檔案,使用者可以下載標準的資料檔案且系統可自動辨識,因而可以轉換成使用者所使用的格式,加拿大的DeltaX計劃,即是一個很好案例,它是一個使用者端的空間資料瀏覽器,使用者可透過它來下載資料,並轉換成使用者端所使用的空間資料格式。但這個等級的缺點是,使用者必須事先知道什麼資料放在有什麼來源位置,且只能使用它的使用者介面(user interface)和查詢語言(query language)來尋找空間資料的內容。第四等級之相互操作性是可以使二個系統更進一步的溝通,現在已經有一些GIS軟體可提供,例如Intergraph的Jupiter和Microsoft的ODBC。客戶端/伺服器端技術可讓使用者建立他們的GIS和遠端GIS之間的溝通,一旦建立,他們可查詢遠端系統而使用他們自己的查詢語言,當然也可能分析和展示遠端資料集,然而,主要的缺點是使用者必須了解在遠端資料庫中的資料模式之知識和語義(semantics)。

第五等級的相互操作性是提供一個單一的“虛擬”整體(global)資料模式,而這個資料模式是所有遠端資料庫中資料的抽象概念(abstraction),因此使用者所送出的查詢,會被送到這個整體資料模式來一一的相對映,讓使用者在這個等級可以更直接且準確地查詢遠端資料庫,如此更突顯事先了解資料的語義是一定須要的,如同二個GIS各自顯示不同主題圖有可能用一個資料模式,差別在於它們用各自的語義來達。上述任何一個等級都可稱為相互操作性,而每一個等級都對應到許多技術,相互操作可被改善或它的範圍可藉由技術層面提升而擴大,現在似乎還沒有GIS的相互操作性達到資料模式或應用程式語義層級,如上述的第五級或第六級,但隨著GIS和IT的發展,相互操作性高的GIS是可以被期待的。

以網際網路作為跨平台運作環境和工作流程,Open GIS是一種技術,可使得應用系統開發者能夠從網路上透明地獲取任何地理資料和任何地理資料處理功能或方法,而不管它的資料格式和資料模型,因此在各個應用領域中,應著重於的改變是各自地理資料模型或資料格式與中介的標準資料的模型與格式之間的差別。Open GIS不僅有助於GIS系統個體間之資訊交換,而且未來能夠與其他系統如統計分析、影像處理、文件檔案管理、視覺化交換資訊。

地理空間資料網路服務: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(執行)時,不會被其他使用者存取並修改。

什麼是地理標記語言? What is Geography Markup Language (GML)?

地理標示語言(Geography Markup Language,GML) 是OGC所提出的一種對地理物件進行編碼的語言。就資訊技術層面而言,GML是以可擴展標示語言(eXtension Markup Language,XML) 為編碼基礎的語言,主要對於地理資訊中地理圖徵(feature)的空間和非空間屬性之模式化、傳輸和儲存,並且達成下列目的(OGC,2003):

(1)透過網路對於分享和交換已編碼的地理資訊。
(2)對於不同領域的論述之地理語彙表達。
(3)對於地理的網路服務之資訊元素表達。

地理現象是複雜、多樣和多尺度的,要準確且有效率的在電腦環境中,甚至網路世界中操作,必須轉化於真實世界概念中地理資料模式(geospatial data models),以作為人與電腦溝通地理資料的中介。GML的應用並扮演了二個重要角色(OGC,2005) ,一是表現原始資料模式;另一是在地理空間資料基礎設施(Spatial Data Infrastructure,SDI)架構下,以GML文件在政府組織和商業團體中相互分享。目前實用性較高GML版本為GML 2.0和GML 3.0,其中GML 2.0符合地理空間資料庫或GIS軟體所奉行的簡易圖徵標準(Simple Feature Profile),同時也被眾多商業軟體所採行,如ESRI ArcGIS,然而GML 3.0則加強地理空間資料之表達上所需的型態與方式,支援了多種物件(objects)以描述地理資訊之位相關係、三維(3D)幾何性質、座標參考系統、時間屬性值、多種比例尺、metadata、網格(grid)資料、和對地形及區域做視覺化處理所需的預設樣式,且GML 3.0也大幅度地擴展內建元素(built-elements),這也是GML提供地理應用開發者最主要的部份。GML 3.0提供29個核心綱目(core schemas)於使用者對地理資料建立各自知識領域或專業領域的地理模式時使用,如此豐富地理描述語彙包含了超過10,000條的編碼充份地提供各知識領域所需。而GML 3.0提供地理物件的編碼包含(OGC,2003):

(1)地理特徵(geographic features),包括幾何(geometry)、位相(topology)和時間的演變(temporal evolution)。
(2)地理覆蓋(geographic coverage),包括幾何位置(geometry)和屬性值(attribute values)
(3)地理觀察(geographic observation),例如水文觀測,具有空間位置和時間動態資料的記錄。
(4)座標參考系統(Coordinate reference systems)。
(5)抽象值(abstract values),包括有測量單位的數值量化,和基於計算、分類和布林邏輯(Boolean)決定的觀測值。

GML的主要目的是提供一個一致性語言來描述地理物件,且透過這個方法所編碼地理空間資料可以輕易地分享在網路世界中。GML模式是基於物件導向技術(Object-Oriented)以直覺地建構真實世界的地理空間物件,因此GML的模式是由宣告地理物件和物件屬性所構成,Trninić (2005) 認為GML模式由幾個部份構成;首先是圖徵(feature),為基本地理物件,是來自於真實世界的抽象化,如道路或房屋;再者是幾何(geometry),是一種物件,而被用來描述地理物件的絕對位置,如點或多邊形;其次是位相(topology),也是一種物件,是用來描述地理物件的空間相互關係,如端點(node)或邊(edge);此外,地理物件也可以有許多屬性,如一個房子的具有多少房間是以表達,其「值」是一個整數型態和一個房子的空間屬性是以表達,其「值」是一個幾何座標的型態,如編碼表1。由此可見,每一個屬性有它自己的值,而值可能是一個簡單的型態,也可能是一個物件,因此GML模型是物件─屬性─值(object-property-value model),相對於ER(Entity-Relationship)模型,即為實體─關係─實體;或物件導向中物件─屬性─值模式(object-attributes-value)。

GML編碼技術是以XML Schema為基礎,是一個理想並適合於以分享為目的資料集。GML模式和它的核心綱目(core schemas)讓使用者可以描述所屬應用領用領域的地理實體,如同蓋房子前需要先畫好藍圖,這樣的藍圖不但得以在該應用領域被使用,一致性的表達方式,更使得這些地理資料亦可分享於其他應用領域中。GML核心綱目(core schemas)的元素是使用XML綱目(Schema)來構成GML的語義模式和語法規則,且GML是一個基於圖徵(feature)架構,因此一個地理物件通常可由一個或數個GML應用綱目(Application Schema)構成,如圖2所示,在GML名稱空間(namespace)中圖徵(feature)是由詮釋資料(Metadata)和幾何(Geometry)所組成,表示GML核心綱目中圖徵(feature)綱目 是由詮釋資料(Metadata)和幾何(Geometry)綱目所組成,而其它領域的名稱空間(namespace),如圖2的foo 1和foo 2應用領域中的schema 1、schema 2、schema 3所包含的元素(element),可以繼承GML架構中的物件,而根據各領域之專家對地理空間物件的模式,可建立以GML編碼模為基礎的應用綱目(application schema),而該應用綱目不但具有GML編碼規則與特性,同時又保有所屬領域中的對地理空間物件的闡釋,如此的物件可能包含道路、水溝、河流、建築物、山脈、崩塌地滑和斷層等各種的地理現象,而這些地理現象在GML中被稱為圖徵(feature),而這些圖徵在GML中是XML的元素(element),有明確的名稱(如)且藉由子屬性元素來描述,因此空間資訊將可利用GML當成一個交換標準以供各領域之專家來交換資料(Galdos Systems Inc., 2003)。

GML除了繼承XML的特色而有利於地理空間資料的交換,進一步地,剖析GML,可發現GML具有幾項特色,而被認為是解決資料相互操作性的重要基礎(Zhang等人,2003;鄧東波等人,2004):

(1) GML基於一個共通(common)的地理的抽象模型,而此模型描述真實世界中如何被一組圖徵(feature)所建構,地理圖徵是一個真實世界現象概括化物件,且該物件關連於地球上某一個空間位置,一個圖徵可有簡單的屬性和幾何屬性,簡單的屬性包括慣用的名稱、型態和值的描述,而幾何屬性可以是點、線和面所組成,因此由GML中的圖徵架構和屬性可使得圖徵容易整合,以及相互比較。

(2) GML所提供的核心綱目(core schemas),是一般性地理空間資料的描述方式,其中GML 3.1.1已增加至29個核心綱目,可滿足目前大部份地理空間資訊的編碼需求,因此藉由擴展與限制核心綱目,不但可充份表達多樣性地理空間資料,亦可使這些編碼遵循於同一標準。

(3)GML基於XML的標準,而在網路世界中對於結構化文件和資料,XML是一個通用的格式,XML是容易轉換的,除了可使用XSLT轉換外,幾乎其它的程式語言皆可轉換XML,因此依附在一個開放、非私有的標準,GML文件具有與XML同樣的彈性,可被運用、轉換和呈現。此外,現存的相關XML技術也同樣地可以應用在GML上,如XQuery和XPath的技術。

(4)GML相同於XML,提供XLink的機制,可連結不同分散的來源在一個複雜的關連(association),相同於,HTML被使用來連結網頁的重要地位,GML則被發展來連結地理網絡中地理空間圖徵集合,透過XLink可以將不同圖徵和圖徵集合之間作可跨文件的串連,因此XLink允許我們可以建構出複雜且分散的地理資料集,使我們可在不同部門間、縣市政府間,甚至國家間緊密地的整合資料及存取資料。

(5)GML文件可透過WFS在網路中相互傳輸資料,而透過其它的OGC所提供的標準網路地理資料服務,如WMS和WCS的建立與整合,不同格式的地理空間資料庫藉由GML格式以相互交換資料。

(6)GML資料完全以文字型態儲存,文字格式不被任何一個軟體可限定的,不同於現今許多地理空間資料格式是以二元制(binary)格式,使人無法閱讀,甚至解析。也因為GML是文字格式,它可以輕易的整合不同來源的非空間型態資料,如文字、一般圖形、動畫、聲音…等,這提高了地理空間資料的價值和親近性。

延伸閱讀:
2005年,國土資訊系統通訊,以地理標記語言建立異質地理資料之共享機制─以台北市政府為例
2005, GML Days, Vancouver, British Columbia, Canada, July 18th – 22thExperience in Building GML-based Interoperable Geo-spatial Systems
2006, Map Asia, Bangkok, Thailand, August 29th – September 1st Working with GML for Internet GIS: User Perspective and Experience

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

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

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

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

回應:國土資訊系統的標準

在這裡要非常感謝Ilya的抽空到開放式地理資訊系統研討會來,並記錄且給了一些commands, 身為研討會的host也來回應一下。

早年在執行政府部門計劃時,如環保署和水保局,總是遇到向各政府單位索取地理空間資料的碰壁或資料不全,甚至沒有這項地理資料之事,即使拿到資料後更是得花功夫將資料整理到「可用的狀態」,而每次資料的重整,不但得了解資料內容,還得整合成同一種資料格式,才能進行下一階段的資料分析或決策。當時對國土資訊系統的九大資料庫,為何是如此難用、難取得資料,心中是充滿了疑惑。當然我和Alice一樣,在我還沒開始Open GIS 的研究之前,我也是不相信國土資訊系統會有標準嗎?

然而,1994年,一群原屬於Open Source GIS社群的人(GRASS的玩家),體認到open source GIS不足以解決地理空間資料歧異所造成的問題,因此組成Open GIS Consortium(OGC),2004年改為Open Geospatial Consortium(OGC),這個非營利組織,強調制定商業中立的地理空間資訊相關之技術規範(Specifications),使GIS開發者可透過這些specs,開發出可透明地在網路中存取地理空間資料的元件,而使地理資料傳輸、交換沒有障礙,而這些技術規範事實上所根據的是ISO 19000系列的地理空間資訊標準,所以地理空間資訊的標準早己在國際間成為重要課題,只是對於這方面國內涉獵不足,加上這些技術需要一定程度的IT背景,使得國內在這方面的推行未見成效。

事實上,多年前內政部為統一國內地理資料曾推行過SEF(Standard Exchange Format),現在看來與Simple File Feature Profile有點像,但我相信,知道SEF的人不多,使用也很少,問題來自於沒有相關操作的工具,現今以商業GIS當道的環境,使SEF法生存。那這些國際標是否也會有一樣的問題呢?OGC所公佈的Specs是工業標準,地位猶如W3C,許多商業GIS、Open Source GIS都遵從這些標準,讓使用者可以轉成符合國際標準的地理資料格式,也可以國際標準的方式,將地理資料於網路中散佈。因此技術與工商業整合是沒有問題,但應用到政府呢?

我們先來看看別人如何做。美國聯邦地理資料委員會(Federal Geographical Data Comittee, FGDC)是美國政府對整合地理資料和發佈地理資料標準最高核心機構,在FGDC的NSDI(National Spatial Data Infrastructure)中,不但有詳細的策略目標,也將如何執行運作的方法與進程清楚的記載,使得美國各政府 部門在生產與發佈地理資料時可以依據這個國家標準,最明顯的案例是美國環保署(US EPA)和人口調查局(US Census)將所轄之地理資料都依FGDC之標準作與發佈,使得後續使用者在使用這些資料時,不用考慮整合問題,而透過data server就可以request使用者所需的資料。那台灣呢?

內政部資訊中心國土資訊系統推動小組(現今改為經建會國土資訊系統推動小組),從2002年開始對ISO的地理資料標準和地理資料標準的建立做一系列的研究報告,對於標準制度建立的過程和標準審議的制度,透過國外標準制度的調查,也建立了一套遊戲規則,但copy國外的標準到台灣,是否可以落實呢?我是存疑的。

我個人認為台灣地理資訊標準要成功最主要的問題在於「人」。地理資訊標準對於早期學地理資訊系統的人是相當陌生的,如今這些標準技術又包含許多IT的技術,要有一定的門檻,因此人才的訓練和培育是否建全,是一個重要的因素。再者,地理資料大部份由政府部門生產,這種從上到下的地理資訊標準規範,如何讓政府生產地理資料單位的人從下到上的遵從,恐怕得有更強而有力的法令和政策來迫使他們。此外,軟體環境是也是一個問題。我個人認為現今台灣地理資訊系統的環境過度依賴商業GIS軟體,以致於商業GIS軟體的內部運作幾乎是一個黑箱,使得處理地理資訊的技術趨於檔案開啟和關閉,形同自廢武功。

我依然衷心期盼國土資訊系統標準能成功運作,而致使NSDI能建立起來,使地理資料成為重要的infrastructure。