問題を解決する強力な新しい方法を共有するのはいつも満足感があります。特に、その解決策がしばらくの間「明白なところに隠れていた」場合はなおさらです。今回は、ArcGIS Enterprise branch versioningとcloud native data sharingの組み合わせが、ポータルアクセス権のない人々にも高速なデータアクセスを提供するだけでなく、アクセスしたデータに対して若かった頃に時間を遡るように要求できる能力をもたらすことを示します。例えばこれらの区画、以前は分割されていなかった区画が現在は3つに分割されています。<\/P>
Parcel subdivision<\/span>Parcel subdivision<\/SPAN><\/SPAN><\/P>数百万のフィーチャーを持ち、branch versioningが対応するような日々激しいメンテナンスが行われているデータセットを想像してください。お客様は任意の時点でデフォルトバージョンの全体または一部にアクセスできます。永遠に。Enterpriseポータルへの追加負荷なしで。<\/P>では、どうやってここまで来たのでしょうか？単純にbranch versioningの挿入専用トランザクションモデルが、時間経過によるデータ状態を共同で保持し、空間的かつ時間的にクエリ可能で、関心のある地域と時間のローカルデータをオンデマンドで作成できるGeoParquetファイルをクラウドストレージに段階的に作成するのに適していることに気づいただけです。<\/P>しかしこれは非常に高度なクエリです！良いニュースは、あなたがそれを理解する必要はなく、このブログダウンロードには私の区画関連の例が入ったノートブックがあり、自分のものを差し込むだけで済むことです。<\/P>クエリ手法自体は私が発明したわけではなく、Esriがこのトピックについてワークショップ資料を公開しています。例えばこのプレゼンテーションの18分あたりを見ると、そのようなクエリがどんなものか分かります。<\/P>Spoiler (読むにはハイライトしてください)<\/noscript>2026年5月5日にノートブックでQUALIFY句を使用し、履歴データ抽出用ノートブックを追加するため更新しました。<\/div>2026年5月5日にノートブックでQUALIFY句を使用し、履歴データ抽出用ノートブックを追加するため更新しました。<\/div><\/div><\/noscript><\/div><\/div>クエリ可能なGeoParquetファイルと初期および増分パーケットファイル作成用メンテナンスワークフローは自分で作成しました。すべてはソースとなるbranch versioned Enterpriseジオデータベースフィーチャークラスから始まります。通常、branch versioningを支えるシステムフィールドは見えませんが、アーカイブクラスをマップに追加すると利用可能になります：<\/P>
Archive class added to the map<\/span>Archive class added to the map<\/SPAN><\/SPAN><\/P>フィールドマップで注目すべき点はいくつかあります：ObjectIDは通常のlong整数に格下げされ（値はもはや一意ではありません）、GDB_*という名前の様々なフィールドが追加されています。これらは任意の時点でデータを見ることを可能にし、それがbranch versioningの仕組みです—最新状態のフィーチャーが勝ちます。それは削除状態かもしれませんが、データ履歴は失われず（削除しない限り）、これがタイムトラベルを可能にします。<\/P>アーカイブクラスはまた、編集時点の発見にも役立ちます。<\/P>アーカイブクラスによってすべてのフィールドへの可視性が提供されることで、共有とメンテナンスワークフローが可能になりました。その流れは次の通りです：<\/P>GDB_BRANCH_ID = 0 のすべてのアーカイブクラス行で初期パーケットファイルを作成する<\/LI>適切なスケジュールで、新しいデフォルトブランチ行状態用デルタパーケットファイルを作成するこれらは既存すべてのパーケットファイル中最大の日付より後の日付GDB_FROM_DATEを持つ<\/LI>またGDB_BRANCH_ID = 0 を持つ<\/LI><\/UL><\/LI>S3互換オブジェクトストア内のお気に入りグロブパスで全パーケットファイルを管理する<\/LI>データ利用者にはデータ抽出用ノートブックまたはスクリプトツールを提供する提供されたノートブックにはPython環境内でDuckDBバージョン1.0.0が必要<\/LI><\/UL><\/LI><\/UL>今私はこれをクラウドネイティブデータ配布として宣伝していますが、執筆時点ではまだAWSアカウント設定中なので添付ノートブックはローカルファイルシステムパスを使っています。公開S3 URLパスが利用可能になったら更新します。その間、テスト用サンプルデータはこちらからダウンロードできますこちら, こちら, こちら および こちらです。これらは初期一括バージョンコピーといくつかの日々編集分の増分デルタファイルです。S3パス設定までノートブック内pqPath変数をご自身の環境に合わせて変更してください。<\/P>Spoiler私が使っているデータは実際にはbranch versionedジオデータベースで管理されていません。サンプルデータを作成しましたので上記リンク先アイテム詳細内のデータ許可をご覧ください。<\/DIV>私が使っているデータは実際にはbranch versionedジオデータベースで管理されていません。サンプルデータを作成しましたので上記リンク先アイテム詳細内のデータ許可をご覧ください。<\/DIV><\/DIV>ノートブックでは範囲(extent)とタイムトラベルクエリ用テンプレートも提供しています。私の場合、ローカルディスクから270万区画すべて抽出するのに約3分強かかります。S3からアクセスすると少し遅くなると思いますが、それも設定でき次第試してみます。ぜひご自身でもノートブックを試してください。<\/P>ノートブックについていくつか質問があるかもしれませんので予想してみます：<\/P>DuckDB 1.0.0 はEsri Condaチャネルで使われており、それ以降バージョンではジオメトリ処理方法が異なるため使用している<\/LI>パーケットファイル内bbox列はJSON型だがDuckDBではJSONとして認識されずvarcharとしてクエリしている<\/LI>DuckDB組み込みrowid擬似列使用時エラーとなったため上書きした<\/LI>空間対応DataFrame経由で出力フィーチャークラスを書き込もうとしたらエラーになった<\/LI>ブログダウンロード内project atbxには望ましい出力テキストフィールド幅探索用スクリプトツールあり<\/LI><\/UL>ここで少しわがままになります。サンプルデータとパーケットファイル作成用にいくつかETLツール（Pro 3.4）を構築しましたが、それらはブログダウンロードには含まれていません。興味ある方はメッセージください。共有します。このデータ共有パラダイムにどれだけ関心あるか聞けるとチームとして助かりますので、ご協力お願いします。<\/P>
