一种为地理图形数据进行二进制编码的格式，基于 flatbuffers，它能容纳 OGC 发布的 Simple Features（简单要素）规范下的数据。
本编码格式受到 geobuf 和 flatbush 的启发。为了简单起见，此编码特地不支持随机写入。此编码格式使用希尔伯特R树（Hilbert R-Tree）作为数据结构，所以其使用范围框（Bounding Box）来进行空间检索的速度是非常快的。对于此编码格式来说，空间索引不是必须的，以便数据能以文件流的形式高效率地写入，以及适配不需要空间过滤（即空间检索）的情况。
设计目标：大数据量的静态数据要比传统格式快，且对于数据量、内容上没有大小的限制，并且适合流式或随机访问。
网站 switchfromshapefile.org 介绍了传统格式（尤其是 shapefile）的更多比对信息，且提供了一些替代方案，同时也提供了替代方案的存在缺点（例如，不适合流式传播）。
FlatGeobuf 是开源的，使用 BSD 2-Clause License 协议。
译者注
所谓流式传输，即可以一边通过 HTTP 传输数据，一边解析并可视化，而不必等待一个 fgb 文件全部请求到前端再做绘制，网络传过来多少数据，前端就画多少，极大提升单文件显示的体验。
0x6667620366676200在 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% |
查看 示例。
它不是 8字节对齐的编码。所以，它没有复制完整的文件之前，最好不要用它。
性能和随机读、流式读的原因。
GDAL 的操作，默认假设数据是不可信的，会进行数据验证以确保操作安全性。如果你相信你的数据，想要一个最大的性能表现，请设置参数 VERIFY_BUFFERS 为 NO。
FlatGeobuf 与矢量瓦片并无竞争关系。矢量瓦片十分适合渲染，但是它是有损格式，而且在创建成本上比较高。FlatGeobuf 是无损格式，如果不需要空间索引数据，数据的写入（创建）是非常快的。
FlatGeobuf 编码格式(fgb) —— 或许是 shp 格式的替代品
原文：https://www.cnblogs.com/onsummer/p/14856870.html