FlatCityBuf example datasets
Table of contents
Ready-made files
The smallest one first: Delft (7MB) — 1115 buildings from the 3DBAG, all 44 attributes indexed. It lives in the repository, and every example on this site uses it.
The published files are served from https://flatcitybuf.open3d.city/data/, on Cloudflare R2 with range requests and CORS enabled, so you can query any of them straight from a script or from the browser — including from the web viewer, which opens the 68GB one by default. Sizes are decimal (1 MB = 10⁶ bytes).
The three *_all_index.fcb files at the bottom are the benchmark set: the whole 3DBAG (10 771 547 features) and two subsets, written with every attribute indexed. The rest is one file per source dataset.
Every dataset also exists as CityJSONSeq under https://cityjson.open3d.city/cityjsonseq/, same stem with a .jsonl extension. That second table, and the notes on range requests and CORS, are in the repository’s canonical inventory: docs/data.md.
You can always convert any CityJSONSeq file to a FlatCityBuf (and vice-versa), see the CLI page.
Looking inside a file
Before writing any code, fcb inspect tells you what a file contains — how many features, in which CRS, and, crucially, which attributes are indexed and therefore queryable. It opens a terminal UI when it has a terminal and prints a static report otherwise (or with --static), and it accepts a URL, reading only the header bytes — so it is instant even on the 68GB file:
fcb inspect delft.fcb
fcb inspect --static delft.fcb
fcb inspect https://flatcitybuf.open3d.city/data/3dbag_all_index.fcb
See inspecting a file.
Serving your own .fcb files
FlatCityBuf needs no special server: static hosting is enough, as long as the server
- supports HTTP range requests (
Accept-Ranges: bytes, and honoursRangewith a206response), and - exposes the
Content-Rangeheader to the browser when the file is on another origin.
The second one is the usual stumbling block. Browsers hide response headers on cross-origin requests unless the server explicitly exposes them, and a reader learns the file size from Content-Range — so it refuses to guess and reports something like “sent a 206 response without an accessible Content-Range header”. The fix is a CORS header:
Access-Control-Expose-Headers: Content-Range, Accept-Ranges
If you host on Google Cloud Storage:
echo '[{"maxAgeSeconds":3600,"method":["GET","HEAD","OPTIONS"],"origin":["*"],"responseHeader":["Content-Type","Content-Range","Accept-Ranges"]}]' > cors.json
gsutil cors set cors.json gs://your-bucket
After changing CORS, hard-reload the page: the browser may have cached the earlier failed response.
To check a host before pointing a reader at it, use the one-line curl recipe in docs/data.md — a 206 answer with an Accept-Ranges and a Content-Range header is all FlatCityBuf needs.