geo-data-engineering

地理空間データエンジニアリング

目的: 空間データをクリーンで検証済み、分析可能な状態に、再現可能なパイプラインで持っていくこと — 現実の GIS で最も多くの時間が費やされ、最も多くのサイレントエラーが生まれる段階です。

フォーマットの選択

フォーマット	用途	避ける理由
GeoParquet	分析用の受け渡し、大規模ベクター、列指向ワークフロー	一部のレガシーなデスクトップ GIS ではまだ読み込めない
GeoPackage	デスクトップ GIS の交換、マルチレイヤープロジェクト	大規模では Parquet より遅い; SQLite のロック
FlatGeobuf	ストリーミング、HTTP レンジリード	単一レイヤー
COG (Cloud-Optimized GeoTIFF)	すべてのラスタ成果物	— (すべての GeoTIFF を COG にしましょう)
Zarr/NetCDF	多次元 (時間 × バンド × y × x)	単一ラスタには過剰
Shapefile	レガシーツールが要求する場合のみ	10 文字のカラム、2 GB の上限、エンコーディングの混沌、マルチファイルの脆さ
CSV + WKT/経度緯度	シンプルなポイントの交換	CRS メタデータがない — 明示的に文書化しましょう

取得のプレイブック

• OpenStreetMap: 小規模エリア → osmnx; 大規模抽出 → Geofabrik PBF + pyrosm/osmium。タグの異質性を尊重しましょう: フィルタリングの前に必ずタグ値の 分布を確認してください。
• 大規模な建物/場所: Overture Maps (S3/Azure 上の GeoParquet、 DuckDB spatial でクエリ — 多くの場合最速の手段)。
• 衛星/ラスタ: pystac-client + odc-stac 経由の STAC API — remote-sensing-analysis を参照; 惑星規模のアーカイブ → google-earth-engine。
• 境界: まず権威ある国家ソース; グローバルな作業には Natural Earth / GADM / geoBoundaries — どれを使ったかを記録してください。バージョンによって大きく異なります。
• すべての取得を記録しましょう: ソース URL、クエリパラメータ、取得日、 ライセンス。データの隣の DATA_SOURCES.md に記載してください。

CRS エンジニアリング

• EPSG:4326 またはソース CRS で保存し、分析は範囲に適した投影 CRS で行います: ローカルの UTM ゾーン (gdf.estimate_utm_crs())、国家グリッド、または 地域横断の面積統計には等積投影 (EPSG:6933/Mollweide)。
• サブメートル精度ではデータムのずれが重要です: データム間の変換には 適切な変換グリッドが必要です (精度が重要な場合は pyproj.network.set_network_enabled(True))。
• ずれたレイヤーを「修正」するために CRS を削除したり上書きしたりしないでください — 代わりに既知のランドマークを使ってどのレイヤーが間違っているかを診断しましょう。

クレンジングパイプライン

標準のハイジーンパスとして scripts/clean_vector.py を実行します (またはその clean_vector() 関数をインポートします): 空/null ジオメトリを削除し、無効なものを make_valid で修復し、重複を排除し、再投影し、そして集計レポートを出力するので、 サイレントなデータ損失は起こりえません。

次に: テキスト属性を正規化し (トリム、空白の圧縮、ロケール対応の ケースフォールド — トルコ語の İ/ı、ドイツ語の ß に注意)、dtype を明示的に 強制変換し、後でフィルタリングに使うすべてのカテゴリの value_counts() を表示します。

スケール戦略

• RAM に収まる: GeoPandas + Shapely 2 のベクトル化演算。空間 インデックスが使われることを確認しましょう (sjoin、query_bulk) — 手書きのループは O(n²) です。
• RAM より大きい、単一マシン: GeoParquet 上の DuckDB spatial 拡張 (述語プッシュダウン + 空間 SQL)、または dask-geopandas。
• 配信 / 同時実行 / トランザクション: PostGIS — postgis-spatial-sql を参照。
• ラスタ: ウィンドウ読み込み (rasterio.windows)、チャンク化された xarray + dask; 50 GB のモザイクを決して read() でメモリに読み込まないでください。

パイプライン標準

• ディスク上の明示的な入力/出力を持つ冪等なステップ; 再実行しても 状態を破壊しません。
• 高コストな段階 (ダウンロード、大きな結合) の後は GeoParquet/GPKG で チェックポイントします。
• 各段階ごとに集計行をログに記録します: 行/フィーチャ/ピクセルの入力 → 出力。
• 書き込み前の決定的な順序付け (安定したキーでソート) により、差分が 意味を持ちます。

落とし穴チェックリスト

• lon/lat 列の CRS を宣言せずに CSV を開いてしまった。
• エクスポート時に Shapefile の列名が黙って切り詰められた。
• レガシーファイルによる文字エンコーディングの文字化け（encoding="utf-8" を試し、次に cp1252 を試してください）。
• 1 つのレイヤーに混在するジオメトリタイプ（Polygon + MultiPolygon は一部の ツールを壊します — .explode() で正規化するか、Multi* に昇格させてください）。
• 単純な再投影後の対蹠線および極をまたぐジオメトリ。
• 記録されたバージョン/日付がない「最新」データのダウンロード — 再現不可能。

実行契約

• ワークフロー: ソースと契約を棚卸しし、来歴付きで取得し、CRS、スキーマ、ジオメトリ、スケールを検査し、決定論的にクリーンアップし、検証し、分析可能な成果物を書き出します。
• 判断ルール: サイズ、ジオメトリ、並行性、下流のアクセス要件からフォーマットとエンジンを選択します。CRS や破壊的な修復を暗黙に推測してはいけません。
• 検証プロトコル: 各段階でフィーチャ数またはピクセル数を突き合わせ、CRS とジオメトリの不変条件をアサートし、出力を空間的にサンプリングし、再実行して冪等性を確認します。
• 失敗モード: 推測するのではなく、曖昧な CRS、混在する単位、無効なエンコーディング、損失のあるフォーマット変換、または説明のつかない行欠落を隔離します。
• 成果物: 検証済みデータセット、機械可読なスキーマと CRS、来歴マニフェスト、会計ログ、拒否レコードレポート、再現可能なパイプライン。
• ソースの鮮度: バージョンに敏感なフォーマットや API を使用する前に権威あるソースレジストリを参照し、確認日を記録してください。