前回のブログでは、ホストされたフィーチャ レイヤーを維持することを目的とした速度テストで、ノーコードの変更データキャプチャとビューソーススワップのパフォーマンスを検証し、引き分けとしました。今回は、新たにコード化されたソリューションの世界から、ArcGIS Online ホストノートブックを使用して、日々変化するソースデータに対してホストされたフィーチャ レイヤーのデルタトランザクションを計算および適用する方法をご紹介します。
対象データは前回のブログと同じく、ロサンゼルス市の街路住所ポイントで、毎日更新されています。
ロサンゼルス住所ポイント
データセットには約100万ポイントがあり、毎日数百件の挿入、更新、削除があります。アップサート（挿入と更新を単一トランザクションで行う組み合わせ）のユースケースについて以前から書きたいと思っていましたが、これは現在 Pro のAppend ジオプロセシングツールでサポートされており、そのためノートブックの ArcPy 高度ランタイムでも利用可能です。
話が先走りましたので、まず状況を整理しましょう。コード化された ETL ワークフローを検討するには、データが適切に管理されていることが重要です。ETL プロセス中に修正や変換をほとんど必要としないことが望ましいです。ノートブックでデータを見ることはできますが、深いデータ検査や問題発見は非常に困難だからです。もしデータを信用できない場合は ArcGIS Data Pipelines または ArcGIS Data Interoperability を使用すべきです。
このケースでは、市がよく管理されたデータを提供しているため、コード化されたリフトアンドシフトプロセスを安心して推奨できます。
使用したツールに戻ります。ブログのダウンロードには ArcGIS Pro 3.6 のツールボックスとモデルがあります。このモデルは、市のオープンデータサイトからダウンロードした CSV データを使ってファイルジオデータベースのフィーチャクラス Addresses を作成します。フィーチャクラスは調整されたスキーマ（Export Features ツールのフィールドマップコントロール参照）を持ち、主キーとして House_Number_ID フィールドに NOT NULL 制約とインデックスが設定されており、アップサートトランザクションに必要な要件を満たしています。
住所データ作成モデル
ArcGIS Pro からフィーチャサービスを公開し、一部シンボロジーやポップアップ動作を適用し、House_Number_ID にユニークインデックスがあることも確認しました。これでサービス維持用ノートブックの準備が整いました。
ブログダウンロード内のノートブックコードをご覧いただくとして、処理手順は以下の通りです：
- DuckDB を使ってオープンデータサイトのダウンロード URL からソース CSV ファイルを読み込む
- 読み込み時にスキーマを強制し、メモリ内リレーション（テーブル）でジオメトリを作成する
- ArcPy を使い DuckDB リレーション内のデータからメモリフィーチャクラスを作成する
- Merge ツールで既存と新規住所データを別のメモリフィーチャクラスに統合
- ここには古いレコードと新しいレコード両方が含まれる
- Find Identical を使いジオメトリおよび全フィールドにわたる統合データ内の同一シーケンスを検出する
- Web Mercator 座標系なので座標精度差異対応に 1m の許容誤差設定
- Frequency を実行し、一意な行（編集対象で同一マッチなし）を特定する支援を行う
- 集合演算でアップサートおよび削除レコードを決定する
- Append と Delete Rows 関数で正しいレコードに対して処理を実行する
ノートブックセルメッセージを見ると全体処理時間は9分半かかっています（かなり大きなデータがノートブックに読み込まれジオプロセスされています）が、実際の書き込みコミットは少量で数秒しかかかっていません。私としてはかなり良好な結果だと思います。
平日の朝にスケジュール処理設定後は継続的に維持される情報製品となりました！
ご意見やご質問があればぜひこの投稿にコメントしてください。
