執筆時点で、私は2026年のEsriユーザー会議で「Cloud-Native Georelational Data Distribution」というタイトルのデモシアターセッションを担当することになっています。 もしUC 2026に参加されるなら、スケジュールに追加できます。 参加できない場合は、以下に示すプレイブックが内容ですが、UC参加を促すために本には欠けている章があり、それをライブでお見せします。つまり、AWS S3から場所や建物の特徴のデータモデルを強制しながら、どれだけ速くマップやシーンにデータを取り込めるかということです。なぜなら、常に単なるデータではなく情報製品として考えるべきだからです。<\/P>
このプロットにはデータ速度の話が3つのスレッドに分かれています。データセットのライフサイクルは以下のように分類しています:<\/P>
- まれな周期的な一括置換
- 時間対応していないベースレイヤーデータ<\/LI><\/UL><\/LI>
- 頻繁な追加とアップサート
- 継続的に増加しライフステージがあり時間対応している運用レイヤー<\/LI><\/UL><\/LI>
- 中頻度の 挿入、更新、削除編集
例えば2026年までの日付範囲内でポリゴン内全311ケースをメモリフィーチャークラスへ抽出した例があります - 4秒でした. 約8500フィーチャーあります.<\/P>
San Francisco Query<\/span><\/span><\/P>このクエリツールはスクリプトツールで、その秘密兵器はQUALIFY句です。 日々生成されるGeoParquetファイルにはケースライフサイクル（ある日は開設、別の日は編集、更に後の日は閉鎖）による重複があります。そのため全GeoParquetファイル群からサービス要求IDごとに最新行のみ欲しいわけですが、このparquetクエリ時QUALIFY句がそれを実現します。<\/P> conn.sql(f"""create or replace temp view sf311_view as select
service_request_id,requested_datetime,closed_date,updated_datetime,
status_description,status_notes,agency_responsible,service_name,
service_subtype,service_details,address,street,supervisor_district,
neighborhoods_sffind_boundaries,police_district,source,media_url,
bos_2012,data_as_of,data_loaded_at,ST_AsWKB(GEOM) as wkb
from read_parquet('{pqPath}',filename=false)
where {where}
and ST_Intersects(ST_GeomFromText('{wkt}'), GEOM)
qualify row_number() over (partition by service_request_id order by updated_datetime desc) = 1;""")<\/code><\/pre> <\/P>さて今や簡単になりました クラウドネイティブな方法で高速なクエリを用いて変化の激しいデータを配信する方法。<\/P>かなり大きなデータがあるが、変更をクエリする方法がない場合はどうでしょうか？<\/P> <\/P>継続的な挿入、更新、および削除編集<\/H3> <\/P>ブランチバージョニングされた編集が頻繁に行われるデータはGISにとって非常に価値のある作業であり、その基盤となるフィーチャサービスへのアクセスを提供してデータ状態を共有することはできますが、サーバーにパブリックマッピングの負荷を追加することは管理者には歓迎されません。 実は、クラウドネイティブなアプローチを使って時間旅行をサポートしながらデータの状態を共有することができます。<\/STRONG> これを可能にしているのは、ブランチバージョニングの挿入専用データモデル<\/STRONG>です。特徴の任意の時点での状態は、OBJECTIDと組み合わせたGDB_FROM_DATEによって決まります。各OBJECTIDの一意の値に対して最新のGDB_FROM_DATEを持つ行が特徴の現在の状態であり、より古いGDB_FROM_DATEの値をクエリすると時間旅行が得られます。 唯一のコツは編集時点を表すGeoParquetファイルを作成することですが、その後QUALIFY句が再び助けとなり、必要なデータを提供します。<\/P>ここに同じ範囲と同じソースGeoParquetファイルを使用した区画データの2つのビュー<\/STRONG>があります。<\/P>
現在および過去の瞬間<\/span><\/span><\/P>左側のビューは最新の瞬間で、右側のビューは過去の瞬間です。多くの区画分割が行われたことがわかります。 データソースは完全なデータ履歴を保持しており、編集は新しいGeoParquetファイルがフォルダまたはクラウドオブジェクトストアに追加される結果となります。 ここでは元の状態のベースラインとして1.46GBのGeoParquetファイルと、2週間にわたる編集を含むいくつかの小さなGeoParquetファイルがあります。<\/STRONG><\/P>
完全なデータ履歴を含むGeoParquetファイル<\/span><\/span><\/P>こちらはブログダウンロードファイル CloudNativeDataDistribution.zip<\/STRONG> のマニフェストです:<\/P>ImportCurrentDivisionAreas.ipynb<\/STRONG> ノートブックOverture Division Areaフィーチャをプロジェクトホームジオデータベースにダウンロードします<\/LI>関連テーブルでフィーチャに多言語名を作成します<\/LI>Division Areaフィーチャを参照データとして使用してロケーターを作成または更新します<\/LI><\/UL><\/LI>GetBaselineSF311<\/STRONG> 空間ETLツールサンフランシスコの311全データセットをGeoParquetに抽出します<\/LI>ArcGIS Data Interoperabilityが必要です<\/LI>アカウントとアプリトークンが必要です<\/LI><\/UL><\/LI>GetUpdatesSF311<\/STRONG> 空間ETLツール既存のGeoParquetファイルより新しい311ケースデータを抽出します<\/LI>新しいGeoParquetファイルを作成します<\/LI>ArcGIS Data Interoperabilityが必要です<\/LI>アカウントとアプリトークンが必要です<\/LI><\/UL><\/LI>Generate311Points <\/STRONG>スクリプトツールGeoParquetファイルを使ってメモリフィーチャクラスを作成する方法を示します<\/LI><\/UL><\/LI>ExtractCurrentParcels.ipynb<\/STRONG> ノートブック
ブランチバージョニングデータモデル内でGeoParquetファイルの最新データ状態を抽出する方法を示します<\/LI><\/UL><\/LI>ExtractEarlierParcels.ipynb<\/STRONG> ノートブックブランチバージョニングデータモデル内でGeoParquetファイルの過去のデータ状態を抽出する方法を示します<\/LI><\/UL><\/LI><\/UL>含まれていませんがリクエスト可能なのは区画データ用GeoParquetファイル作成に使用したツールです。 私のサンプルツールではローカルファイルストレージでGeoParquetを使用していますが、本番環境ではAWS S3などクラウドオブジェクトストアを使用します。<\/P>さて、2026年サンディエゴユーザー会議でお会いできることを願っていますが、もっと励みが必要ならば、Overture Buildingテーマデータをシーンに取り込むデモの先行プレビューをご覧ください。ブログダウンロード内にいくつかイースターエッグスクリプトツールがありますので探してみてください 😉.<\/P>
Overture Buildings<\/span><\/span><\/P> <\/P>
