PostGIS開啟開源空間資料庫的未來(1)

1986年，加州大學伯克利分校的Michael Stonebraker教授領導了Postgres的專案，它是PostgreSQL的前身。隨後出現了PostGIS，PostGIS是物件－關係型數 據庫系統PostgreSQL的一個擴充套件，它的出現讓人們開始重視基於資料庫管理系統的空間擴充套件方式，而且使PostGIS有望成為今後管理空間資料的主流技術。

由於空間資料具有空間位置、非結構化、空間關係、分類編碼、海量資料等特徵，一般的商用資料庫管理系統難以滿足要求。

為了提高資料庫管理系統（DBMS）對空間資料的管理能力，國內外先後出現過：檔案與關係資料庫混合管理系統、全關係型空間資料庫管理系統、關係型 資料庫＋空間資料引擎、擴充套件物件關係型資料庫管理系統，以及面向物件空間資料庫管理系統等多種解決方案。目前，國內外較為流行的主要集中在“關係型資料庫＋空間資料引擎”

“關係型資料庫＋空間資料引擎”通常是近年來由GIS廠商研發的一種中介軟體解決方案。使用者將自己的空間資料交給獨立與資料庫之外的空間資料引擎，有空間資料引擎來組織空間資料在關係型資料庫種的儲存；當用戶需要訪問資料的時候，再通知空間資料引擎，有引擎從關係型資料庫中取出資料，並轉化為客戶可以使用的方式。

因此，關係型資料庫僅僅是存放空間資料的容器，而空間資料引擎則是空間資料進出該容器的轉換通道。這類系統的典型代表有ESRI的ArcSDE和 MapInfo的SpatialWare。其優點是，訪問速度快，支援通用的關係資料庫管理系統，空間資料按BLOB存取，可跨資料庫平臺，與特定GIS 平臺結合緊密，應用靈活。其缺點主要表現為，空間操作和處理無法在資料庫核心中實現，資料模型較為複雜，擴充套件SQL比較困難，不易實現資料共享與互操作。

擴充套件物件關係型資料庫管理系統是由資料庫廠商研發的管理空間資料一種解決方案。由於關係型資料庫難以管理非結構化資料（也包括空間資料），資料庫廠商借鑑面向物件技術，發展了物件關係型資料庫管理系統。

此係統支援抽象的資料型別（ADT）及其相關操作的定義；使用者利用這種能力可以增加空間資料型別及相關函式，從而將空間資料型別與函式就從中介軟體 （空間資料引擎）轉移到了資料庫管理系統中，客戶也不必採用空間資料引擎的專用介面進行程式設計，而是使用增加了的空間資料型別和函式的標準擴充套件型SQL語言 來操作空間資料。

這類支援空間擴充套件的產品有Oracle的Oracle Spatial， IBM的DB2 Spatial Extender， Informix 的Spatial DataBlade。其優點是，空間資料的管理與通用資料庫系統融為一體，空間資料按物件存取，可在資料庫核心中實現空間操作和處理，擴充套件SQL比較方 便，較易實現資料共享與互操作。其缺點主要表現為，實現難度大，壓縮資料比較困難，目前的功能和效能與第一類系統尚存在差距。

目前開源空間資訊軟體領域最效能優秀的資料庫軟體當屬PostgreSQL資料庫，而構建在其上的空間物件擴充套件模組PostGIS則使得其成為一個真正的大型空間資料庫。

緣起PostgrSQL

1986年，加州大學伯克利分校的Michael Stonebraker教授領導了Postgres的專案，它是PostgreSQL的前身。這個專案的成果非常顯著，在現代資料庫的許多方面都作出了大 量的貢獻，如在面向物件的資料庫、部分索引技術、規則、過程和資料庫擴充套件方面都取得了顯著的成果。同時，Stonebraker將PostgreSQL納 入到BSD版權體系中，使得PostgreSQL在各種科研機構和一些公共服務組織得到了廣泛的應用。

在PostgreSQL中已經定義了一些基本的集合實體型別，這些型別包括：點（POINT）、線（LINE）、線段（LSEG）、方形 （BOX）、多邊形（POLYGON）和圓（CIRCLE）等；另外，PostgreSQL定義了一系列的函式和操作符來實現幾何型別的操作和運算；同 時，PostgreSQL引入空間資料索引R-tree。

儘管在PostgreSQL提供了上述幾項支援空間資料的特性，但其提供的空間特性很難達到GIS的要求，主要表現在：缺乏複雜的空間型別；沒有提供空間分析；沒有提供投影變換功能。為了使得PostgreSQL更好的提供空間資訊服務，PostGIS應運而生。

PostGIS簡介

PostGIS是物件關係型資料庫系統PostgreSQL的一個擴充套件，PostGIS提供如下空間資訊服務功能：空間物件、空間索引、空間操作函式和空間操作符。同時，PostGIS遵循OpenGIS的規範。

PostGIS的版權被納入到GNU的GPL中，也就是說任何人可以自由得到PostGIS的原始碼並對其做研究和改進。正是由於這一點，PostGIS得到了迅速的發展，越來越多的愛好者和研究機構參與到PostGIS的應用開發和完善當中。

PostGIS發展歷程

PostGIS是由Refractions Research Inc開發的，Refractions是一家GIS和資料庫諮詢公司，Refraction公司最初是在PostgreSQL的基礎上研究空間資料庫的實 現，由於PostgreSQL所提供的空間資料型別和功能遠遠不能滿足GIS的需求，研究工作經常陷入到進退維谷的境地，最終的結果往往是耗費了大量的人 力物力，而產品卻極其複雜並且效能低下。這些原因直接或間接促成PostGIS專案的實施。

PostGIS的實施也不是一帆風順，直到PostgreSQL 7.1釋出之後，PostGIS的實現才變為可能，主要原因是7.1版本之前PostgreSQL支援的記錄大小最大為8Kb，從7.1之 後，PostgreSQL將這一限制擯棄。即使採用二進位制方式儲存，空間資料物件也往往會經常超過8Kb，如果這個限制存在的話，空間資料的儲存就無從談 起。

伴隨著這一限制的消除，PostGIS的研究和開發也隨即在2001年的4月展開，並於2001年的5月釋出了PostGIS的第一版 （PostGIS V0.1）。在PostGIS的第一版中，主要包括空間資料庫、採用標準表示方式的空間資料物件、支援快速查詢的空間索引和一些簡單的分析函式（如 area和length等）。PostGIS V0.1中支援的空間資料物件型別包括：點、線、多邊形、幾何物件型別，以及多點、多線、多多邊形的幾何物件型別。

2001年5月釋出的PostGIS V0.2增加了對於Windows平臺下二進位制表示的支援，同時為新使用者提供幫助文件。不過，使用者反饋PostGIS的函式命名沒有遵循OpenGIS規範。

2001年7月PostGIS V0.5釋出，PostGIS增加了OpenGIS現有的所有功能性函式並在函式的命名上與其保持一致。增加了24個OpenGIS存取函式，同時刪除了與這些函式功能等價的不標準的原有函式。

伴隨著來自不列顛哥倫比亞省政府的資金支援，對於在球體表面的長度運算支援也加入到0.5版中。同期，Refractions公司將British Columbia省的數字道路地圖集移植到PostGIS中，同時使用資料庫的模式和資料轉換功能為地圖集客戶提供支援（急救車派遣、緊急事物響應，以及 其他市政事物等）。

PostGIS V0.5之所以重要，還有一個原因就是Minnesota大學的Mapserver的釋出。Minnesota大學的Mapserver是一個開源的互聯 網地圖釋出引擎，就像ESRI公司的ArcIMS系統，Mapserver同時增加了對於PostGIS的支援。

• PostGIS開啟開源空間資料庫的未來(2)

在Mapserver中，提供了一個Web驅動的介面，這個介面用於檢查資料庫中資料的空間特徵。在PostGIS中，PostGIS為了使得 Mapserver能夠更好的提供服務，提供了一個易於讀寫的資料來源，這個資料來源將會在網路事務繁忙的時候發揮其效用。比如，如果用標準的GIS檔案作為 資料來源，如果有兩個使用者併發的對同一檔案進行寫入操作，這樣將會不可避免的導致操作衝突，而利用PostGIS就能夠很好的解決這個缺陷，同時確保資料的 完整性。

2001年9月，PostGIS V0.6釋出，PostGIS V0.6提供了完整的OpenGIS支援，加入了標準的元資料表，並且提供了對於空間參照系統標識的支援。另外還加入了OpenGIS支援的12個功能函 數，同時對於Mapserver的支援得到了進一步的增強。

2002年2月，PostgreSQL V7.2釋出，在7.2版中，GIST索引的API函式作了一點改進。由於這些API函式同樣應用於PostGIS中，這給PostGIS V0.6的應用帶來了麻煩，促使PostGIS必須作出改進適應PostgreSQL的變化。2002年PostGIS V0.7釋出，在0.7版中，提供了新的對於GIST的API函式支援，同時在這一版中，提供了對於座標變換的支援。

從2002年到現在，PostGIS又陸續釋出了一系列的新版本，這些PostGIS產品在繼承PostGIS產品原有優點的同時，又針對 PostGIS本身存在的問題和不足進行了進一步的改進。到現在為止，PostGIS的最新版本是PostGIS V1.1.4。PostGIS V1.1.4主要改進的地方包括：⑴提供了對於將要釋出的PostgreSQL V8.2的支援；⑵修復了函式collect中存在的bug；⑶在MakeBox2d和MakeBox3d中增加了對SRID的匹配檢查；⑷提高了 pgsql2shp的執行併發性；⑸進一步改進了對於Java的支援。

PostGIS特性

PostGIS支援所有的空間資料型別，這些型別包括：點（POINT）、線（LINESTRING）、多邊形（POLYGON）、多點 （MULTIPOINT）、多線（MULTILINESTRING）、多多邊形（MULTIPOLYGON）和集合物件集 （GEOMETRYCOLLECTION）等。PostGIS支援所有的物件表達方法，比如WKT和WKB。

PostGIS支援所有的資料存取和構造方法，如GeomFromText()、AsBinary()，以及GeometryN()等。

PostGIS提供簡單的空間分析函式（如Area和Length）同時也提供其他一些具有複雜分析功能的函式，比如Distance。

PostGIS提供了對於元資料的支援，如GEOMETRY_COLUMNS和SPATIAL_REF_SYS，同時，PostGIS也提供了相應的支援函式，如AddGeometryColumn和DropGeometryColumn。

PostGIS提供了一系列的二元謂詞（如Contains、Within、Overlaps和Touches）用於檢測空間物件之間的空間關係，同時返回布林值來表徵物件之間符合這個關係。

PostGIS提供了空間操作符（如Union和Difference）用於空間資料操作。比如，Union操作符融合多邊形之間的邊界。兩個交迭的多邊形通過Union運算就會形成一個新的多邊形，這個新的多邊形的邊界為兩個多邊形中最大邊界。

PostGIS還提供以下功能：

資料庫座標變換

資料庫中的幾何型別可以通過Transform函式從一種投影系變換到另一種投影系中。在OpenGIS中的幾何型別都將SRID作為自身結構的一部分，但不知什麼原因，在OpenGIS的SFSQL規範中，並沒有引入Transform。

球體長度運算

儲存在普通地理座標系中的集合型別如果不進行座標變換是無法進行程度運算的，OpenGIS所提供的座標變換使得積累型別的程度計算變成可能。

三維的幾何型別

SFSQL規範只是針對二維集合型別。OpenGIS提供了對三維集合型別的支援，具體是利用輸入的集合型別維數來決定輸出的表現方式。例如，即便 所有幾何物件內部都以三維形式儲存，純粹的二維交叉點通常還是以二維的形式返回。此外，還提供幾何物件在不同維度間轉換的功能。

空間聚集函式

在資料庫中，聚集函式是一個執行某一屬性列所有資料操作的函式。比如Sum和Average，Sum是求某一關係屬性列的資料總和，Average 則是求取某一關係屬性列的資料平均值。與此對應，空間聚集函式也是執行相同的操作，不過操作的物件是空間資料。例如聚集函式Extent返回一系列要素中 的最大的包裹矩形框，如“SELECT EXTENT(GEOM) FROM ROADS”這條SQL語句的執行結果是返回ROADS這個資料表中所有的包裹矩形框。

柵格資料型別

PostGIS通過一種新的資料型別片，提供對於大的柵格資料物件的儲存。片由以下幾個部分組成：包裹矩形框、SRID、型別和一個位元組序列。通過 將片的大小控制在資料庫頁值（32×32）以下，使得快速的隨即訪問變成可能。一般大的圖片也是通過將其切成32×32畫素的片然後再儲存在資料庫中的。

PostGIS發展展望

目前，由於“關係型資料庫＋空間資料引擎”的技術方案訪問迅速、與GIS聯絡緊密的優點，在應用中佔有一定的優勢，但空間資料引擎獨立於資料庫內 核，難以充分利用關係型資料庫中各種成熟的資料管理、訪問技術，成為進一步發展的致命弱點。另外，難以支援擴充套件SQL，不易實現資料共享與互操作等問題也 逐漸暴露出來。

儘管面向物件空間資料庫管理系統最適應於空間資料的表達和管理，不僅支援變長記錄，而且支援物件的巢狀、資訊的繼承與聚集。有關面向物件資料庫管理 系統的研究已有十多年了，由於缺乏良好的資料基礎，在訪問速度尚未有重大突破，難以發展成熟，據估計在較長一段時間內面向物件資料庫管理系統都不會替代對 象關係型資料庫管理系統。

擴充套件物件關係型資料庫管理系統無疑將成為以後的發展方向。儘管目前PostGIS/PostgreSQL和Spatial Oracle的效能與ArcSDE仍有一定的差距，但是隨著資料庫廠商對空間資料管理市場的不斷重視、結構化資料管理方式與空間資料管理方式的進一步融 合、資料壓縮傳輸技術的不斷提高，基於資料庫管理系統的空間擴充套件方式將會不斷的完善，成為今後管理空間資料的主流技術。而多數GIS廠商則應將精力集中到 空間分析、空間模型等方面，從而形成較好的社會分工結構。

目前，軟體開源已經成為IT界的一種發展趨勢，越來越多的軟體加入到開源系統中。PostGIS不論在功能還是擴充套件性方面都不落後於商業GIS平臺 的空間資料庫，而且由於其原始碼的公開性，更加容易吸引廣大愛好者參與到PostGIS的開發中，不斷完善現有的功能同時進一步擴充套件新的特性，相信 PostGIS的發展前景將會非常美好。