データが変わったら、トレントクライアントはどうやってそれを拾って変更をダウンロードするんだろう？

CIは計算リソースの無駄遣いの一つだと思うけど、地図データがライブラリや他のコードと同じように乱用されるとは思えないな。

CIサーバーからのリクエストを確実に特定できるのかな？

GPKGファイルを「クエリ」するウェブアプリがあるんじゃないかな。Parquetは精密にクエリできるけど、GPKGでも同じことができるかはわからないな。

何か軽量な認証（APIキーとか、メールベースでも）を持つのはいい妥協だと思う。

ログインがないから、メールアドレスも持ってないよね。

いくつか考えられる理由があるね。1. BitTorrentは悪いイメージがある。ほとんどの人は違法ダウンロードと結びつけて考えてる。2. ちょっと複雑なファイアウォールのルールが必要で、ネットワーク管理者にそれを設定してもらうのは、理由1のせいでちょっと抵抗があるかも。非常に制限の厳しいネットワークでは、BitTorrentのせいで全く許可したくないってこともあるし。3. BitTorrentクライアントはHTTPクライアントよりも複雑で、ほとんどの会社のコンピュータやCIパイプラインにはインストールされてない（必要がないから、そしてまた理由1）。多くの人はただcurlして終わりにしたいんだよね。4. 多くの人がシードする必要があると思ってて、なぜかそれが怖いみたい。全体的に見て、理由1と、単にcurlしてすべてが動くっていう事実が大きいと思う。BTがどれだけ優れたファイル転送プロトコルか、そしてそれがどれだけ使われていないかを理解していないのが悲しいな。確か、あるゲームクライアントが裏でBTを使ってアップデートしてたのを覚えてるし、peertubeはwebtorrentを使ってるけど、残念ながらBTはあまり人気がないね。

単にhttpが持ってる「ユニバーサルクライアント」がないからだと思うし、devたちがssh/scpで持ってることが多いんだよね。そんなクライアント（自動化されたスクリプトCLIクライアントでも）を設定するのが難しいわけじゃないけど、トラッカーも必要になるし、それを維持するためのツールも必要だし。直感的に言うと、これらは不可能じゃないし、数カ所の難しいところを除けば、そんなに難しくもないと思う。要は、非常に大きなファイルやセットの頻繁なダウンロードに対する需要がどれくらいあるかってことが問題なんだよね。それが信頼性やシーディングのボリュームの問題につながって、ツールを開発して様々なRCSやファイル同期サービスと統合するための労力と対比されることになる。Git LFSみたいなものが役立つかな？ここら辺は私の理解の限界だわ。