值此FOSS4G大會即將召開之日，最近我會在Blog上依次介紹一些OpenGIS標準、架構及用于實現(xiàn)的軟件。一方面給初涉此行的朋友一個快速入門的概覽，另一方面也是對我接觸OpenGIS近一年來的總結(jié)。
OpenGIS定義了一組基于數(shù)據(jù)的服務，而數(shù)據(jù)的基礎是要素（Feature）。所謂要素簡單地說就是一個獨立的對象，在地圖中可能表現(xiàn)為一個多邊形建筑物，在數(shù)據(jù)庫中即一個獨立的條目。要素具有兩個必要的組成部分，幾何信息和屬性信息。OpenGIS將幾何信息分為點、邊緣、面和幾何集合四種：其中我們熟悉的線（Linestring）屬于邊緣的一個子類，而多邊形（Polygon）是面的一個子類。也就是說OpenGIS定義的幾何類型并不僅僅是我們常見的點、線、多邊形三種，它提供了更復雜更詳細的定義，增強了未來的可擴展性。另外，幾何類型的設計中采用了組合模式（Composite），將幾何集合（GeometryCollection）也定義為一種幾何類型，類似地，要素集合（FeatureCollection）也是一種要素。屬性信息沒有做太大的限制，可以在實際應用中結(jié)合具體的實現(xiàn)進行設置。
相同的幾何類型、屬性類型的組合成為要素類型（FeatureType），要素類型相同的要素可以被存放在一個數(shù)據(jù)源中。而一個數(shù)據(jù)源只能擁有一個要素類型。因此，可以用要素類型來描述一組屬性相似的要素。在面向?qū)ο蟮哪Ｐ椭校耆梢园岩仡愋屠斫鉃橐粋€類，而要素則是類的實例。
通過GIS中間件可以從數(shù)據(jù)源中取出數(shù)據(jù)，供WMS服務器和WFS服務器使用。
WMS服務器接收請求，根據(jù)請求內(nèi)容的不同，可以返回不同格式的最終數(shù)據(jù)。例如，WMS可以返回常用圖片格式的地圖片段供最終用戶閱讀（類似Google Maps），其中地圖是根據(jù)一個樣式文件（SLD）生成的，它描述了地圖的線劃粗細，色彩等；WMS也可以返回GeoRSS和KML用來和其它地圖服務互通。
WFS服務器也可以接收請求，但WFS將返回GML格式的地理信息數(shù)據(jù)。GML是一種基于XML的數(shù)據(jù)格式，它可以完整的再現(xiàn)數(shù)據(jù)，也是OpenGIS數(shù)據(jù)源的重要形式。也就是說，WFS返回的GML可以繼續(xù)作為數(shù)據(jù)源。在WFS請求中，OpenGIS定義了一個Filter標準，用來實現(xiàn)對數(shù)據(jù)的篩選，使WFS更加靈活。另一方面，WFS還支持通過WFS-t提交客戶端對數(shù)據(jù)的修改。通俗地說，WMS是“只讀”的，而WFS則是可以讀寫的。
草草說完，發(fā)現(xiàn)自己的理解也十分有限，如有謬誤，還望讀者不吝指正。另外還有WCS方面不曾涉及，要獲得更進一步的了解，請下載OpenGIS的標準進行閱讀。
今天來說OpenGIS架構的軟件、類庫實現(xiàn)情況。OpenGIS是一個開放標準，不過它已經(jīng)不僅僅在開源世界發(fā)揮作用，許多商業(yè)軟件也支持了OpenGIS的標準。當然，這里所提到的軟件全部都是開源軟件。
幾何基礎類庫代表： JTS（Java）， GEOS（C++）， Shapely（Python）
這類幾何基礎類庫主要實現(xiàn)的是OpenGIS的Simple Feature Access標準，簡單地說他們就是對幾何類型（Geometry）進行了一定程度的封裝。以JTS為例，它按照OpenGIS對于Geometry的描述實現(xiàn)了基于Java的接口和繼承關系，制作好了可以使用的類似Point、LineString這樣的類。另外這些類庫還普遍實現(xiàn)了OpenGIS的DE-9IM空間位置關系判斷和一些常用的計算幾何方法（如緩沖（buffer））。
此類軟件是所有GIS類庫的基礎，正如幾何是GIS的基礎之一一樣。
數(shù)據(jù)源實現(xiàn)代表：PostGIS（PostgreSQL），MySQL Spatial
數(shù)據(jù)源的實現(xiàn)主要是開源數(shù)據(jù)庫的空間擴展。數(shù)據(jù)庫的空間擴展不僅僅在數(shù)據(jù)表中支持幾何類型的存儲，而且更提供了SQL級別的集合關系判斷，例如，可以直接利用SQL查詢在某個多邊形內(nèi)的點。
中間件代表：GeoTools（Java）
中間件在系統(tǒng)中扮演連接數(shù)據(jù)和服務的角色。GeoTools承擔了從各種數(shù)據(jù)源（如PostGIS，GML，Shapefile，WFS）讀取數(shù)據(jù)并將數(shù)據(jù)標準化的工作。Feature接口就定義在GeoTools中，不同數(shù)據(jù)源的數(shù)據(jù)讀出后被統(tǒng)一成包含一個Geometry成員（定義在JTS中）的Feature接口的實現(xiàn)。這樣，進一步的操作只需面向Feature即可，省去了高層軟件對于不同數(shù)據(jù)源的解讀過程。另外，GeoTools還是OpenGIS標準的全面實現(xiàn)，其中包括Filter、坐標轉(zhuǎn)換、GML。
WMS/WFS服務器代表： GeoServer（Java），MapServer（PHP）
地圖服務器扮演向網(wǎng)絡中的客戶端提供地圖服務的角色。這類地圖服務器可以接收統(tǒng)一規(guī)范的WMS和WFS請求（request），返回多種格式的數(shù)據(jù)。這個過程有WMS/WFS規(guī)范的嚴格規(guī)定，所以，對客戶端來說其地圖服務器的實現(xiàn)究竟是什么并不會造成太大影響。這樣的規(guī)范，為公共的、聯(lián)合的地圖服務創(chuàng)造了可能。
客戶端代表：OpenLayers/MapBuilder（JavaScript），uDig（Java），QGIS（C++）
客戶端分為瀏覽器和桌面客戶端程序兩種。以OpenLayers為代表的B/S系統(tǒng)客戶端現(xiàn)在已經(jīng)非常強大，它可以封裝WMS請求，在瀏覽器上實現(xiàn)地圖的切片載入功能。另外拖動、縮放都功能也非常完善，可以實現(xiàn)跨瀏覽器操作。最近的OpenLayers版本還支持了矢量編輯功能，可以通過WFS-t提交。而傳統(tǒng)的桌面客戶端程序功能則更加強大，支持多種包括WMS和WFS在內(nèi)的數(shù)據(jù)源，另外編輯功能、操作性也要比瀏覽器中的強大。
Shapefile
ESRI的Shapefile格式是GIS矢量文件格式的事實標準，通常由.shp, .shx, .prj, .dbf等文件組成。OpenGIS的實現(xiàn)軟件普遍支持Shapefile的讀寫。Shapefile在GeoServer中可以直接作為數(shù)據(jù)源，但是這種方式并不被推薦，原因很簡單，基于文件的數(shù)據(jù)源可能造成性能不佳和數(shù)據(jù)丟失。
GMLGML是OpenGIS的標準規(guī)范之一，它基于xml描述地理數(shù)據(jù)。于Shapefile相比，xml更容易讀寫，易于在網(wǎng)絡中以各種形式傳播。同時，xml還具有可讀性，人可以理解和辨識。GeoTools實現(xiàn)了GMLDataStore，因此在GeoServer中GML也可以直接作為數(shù)據(jù)源（需要下載GML擴展）。同時，GML的數(shù)據(jù)源為數(shù)據(jù)源動態(tài)化提供了實現(xiàn)的思路和可能性。
PostGISPostGIS是加拿大Refractions公司支持的開源項目，它為開源數(shù)據(jù)庫PostgreSQL提供了空間支持。PostGIS安裝后，PostgreSQL中出現(xiàn)一個模版數(shù)據(jù)庫，新建空間數(shù)據(jù)庫時只需以PostGIS為模版即可。PostGIS在SQL級別上實現(xiàn)了基本的空間運算功能。另外絕大多數(shù)開源GIS軟件（即使是不嚴格遵守OpenGIS標準的）都支持PostGIS數(shù)據(jù)表的直接載入，讀寫等功能。毋庸置疑，PostGIS是OpenGIS數(shù)據(jù)源最佳實現(xiàn)。
MySQL SpatialMySQL是開源數(shù)據(jù)庫的大鱷，從MySQL4.0開始加入了Spatial擴展功能，實現(xiàn)了OpenGIS規(guī)定的幾何數(shù)據(jù)類型，在SQL中的簡單空間運算。但是從4.0之后到現(xiàn)在，MySQL的Spatial部分一直沒有繼續(xù)的更新和增強。加上早先MySQL在SQL上對空間運算支持的不完善（只支持基于最小外接矩形的關系判斷），所以MySQL是開源數(shù)據(jù)源中一個不太讓人滿意的選擇。不過由于MySQL在小型項目上的廣泛引用，在一些情況下也是可以以MySQL為數(shù)據(jù)源的。
db4o?： 對象數(shù)據(jù)庫作為數(shù)據(jù)源的可能性OpenGIS的系統(tǒng)架構完全是基于一個面向?qū)ο蟮哪Ｐ偷模鴤鹘y(tǒng)的關系數(shù)據(jù)庫、Shapefile文件是現(xiàn)在應用的主流。在地理描述的過程中，關系數(shù)據(jù)庫的特性并沒有被完全發(fā)揮，而為此還需要有中間件做ORM的工作。試想直接將FeatureType和Features以對象形式存入對象數(shù)據(jù)庫，整個系統(tǒng)至少在理論上可以減少一層。不過，以對象數(shù)據(jù)庫作為數(shù)據(jù)源，還需要對象數(shù)據(jù)庫的性能進一步提升。而之后的和已有軟件的對接應該不成問題，因為db4o可以直接存儲Feature對象和Geometry對象。
但是因此產(chǎn)生的數(shù)據(jù)對實現(xiàn)的依賴性又是一個問題：數(shù)據(jù)和實現(xiàn)緊密耦合，數(shù)據(jù)中捆綁了代碼，雖然db4o號稱支持Java和.NET的的互操作，但是對于其它實現(xiàn)來說又成了問題。從這個角度來說，對象數(shù)據(jù)庫作為數(shù)據(jù)源是一種倒退。
為什么沒有KML？KML作為一種新的標準（沒有在意最后是否通過），它的作用主要是網(wǎng)絡中地理信息的傳輸。KML是一種面向客戶端設計的數(shù)據(jù)形式，這是它不能取代GML地位的原因，同時也是它在GoogleEarth和很多地圖應用上遠強于GML的原因。對照一下KML和GML的形式就很容易理解，GML將屬性數(shù)據(jù)存儲為Element，而KML則是以超文本的形式存儲屬性數(shù)據(jù)，前者便于數(shù)據(jù)讀取，后者便于客戶端表現(xiàn)。于KML很類似的就是GeoRSS，效果是相似的。