FlatGeobuf
一種為地理圖形數據進行二進制編碼的格式，基於 flatbuffers，它能容納 OGC 發布的 Simple Features（簡單要素）規范下的數據。
本編碼格式受到 geobuf 和 flatbush 的啟發。為了簡單起見，此編碼特地不支持隨機寫入。此編碼格式使用希爾伯特R樹（Hilbert R-Tree）作為數據結構，所以其使用范圍框（Bounding Box）來進行空間檢索的速度是非常快的。對於此編碼格式來說，空間索引不是必須的，以便數據能以文件流的形式高效率地寫入，以及適配不需要空間過濾（即空間檢索）的情況。
設計目標：大數據量的靜態數據要比傳統格式快，且對於數據量、內容上沒有大小的限制，並且適合流式或隨機訪問。
網站 switchfromshapefile.org 介紹了傳統格式（尤其是 shapefile）的更多比對信息，且提供了一些替代方案，同時也提供了替代方案的存在缺點（例如，不適合流式傳播）。
FlatGeobuf 是開源的，使用 BSD 2-Clause License 協議。
譯者注
所謂流式傳輸，即可以一邊通過 HTTP 傳輸數據，一邊解析並可視化，而不必等待一個 fgb 文件全部請求到前端再做繪制，網絡傳過來多少數據，前端就畫多少，極大提升單文件顯示的體驗。
例子（可能要魔法上網）
規格
- 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
預打包（適用於瀏覽器）
- 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 格式無明顯優勢，沒有使用信息壓縮算法
- 編碼規范文檔缺乏