|
原創(chuàng) freegiser Spatial Data 2021-03-29 22:25 收錄于合集 #GIS17 #WebGIS19 #PostGIS13 #矢量切片2 一 背景 但凡是有GIS背景的系統(tǒng)開發(fā)，數(shù)據(jù)處理工程師，都不會對shp格式文件感到陌生，可以說，shp格式簡直就是所有g(shù)is軟件的“最大公約數(shù)”，無論你是在用ArcMap還是用QGIS，是用postgis還是oracle spatial，是用geoserver還是mapserver，幾乎所有g(shù)is軟件或中間件都原生支持shp，堪稱“業(yè)界寵兒”。但沒有任何格式是完美的，shp有好的一面，但也有壞的一面，不區(qū)分場景的濫用會導(dǎo)致其壞的一面放大。目前，在企業(yè)級WebGIS場景下也有大量業(yè)務(wù)系統(tǒng)存在過度使用shp的問題，本文就該主題討論下shp為什么不適合在企業(yè)級WebGIS中使用。 二 企業(yè)級WebGIS數(shù)據(jù)需求 討論某種技術(shù)、規(guī)范、格式適不適合某種場景，是要看具體業(yè)務(wù)需求的，shp本身是種數(shù)據(jù)格式，討論其是否適合的話首先要明確業(yè)務(wù)場景，通常企業(yè)級WebGIS是典型的BS三層架構(gòu)，每層的業(yè)務(wù)需求枚舉如下圖：
三 shp對業(yè)務(wù)場景力度 3.1 存儲層 空間存儲：由于.shp文件（圖形）和.dbf文件（屬性）不能超過2G，那么等于說明shp文件存儲的空間數(shù)據(jù)<4G（實際更小），而很多空間業(yè)務(wù)數(shù)據(jù)是很大的數(shù)據(jù)量，超過3，4G的企業(yè)級數(shù)據(jù)是很常見的，因此，shp自身的限制決定了其不具備系統(tǒng)存儲層的通用性。 屬性查詢：很常用的業(yè)務(wù)要求，即根據(jù)某個字段過濾查詢，在一般關(guān)系型數(shù)據(jù)庫中，就是一行簡單的sql的問題，如果性能不行，可以加個索引優(yōu)化；而shp如果自己寫個查詢服務(wù)，肯定首先要在內(nèi)存里讀取數(shù)據(jù)，然后遍歷數(shù)據(jù)進(jìn)行過濾，要寫代碼很麻煩，如果不想自己寫代碼就用geoserver發(fā)布個地理服務(wù)，根據(jù)ogc的wfs規(guī)范去查詢，寫起來是簡單了，但是查詢性能有很大問題，且shp不能像數(shù)據(jù)庫那樣建立字段索引。這里貼幾個早年性能測試情況，數(shù)據(jù)規(guī)模約8.7萬個點，使用 name='xx鎮(zhèn)' 作為屬性查詢條件： shp屬性查詢 16s：（基于geoserver的wfs） shp導(dǎo)入postgis不建立索引 0.1s：
shp導(dǎo)入postgis對name建立索引 0.05s:
性能測試對比如下”
從開發(fā)簡潔性，還是條件查詢性能上，shp都太不夠看了，根本不具備企業(yè)級數(shù)據(jù)查詢的要求。 聯(lián)表join：shp導(dǎo)入數(shù)據(jù)庫就是普通的關(guān)系表，只不過多了個圖形字段，與其他業(yè)務(wù)表join是沒問題的，但是shp本身不能和數(shù)據(jù)庫通信，也就談不上join的能力了。印象里arcmap里的shp可以和屬性表關(guān)聯(lián)，但是和數(shù)據(jù)庫關(guān)聯(lián)沒做過不知道是否可以，就算支持性能也跟不上，而其他開源的中間件都不支持shp和表的join。 空間分析：以疊加分析為例。 shp空間分析 1s：
shp導(dǎo)入postgis空間分析 0.15s：
shp第一次查詢有點慢，第二次查詢會快很多，原因是，gis server（如geoserver）首先要把數(shù)據(jù)load到內(nèi)存里，然后根據(jù)shp元數(shù)據(jù)構(gòu)建空間索引，這個耗時較多；而第二次查詢時，server并未把數(shù)據(jù)從內(nèi)存卸載，因此就沒有這個load耗時了。由于shp是自帶空間索引的，所以第二次的查詢耗時可以理解成是真實的空間查詢耗時，這個耗時貼近postgis的空間查詢。那么可以理解成shp還是postgis都有空間索引，查詢性能幾乎一致，但是shp有個初次查詢load到內(nèi)存的io耗時，而數(shù)據(jù)庫根據(jù)空間索引查，并不用把數(shù)據(jù)全部load到內(nèi)存，所以有較小的io開銷，更好的體驗。 除此之外，shp文件里字段太長會強制截取的限制，很容易破壞數(shù)據(jù)的完整性。 此外，數(shù)據(jù)規(guī)模極端大的情況，數(shù)據(jù)庫可以擴展分布式等，shp只能定位在很小的業(yè)務(wù)場景里。 綜述：無論從任何一點看，企業(yè)級WebGIS都不可能用shp做數(shù)據(jù)存儲的。 3.2 服務(wù)層 gis服務(wù)端其實是很尷尬的存在，通常是啥也不干其實，也干不了太多，因為大量數(shù)據(jù)查詢分析是走數(shù)據(jù)庫引擎，少量數(shù)據(jù)查詢和處理前端就夠了。因此，尷尬的服務(wù)端大多數(shù)情況下，只是負(fù)責(zé)把數(shù)據(jù)庫的數(shù)據(jù)搬運給前端，那么這個搬運過程稱為數(shù)據(jù)查詢，數(shù)據(jù)查詢的話，shp的表現(xiàn)并不能滿足業(yè)務(wù)需求，見上一章節(jié)的測試。 另一方面，查詢的矢量數(shù)據(jù)結(jié)果以geojson、gml、topojson格式傳給前端是很自然的選擇，但是如果數(shù)據(jù)太大，就會形成網(wǎng)絡(luò)瓶頸，等很久才能傳輸?shù)角岸?，用戶體驗會非常糟糕。這種情況下，假設(shè)我們用postgis的話，可以使用postgis的矢量切片和并行計算等特性，快速把結(jié)果傳到前端，詳情參考早前一篇postgis可視化的文章：
如果使用shp做數(shù)據(jù)源的話，絕大部分普通的人會躺下了，已經(jīng)這樣了，還能怎么辦咧？少部分“聰明”人可能比如使用geoserver，一開始就把shp切成矢量切片，前端查詢時，只是把不符合條件的數(shù)據(jù)不渲染，符合條件的數(shù)據(jù)渲染，但是這其實就是在欺騙自己的不規(guī)范行為，因為實際上服務(wù)端并沒有響應(yīng)查詢，僅僅客戶端調(diào)整樣式蒙混過去。極少部分的技術(shù)極客，可能自己把數(shù)據(jù)load到內(nèi)存，建立空間索引，加到內(nèi)存的話可以自己設(shè)計一些索引再做關(guān)聯(lián)查詢，再把結(jié)果轉(zhuǎn)矢量切片壓縮形式傳回客戶端，一整套下來，很可能重新設(shè)計了一個空間數(shù)據(jù)庫。。。好吧，這么辛苦，不如當(dāng)初直接入庫了。。。 服務(wù)層沒啥好說的，就是優(yōu)化空間有限或者代價太大。。。 3.3 客戶端 客戶端最常見的騷操作就是支持用戶上傳shp，這個需求實質(zhì)上非?？拥话悴皇莾?nèi)行人設(shè)計出來的需求，其實客戶要求的應(yīng)該是支持上傳自定義gis數(shù)據(jù)，反應(yīng)到開發(fā)那就成了支持上傳shp數(shù)據(jù)，這樣的“需求變更”會生成一系列問題。 首先，shp文件通常有.shp、.dbf、.prj等多個文件組成，那么支持上傳的時候，常見做法是打個壓縮包，那么是打成.zip還是.tar還是.7zip？打包的路徑是包括文件夾還是不包括文件夾啊等等，畢竟打包是很任性的一種行為，客戶根據(jù)格式和文件路徑能排列組合成好多形式，你支持哪一種？ 其次，shp文件如果很大，幾十M？幾百M？幾個G大小系統(tǒng)需要控制嗎？這么大明顯不能傳過來啊，太占帶寬了不是？斷點還續(xù)傳？好容易傳過來，還要解析吧，解析完渲染卡了咋辦？還得自己將線面拆webgl的三角形？再webgl自定義圖層渲染？一頓操作猛如虎？每個步驟都要命！ 有人說我會控制上傳文件的大小，如果太大我就不支持，我還要求打包格式，還要求打包路徑，還要求。。。稍等下，客戶只想簡單的傳個東西顯示，你這么多要求，是不是明顯已經(jīng)傷害了客戶的感情？是不是他惹不起你干脆不用你這個功能？畢竟軟件中每多個步驟就少50%的用戶，你要求這么多，用戶不想記住那干脆不用了，成功過關(guān)？況且如果數(shù)據(jù)真的只有200k這么小，我shp上傳這么麻煩干嘛？我直接上傳geojson不香嗎？ 可能用戶不會轉(zhuǎn)geojson，在線網(wǎng)站，ogr2ogr等命令都能很輕松的將shp轉(zhuǎn)json，培訓(xùn)一些簡單操作給客戶，他轉(zhuǎn)好再上傳你系統(tǒng)，對客戶來說，操作簡單，對開發(fā)來說，實現(xiàn)簡單，雙贏的局面為什么不好好溝通下？ 實際上上傳shp就不是一個嚴(yán)謹(jǐn)?shù)?，重視體驗的系統(tǒng)應(yīng)該有的功能，彼此傷害的一個偽需求，由不懂的客戶發(fā)起，不懂的技術(shù)leader拍板，不懂的開發(fā)暴力上線，大家都在混才會有這個需求。。。 3.4 小結(jié) shp的表現(xiàn)在WebGIS任何一端，都是麻煩的制造者，不具備擴展性，不具備性能和功能，不具備系統(tǒng)開發(fā)的簡潔高效，不具備用戶體驗。。。那么作為項目的決策者，直接裸奔shp上系統(tǒng)，可能真是“無知者無畏”啊。。。 三 Shp實際應(yīng)用場景 上文把shp說的一無是處？錯了，shp并不是一無是處，只是被不懂的人用錯了地方，shp真正的用途絕對不是在企業(yè)WebGIS系統(tǒng)里，這類系統(tǒng)必然上空間數(shù)據(jù)庫，這就是當(dāng)年esri推的sde的緣故，大家都懂的道理，外行人亂用而已，如之奈何。本章節(jié)就正本清源的說下shp究竟用在哪里。
本想寫點別的用途，發(fā)現(xiàn)沒有了，shp就是停留在這了，一份中介性質(zhì)的數(shù)據(jù)格式，便于人與人，人與軟件的數(shù)據(jù)交換使用，在這個場景下，shp是絕對的王者，因此，請不要再在webgis系統(tǒng)中直接上shp數(shù)據(jù)源。 |
|
|
