投稿遅れてすみません
私のオープンソースGISを含んだ活動、Code for Historyの2023年のアップデートについて、先の記事に書いたもの以外を書きます。
Toriiとは、QGISが使える技術者がいない現場でも、Excelで情報を更新すれば、QGIS（GeoJSON）との間でマルチマスタとして相互に情報を同期しつつ、Webなどで情報を公開できる形式にまで変換してくれる文化財情報管理ツールです。
2022年2月の研究報告人文科学とコンピュータ（CH）126でこれについて発表しています。
実際の利用は、令和館林石造物悉皆調査や奈良地蔵プロジェクトで使われています。
別にFlatGeoBufに対応する予定など特になかったのですが、いわさきさんの記事を読んで俄然FlatGeoBufに興味が出たので、対応してみました。
実際に対応してみた結果ですが、元々のデータサイズが大きくなかったこともありますが、それほどデータの圧縮効果はありませんでした。
元々石造物の刻銘判読情報などテキストデータが多かったのでバイナリ化の恩恵が少なかったのと、あと現状の仕様ではObjectやArray型の属性値はテキストシリアライズした結果で格納されるようで、私のデータはバリバリ構造化データなので、これは相性悪いなと。
まあ、まだまだこれからの仕様じゃないかと思うので、将来のアップデートでObjectやArrayの属性値もバイナリ化したり、できるのかどうかわかりませんがテキストの属性値も圧縮データ化すればデータ量減らせるんじゃないのかな？とか思うので、将来に期待したいです。
[追記]
…というあたりをIssueに投げてみましたが、
別に否定的ではないのですが、
I would rather suggest compressing the whole file to keep compression and format separate.
そういわれると確かにそうですよね、FlatGeoBufの主眼の強みは別にデータサイズを小さくすることじゃなくて、Byte Rangeアクセスで部分取得ができるようなクラウドフレンドリーな仕様であるところにあるのだし。
単に転送量を小さくするだけならHTTPサーバでgz圧縮かければ済むのだし、そう考えるとToriiでFlatGeoBufに対応する意味はあまりなかったのかな（表示サイトもRangeリクエストせずにFGBファイル全体読み込んでるし）。
まあせっかく対応したのでそのままつけておきます、Byte Rangeリクエストが必要になるようなでかいプロジェクトで今後使われるかもしれないし。
後いくつかの話題についても書こうと思っていたのですが（Overture Maps Foundationの話や、MaplatEditorをGISデータ対応させる話など）、ただでさえ投稿が遅れているし記事が長くなるばかりなので、今回はこのネタだけでおしまいにします。
それでは皆さん、よいお年を。