FlatGeobuf
一種為地理圖形資料進行二進制編碼的格式，基于 flatbuffers，它能容納 OGC 發布的 Simple Features（簡單要素）規范下的資料，
本編碼格式受到 geobuf 和 flatbush 的啟發，為了簡單起見，此編碼特地不支持隨機寫入，此編碼格式使用希爾伯特R樹（Hilbert R-Tree）作為資料結構，所以其使用范圍框（Bounding Box）來進行空間檢索的速度是非常快的，對于此編碼格式來說，空間索引不是必須的，以便資料能以檔案流的形式高效率地寫入，以及適配不需要空間過濾（即空間檢索）的情況，
設計目標：大資料量的靜態資料要比傳統格式快，且對于資料量、內容上沒有大小的限制，并且適合流式或隨機訪問，
網站 switchfromshapefile.org 介紹了傳統格式（尤其是 shapefile）的更多比對資訊，且提供了一些替代方案，同時也提供了替代方案的存在缺點（例如，不適合流式傳播），
FlatGeobuf 是開源的，使用 BSD 2-Clause License 協議，
譯者注
所謂流式傳輸，即可以一邊通過 HTTP 傳輸資料，一邊決議并可視化，而不必等待一個 fgb 檔案全部請求到前端再做繪制，網路傳過來多少資料，前端就畫多少，極大提升單檔案顯示的體驗，
例子（可能要魔法上網）
- 流式傳輸例子
- OpenLayers 例子
- Leaflet 例子
規格
- MB：魔法字符，指示此檔案用，即
0x6667620366676200 - H：頭部資訊
- I：（可選）被打包的靜態希爾伯特R樹 索引資料，
- DATA：要素資料
在 fgb 檔案中，任何 64 位 flatbuffer 資料值（例如坐標資料）必須進行 8位元組對齊，以便直接進行記憶體訪問，
任何字串值假定其編碼為 UTF-8，
性能
從 OSM 上下載的一份 shapefile 檔案，約 90 萬條線要素，選取五種格式的各方面性能比對如下表：
| Shapefile | GeoPackage | FlatGeobuf | GeoJSON | GML | |
|---|---|---|---|---|---|
| 讀取完整資料 | 100% | 102% | 46% | 1500% | 890% |
| 使用空間索引讀取 | 100% | 94% | 71% | 70500% | 39900% |
| 寫入完整資料 | 100% | 77% | 39% | 390% | 320% |
| 帶空間索引寫入 | 100% | 158% | 65% | - | - |
| 檔案大小 | 100% | 72% | 77% | 120% | 210% |
此測驗使用 GDAL 的 FlatGeobuf 驅動，設定讀取引數為 ogrinfo -qq -oo VERIFY_BUFFERS=NO 進行回圈重復讀取資料，對于檔案寫入的測驗中，使用 ogr2ogr 以及分別使用引數 -lco SPATIAL_INDEX=NO 和 -lco SPATIAL_INDEX=YES 將原始資料轉換成新檔案，
在空間索引的測驗項中，只選取了一個比較小的范圍框，它范圍內僅有 1204 個要素，僅僅是為了測驗空間索引的性能，
使用一份由 251萬多個多邊形的資料來進行性能測驗，結果如下表：
| Shapefile | GeoPackage | FlatGeobuf | |
|---|---|---|---|
| 讀取完整資料 | 100% | 23% | 12% |
| 使用空間索引讀取 | 100% | 31% | 26% |
| 寫入完整資料 | 100% | 95% | 63% |
| 以空間索引寫入 | 100% | 107% | 70% |
| 檔案大小 | 100% | 77% | 95% |
特性
- 在 JavaScript、TypeScript、C++、C#、Java、Rust 已有實作
- 高效率的 IO 表現（包括流式和隨機）
- GDAL/OGR 驅動 支持
- GeoServer WFS 輸出格式 支持
程式/庫支持
- Fiona（1.8.18 以上）
- GDAL（3.1 及以上）
- Geo Data Viewer（VSCode 插件）（2.3 及以上）
- GeoServer（2.17及以上）
- GeoTools（23.0及以上）
- QGIS（3.16及以上）
檔案
TypeScript / JavaScript
API 檔案
預打包（適用于瀏覽器）
- flatgeobuf.min.js 包含了通用模塊
- flatgeobuf-geojson.min.js 包含了 geojson 模塊
- flatgeobuf-ol.min.js 包含了 openlayers 模塊
NodeJs 用法
查看 示例，
TODO
- Java 索引支持
- C 語言支持
- Go 語言支持
問答
為什么不用 WKB 幾何編碼？
它不是 8位元組對齊的編碼，所以，它沒有復制完整的檔案之前，最好不要用它，
為什么不用 Protobuf？
性能和隨機讀、流式讀的原因，
為什么我用 GDAL 沒有達到期望的性能表現？
GDAL 的操作，默認假設資料是不可信的，會進行資料驗證以確保操作安全性，如果你相信你的資料，想要一個最大的性能表現，請設定引數 VERIFY_BUFFERS 為 NO，
與矢量瓦片比較呢？
FlatGeobuf 與矢量瓦片并無競爭關系，矢量瓦片十分適合渲染，但是它是有損格式，而且在創建成本上比較高，FlatGeobuf 是無損格式，如果不需要空間索引資料，資料的寫入（創建）是非常快的，
譯者注
優點
- 單檔案
- 支持R樹的空間索引，帶索引的資料讀取性能高
- 支持流式傳輸
- 無損格式
- 檔案體積相對不大
- 多編程語言、多軟體已支持
缺點
- 不支持像 GeoPackage 格式一樣有擴展能力
- 幾何與屬性資料并未分離，若能分離，幾何資料可進一步優先傳輸并極大提高渲染速度
- 創建檔案時若使用空間索引，效率上可能會有所打折（但是也比傳統格式快）
- 檔案體積較之于 GeoPackage 格式無明顯優勢，沒有使用資訊壓縮演算法
- 編碼規范檔案缺乏
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/285874.html
標籤：GIS