GeoCyber

相互操作性(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)。

同時，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系統個體間之資訊交換，而且未來能夠與其他系統如統計分析、影像處理、文件檔案管理、視覺化交換資訊。
Share on Facebook

Share on Facebook

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(執行)時，不會被其他使用者存取並修改。

Share on Facebook

Share on Facebook

Australia – AUS-SDTS
Austria – A2260
Canada – SAIF (Spatial Archive and Interchange Format)
China DEFS*
EU – CEN/TC278 GDF
EU – CERCO ETDB
Finland – JHS 111-119
France – EDIGeO (Échanges de Données Informatisés dans le domaine de l’Information géographique)
Germany – ALK/ATKIS-EDBS
IHO S-57
Israel – IEF ‘91
Japan – JSGI 2.0 (Japanese Standards for Geographic Information)
NATO – DGIWG DIGEST
Netherlands – NEN 1878
Norway – SOSI
Russian Fed – [...]

Share on Facebook

目前成大洪榮宏老師幫內政部制定一系列關於國土資訊系統的標準制度，包括「資料標準共同規範」、「詮釋資料標準」、「行政界線標準」、「地籍資料標準」、還有本次的「高程資料標準」。
就Open GIS的理念而言，資料標準是為了資料流通，但OGC制定的GML雖然有豐富的地理語彙可使用於地理資料的標示，但因GML Schema或者說XML Schema較為彈性架構，使得同樣的資料有可些有不同的地理資料模型產生，在這裡的case，是這麼多的資料標準下，若有一個共同的資料標準模型，有助於程式開發的人有一個設計的準則，也使得後續處理元件開發才能環環相扣，所以看到這一系列的標準，心中的疑問是這些標準的有無共通模型，而這個模型是一個更高等級，或是說更抽象等級的資料模型，用來限定這些資料標在一定的範圍與邏輯思考，然而，答案是否定的。「資料標準共同規範」看起來只規定限用ISO的標準和XML技術，另一方面，各個分項資料之間交由各個權責單位來負責，也無相互的溝通機制，當然使用GML已經是共同標準，但後續可能要為了處理不同層次的GML文件，所花的efforts恐怕也不少，這是一個還沒發生的問題，可是未來可能發生。
這個專家會議果然來的都是高程資料的專家，但是專家似乎對於資料模型(Data Model)不是很了解，針對的都是資料的專業知識，至於application schema應該長的如何，好像沒有人有太多的想法，反而把焦點放在資料的生產過程和資料的轉換問題。但interoperability的重點應該把焦點放在application schema是否能夠充份解釋data model，以致於資料交換上不產生落差，資料生產的精度和方法，以致於資料轉換的問題，事實上不是這裡的重點，這部份都放在metadata來解決就好了!!所以主要的問題還是在於認知的問題，資料交換的議題是在於某一單位所釋放出來的資料是否能被其它單位無隔閡、無障礙地讀取或使用，資料精度是資料品質的問題，資料模型才是資料交換過程中決定交換的關鍵。
Share on Facebook

Share on Facebook

在這裡要非常感謝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國外的標準到台灣，是否可以落實呢?我是存疑的。
[...]

Share on Facebook