日韩综合网站,欧美黄色成人在线,欧美精品久久久久久久久久,精品三级在线观看,后入无码日韩,www午夜视频,日韩精品二区中文字,精品在线免费视频

當前PostGIS最新版本是3.3，本系列將分別詳細描述下從PostGIS 3.0-PostGIS 3.3有哪些新特性，本文僅描述3.2版本新特性，部分資料說明來源于postgis作者paul的個人技術博客，其中官方原文內容說明參考：git.osgeo.org/gitea/postgis/postgis/raw/tag/3.2.0/NEWS，本文僅就相關內容整理。

一?版本約束

????一般約束：PostGIS 3.2支持9.6及以上版本，要求編譯GEOS 3.6及以上版本。

?????推薦約束：PostgreSQL 14+PostGIS3.2?版本搭配，其中PostGIS 3.2編譯需要Proj 6.1及以上版本，GEOS 3.10.0版本。

?????熟悉PostGIS的應該知道，PostGIS是依賴一系列底層基礎庫的，如GEOS（圖形topo計算），Proj（地理投影），GDAL（矢量柵格空間讀取與計算），SFCGAL（三維圖形計算）還有其他基礎庫，不同基礎庫的升級會影響PostGIS功能，如果希望能使用上PostGIS新版本特性，請嚴格按照推薦約束使用。

二主要特性

2.1 移除wagyu編譯可選項

postgis3.0集成Mapbox的wagyu算法，但是是可選項，用戶可以通過

`--without-wagyu`參數(shù)不使用該算法，這樣可以生成動態(tài)矢量切片但性能有點損失，由于這個選項基本毫無意義，在postgis3.2版本移除該編譯選項，從而在生成矢量切片時默認統(tǒng)統(tǒng)使用wagyu算法。簡化沒有收益的不必要的配置。

2.2 具有副作用的gist索引構建加速

在pg14+postgis3.2版本中，使用Hilbert排序算法可以大大加快構建gist索引耗時，約提升了2-5倍。但副作用是基于這種排序構建的gist索引查詢性能會下降很多，大約下降30%。考慮到索引的構建與基于索引的查詢頻次并不相同，用戶可能構建一次或多次索引，但會更見頻繁的基于空間索引去查詢數(shù)據(jù)，因此，雖然該版本支持加快索引構建，但是并不是默認的。

在您理解副作用的前提下，可手動調整開啟構建索引算法：

      
        ALTER OPERATOR FAMILY gist_geometry_ops_2d USING gist
      
      
          ADD FUNCTION 11 (geometry)
      
      
          geometry_gist_sortsupport_2d (internal);

也可以關閉，使用默認索引構建：

      
        ALTER OPERATOR FAMILY gist_geometry_ops_2d using gist
      
      
          DROP FUNCTION 11 (geometry);

2.3 新增ST_InterpolateRaster離散點插值成柵格

ST_InterpolateRaste

ST_InterpolateRaster用于獲取一批散點，每個散點都有測量值，根據(jù)散點的xy坐標和測量值，通過空間插值與圖像插值算法，生成一副柵格圖像。熟悉gis的都知道例如idw（反距離權重）空間插值，熟悉圖形學的知道最近鄰插值，雙線性插值等，該api就是通過這些插值算法生成一副插值結果，結果以柵格對象輸出，存儲以postgis的rast對象存儲。

當前，ST_InterpolateRaster支持5種插值算法：反距離權重插值, inverse distance nearest-neighbor, moving average, 最近鄰插值,雙線性插值。

個人評價：在gis領域常用的空間算法是idw，克里金插值算法，這些算法通常具有較強的業(yè)務定制性優(yōu)化，測量樣本點通常不大，通過數(shù)據(jù)庫存儲測量樣本點，服務端查詢樣本點方式，在服務端生成插值結果通常是更常用方案。

在重視oltp場景下，這些算法通常很吃cpu，耗時比較嚴重和不可控，除非你真的想知道在干嘛，否則這些算法最好不用于直接對用戶的服務。

2.4 新增ST_Contour，基于柵格生成等值線

ST_Contour

ST_Co ntour支持基于柵格圖像，使用marching squares算法生成等值線數(shù)據(jù)，僅僅支持生成等值線，不支持等值面。

個人評價：等值線面算法通常也是服務端生成，因為在數(shù)據(jù)庫中生成耗時嚴重，postgis新實現(xiàn)的這些api本身其實是gdal中新增實現(xiàn)的方法的封裝，并沒有太大的實際意義。

實際業(yè)務中，數(shù)據(jù)庫仍然是存散點測量數(shù)據(jù)，由服務端查詢測量數(shù)據(jù)，根據(jù)空間插值生成柵格（或者說格網(wǎng)，柵格和格網(wǎng)很相似，但有一點點差異）數(shù)據(jù)，然后根據(jù)ms算法生成等值線，基于等值線與格網(wǎng)邊框關系，線與線的關系，封裝閉合等值面。

2.5 新增的ST_SetM,ST_SetZ，修改柵格數(shù)據(jù)

2.6?根據(jù)坐標提取柵格數(shù)據(jù)像素值ST_Value支持雙線性插值

2.7 支持柵格的云存儲

柵格影像都是geotiff這種文件格式，正常非遙感、氣象等行業(yè)，很少會有將影像存儲到數(shù)據(jù)庫的需求。而對強應用行業(yè)來說，如何將高頻觀測影像結果存儲和應用是個問題。

postgis的柵格數(shù)據(jù)管理能力是gdal賦予的，postgis支持in-db與out-db兩種柵格存儲形式。in-db即將柵格影像數(shù)值與元數(shù)據(jù)都存入數(shù)據(jù)庫，out-db將柵格影像元數(shù)據(jù)存入數(shù)據(jù)庫，實際影像數(shù)值數(shù)據(jù)不存，仍以文件形式存儲。

總的來說，in-db由于切片的原因在大部分應用場景下性能更高，而out-db架構更靈活，但本身沒更改原始數(shù)據(jù)，沒有切片，在大部分場景下性能不是很高。

隨著云計算、云存儲等新的it架構的形成，gdal目前支持以vsicurl形式訪問云服務器，存儲桶上等存儲的數(shù)據(jù)，例如aws s3,google cloud storage,azure等。因此，postgis新增postgis.gdal_vsi_options等變量支持綁定數(shù)據(jù)庫與云存儲里的影像數(shù)據(jù)。

postgis的云柵格數(shù)據(jù)管理能力實際是借由out-db和gdal的vsicurl兩個混合而來的。

個人評價：明顯不考慮性能，也不是面向oltp的場景，更加偏向于數(shù)據(jù)管理和離線計算（不追求性能場景下）的架構創(chuàng)新。一般業(yè)務用不到。

2.8?支持FlatGeoBuf格式

簡單來說，FlatGeoBuf是一種流式傳輸格式，例如一個100M的空間數(shù)據(jù)傳到客戶端顯示，客戶端需要接收完整的數(shù)據(jù)，解析后渲染，這個網(wǎng)絡不好就很耗時。流式傳輸就是客戶端收到多少數(shù)據(jù)，解析并渲染多少（就是視頻播放器那種邊下邊看的意思），則在較大數(shù)據(jù)的渲染時有好的用戶體驗。

更多FlatGeobuf格式說明參考：《FlatGeobuf 編碼格式(fgb) —— 或許是 shp 格式的替代品》（https://zhuanlan.zhihu.com/p/378426761）

總的來說：FlatGeoBuf是無損的格式，也比較偏向于云存儲優(yōu)化的數(shù)據(jù)存儲領域。但其實應用場景并不多，業(yè)務里應用場景更多的是基于Protobuf的矢量切片技術（有損壓縮）。因此這種格式并沒有廣泛應用和很好的應用案例，但實現(xiàn)該方法，也是未來業(yè)務創(chuàng)新的一個機會。

三總結

postgis3.2新增內容對業(yè)務的影響較小，主要是柵格數(shù)據(jù)的處理能力加強（但不必要），云柵格（vsicurl），云矢量（flatgeobuf)等云上能力的業(yè)務創(chuàng)新。總的來說，當前gis里云數(shù)據(jù)云存儲優(yōu)化很多，比如geotiff與cloud optimized geotiff(cog，云優(yōu)化tif），需部署于動態(tài)服務器的切片存儲格式MBTiles與適合云存儲的部署靜態(tài)服務器的切片存儲格式PMTiles。

在gis領域，類似”文件即服務“的形式目前有多點開花狀態(tài)，文件即服務的形式可能是云存儲廠商技術在推動的，比較靜態(tài)化，比較適合他們的業(yè)務開展，當然如果你業(yè)務恰好很合適，也是值得思考的方向，但實際大部分業(yè)務中的很多數(shù)據(jù)是動態(tài)化的，因此，在實際選型時還是要仔細考慮實際情況。

postgis 3.2的新特性，也就是說指明了一些用戶可以創(chuàng)新的方向，并未帶來傳統(tǒng)功能上性能更好的體驗。

另外，新的柵格API并不是實際業(yè)務中最優(yōu)解決方案，能別用就先別用，除非你不懂也不想寫算法，只把數(shù)據(jù)庫當個工具而已。。。

PostGIS 3.2新特性