在對(duì)空間信息的支持上，由于它缺乏對(duì)幾何體的存儲(chǔ)， MSSQL 總是比別的數(shù)據(jù)庫(kù)慢了一拍。在新的 .NET CLR 的支持下，你可以真正地添加你自己的基于 .NET 的對(duì)象。盡管我也試了下在 SQL Server 中實(shí)現(xiàn)簡(jiǎn)單幾何類型的存儲(chǔ)，但有一些限制使我不得不放棄了嘗試。首先，用戶數(shù)據(jù)類型不能超過 8000 字節(jié)。也就是說，幾何體對(duì)象不能超過 500 個(gè)節(jié)點(diǎn)，這對(duì)像海岸線這樣的對(duì)象就顯得太少了。另一個(gè)問題是 SQL Server 不支持繼承，所以你也不能對(duì)你的數(shù)據(jù)類型做比較好的面向?qū)ο髮?shí)現(xiàn)。

　　所以試著找到了一個(gè)完全不同的更簡(jiǎn)單的實(shí)現(xiàn)。以 Well-Known Binary 的形式（譯者注： OpenGIS 的說明書中定義了兩個(gè)表述空間對(duì)象的標(biāo)準(zhǔn)方式：一個(gè)是 WKT （ the Well-Known Text ）形式，另一個(gè)是 WKB （ the Well-Known Binary ）形式）存儲(chǔ)幾何體在一個(gè)圖像列中。使用圖像列的目的是它能夠保存大到 2G 的數(shù)據(jù)，這對(duì)大多數(shù)的幾何對(duì)象都足夠了。而字節(jié)列和用戶自定義類型一樣，也有 8000 個(gè)字節(jié)的限制，所以也不夠好。除了幾何列之外，我還創(chuàng)建了四個(gè)實(shí)數(shù)類型的列，用來存儲(chǔ)幾何外接矩形框的最大最小坐標(biāo)值。這能提高基于外接矩形框的查詢的效率。其它的列用來存儲(chǔ)幾何體的屬性。

　　在 SharpMap 中實(shí)現(xiàn)了這個(gè)方法。首先，建立了一個(gè)小的數(shù)據(jù)庫(kù)導(dǎo)入程序用來導(dǎo)入 shapefile 文件。它在數(shù)據(jù)庫(kù)中建立一個(gè)表，然后把幾何體及其對(duì)象導(dǎo)入其中。 SharpMap 為其提供了必要的數(shù)據(jù)讀取器和 WKB 格式化程序。第二個(gè)部分是建立了一個(gè)數(shù)據(jù)提供接口， SharpMap 能夠基于這個(gè)接口繪制數(shù)據(jù)。我做這些時(shí)多少參照了 PostGreSQL/PostGIS 的數(shù)據(jù)提供接口，只是用四個(gè)外框坐標(biāo)列來做外接矩形框查詢。所有這些工作所發(fā)費(fèi)的時(shí)間不超過一個(gè)小時(shí)，因此，可以說做起來是比較簡(jiǎn)單的。

　　對(duì)于這種方法的效率我是很驚訝的。它比 shapefile 的數(shù)據(jù)接口還快一點(diǎn)點(diǎn)，而 shapefile 數(shù)據(jù)接口曾經(jīng)是 SharpMap 中最快的數(shù)據(jù)接口。而 PostGreSQL/PostGIS 相比而言要慢 4 － 6 倍。

【 頂部 】 【 關(guān)閉 】