open-map-stack

OpenMapStack Toolkit

オープンを優先するスタックと、グローバル規模、レイテンシー、SLA、またはデータ品質の要件からローカル処理が適さない場合の実用的なホスト型／SaaSの選択肢を組み合わせた、本番環境向けの地理空間ワークフローです。デフォルトでクラウドネイティブです。データの探索にはSTAC、保存にはGeoParquet + COG + PMTiles、計算にはDuckDBとPostGIS、配信にはMapLibreとMartinを使用します。

主なスキルを選ぶ

関連するソース、計算、保存、配信の判断は、まとめて行います。主なスキルを1つ選び、タスクで必要な場合に限り、対象を絞った支援スキルを使います。

リクエスト	インストール済みの場合に選ぶ主なスキル
未解決のアーキテクチャ、変化する規模やチームのニーズ、またはエンドツーエンドのGIS分析	open-map-stack
選択したワークフローに基づく、再現可能なプロジェクトの構築または保守	reproducible-gis-project
Portolanカタログを含む、既知の要件に基づいたデータの検索と評価	geospatial-data-discovery
選択済みのエンジンでの空間SQLの作成／レビュー／デバッグ	spatial-sql

専門スキルがない場合は、範囲を限定したタスクに、このスキルのローカルリファレンスを使用してください。インストールを必須としたり、すべてのスキルを有効にしたりしないでください。一般的なスキルのみがインストールされている場合も、重要な分析では以下の完全なプロジェクト契約を維持します。製品固有のヘルプについてはreferences/companion-skills.mdを参照してください。OpenMapStackは、GISのセマンティクスと各段階を横断した正確性を担います。

再現可能なプロジェクトファーストの契約

複数段階にわたる重要な GIS 分析では、納品前に決定論的で、検査可能かつ再現可能な技術プロジェクトをコンパイルするか、維持してください。地図、ダッシュボード、レポートはそのプロジェクトのビューであり、分析の正規の定義ではありません。

重要な分析をコンパイルまたは納品する前に、必須のワークフローと納品ルールについては references/project-workflow.md を、openmapstack-project/v1 スキーマ全体については references/project-spec.md を読んでください。 templates/ と、完成例である examples/tartu-development プロジェクトを使用してください。 CLI のインストール方法と、例の実行時要件については、 references/installation.md を読んでください。

信頼できるソースは実在し、変更されず、バージョンが固定されているものを使用してください。明示的なインフォームド・コンセントなしに、ベースラインのジオメトリを決して捏造しないでください。仮定とすべての手動修正は、データまたは正規のパイプラインロジックとして記録し、オーバーライドは実行可能かつ検証済みのものにし、不明なセマンティック属性は不明のまま保持してください。プロジェクトには、明示的な CRS、決定論的で順序付けされたステップ、機械可読な検証および実行エビデンス、プロヴェナンス、チャットに依存しない、文書化されたクリーンな再実行手順が必要です。CLI がインストールされているか確認してください（openmapstack --version または python3 -m openmapstack --version を実行し、動作する形式を以下のすべてのコマンドで使用してください）。インストールされている場合は、openmapstack validate と正規の openmapstack run の手順を実行し、その後 openmapstack verify project.yaml --rerun を実行してください。これは宣言された入力から空のワークスペースにプロジェクトを再構築します。 この verify --rerun を最後のステップとし、合格するまで納品しないでください。validate だけに合格しても不十分です。正規のパイプラインでは、data/derived 以下のすべてのファイル、選択したすべての納品物、実行記録、マニフェストの runs.latest および project.status を生成しなければなりません。単発のスクリプトや手動編集で生成してはいけません。再実行では新しい実行記録が書き込まれるため、ポインターを手動で修正すると再実行が壊れます。検証機能がない場合は、暗黙に合格とせず not_testable としてください。パイプラインの結果から、永続的な Markdown の所見を生成してください。選択した出力先については、参照先のワークフローに記載されたプレゼンテーション要件に従ってください。 実際の作成者とツールキットを明記し、納品するすべてのビューに、正規の実行時刻を記載したリンク付きクレジットを表示してください（ワークフローのクレジット要件を参照）。必須の帰属表示の文面も確認してください。フィールドチェックでは、その意味が適切かどうかまでは証明できません。 新規プロジェクトでは delivery.schema: openmapstack-delivery/v1 を記録し、組み込みのダッシュボードをデフォルトにしてください。明示的な外部のみ、または組み合わせた納品形式を尊重してください。QGIS と Observable は任意の出力先です。delivery のない既存のマニフェストは、明示的に移行されるまで従来の v1 の動作を維持します。ソースのプロヴェナンス、GIS の正確性、クリーンな再実行は、どの選択肢でも必須です。

ダッシュボードのベースマップでは、ユーザーの選択と適切なローカルまたは地域のサービスを優先してください。それ以外の場合は、references/web-delivery.md に記載された事前設定済みの goplex.ee Protomaps フォールバックを使用し、ライト／ダークの切り替えと、提供元のクレジットを見やすく表示してください。

範囲が限定された一度限りの SQL、CRS、または変換に関する質問では、該当するドメインのリファレンスだけで十分です。プロジェクト全体の成果物や方法論は必要ありません。

ユーザーのスタックに dlt、Dagster、dbt、QGIS、または Observable が含まれる場合は、所有権と統合の境界について references/established-stack.md を読んでください。 ユーザーが選択したツールを維持し、ソースのバージョン固定、GIS の正確性、再現可能なエビデンスを保ってください。SQL、データ取り込み、またはスケジューラーの定義を重複して作成しないでください。

モジュール — 作業を始める前に関連するリファレンスを確認してください

タスクの内容	確認するもの
データの検索または取得（OSM、Overture、Sentinel、Landsat、建物フットプリント、地域ポータル、STAC および Portolan カタログ、MCP ベースの検索）	references/data-sources.md
ユーザー自身のウェアハウスまたはデータベースの読み取り（PostGIS、BigQuery、MotherDuck、DuckDB、GeoParquet ディレクトリ）：参照による認証情報、読み取り専用の検索、承認済みスナップショット、ピンのクラス	references/user-data-sources.md
グローバルまたは大陸規模でのローカル処理とオンライン／ホスト型／SaaS サービスの選択、ベースマップ、標高、ルーティング、ジオコーディング、場所検索、郵便番号検索 API	references/services-and-scale.md
形式の選択、形式間の変換、または CRS／投影／EPSG に関する質問	references/formats-and-crs.md
再現可能な GIS プロジェクト成果物のコンパイル（project.yaml、パイプライン、オーバーライド、検証、プレゼンテーション）	references/project-spec.md + templates/
GDAL/OGR、GeoPandas、xarray、DuckDB、PostGIS、または PDAL の実行 — 実際の処理	references/processing.md
DuckDB Spatial、PostGIS、BigQuery GIS、Snowflake、または Sedona での空間 SQL／GeoSQL の作成またはレビュー	references/spatial-sql.md
ベクター解析、ラスタ解析、地形／水文学、ネットワーク解析、点群ワークフロー	references/analytics.md
タイル生成（PMTiles、MVT）、タイルサーバー（Martin、TiTiler）、配信用レンダリング（MapLibre、deck.gl）、または探索用レンダリング（kepler.gl、lonboard）	references/web-delivery.md
プロジェクトのダッシュボードまたはレポートページの設計：アーキタイプ、コンポーネント、トークン、チェックで使用する状態フック	references/design-language.md
QGIS デスクトップ、QGIS プラグインのエコシステム、QGIS MCP、PyQGIS スクリプト、Processing ツールボックス	references/qgis.md
再現性、検証、ライセンスの帰属表示、タイルのスモークテスト、デプロイのチェック	references/validation-and-ops.md

単純な単発の質問（CRS 変換 1 回、ogr2ogr の呼び出し 1 回）では、関連するリファレンスだけで十分です。プロジェクト成果物全体を作成する必要はありません。複数段階のパイプラインでは、data-sources.md と processing.md をあわせて読み、分析を再実行可能なプロジェクトにまとめるために project-spec.md + templates/ を確認してください。「生データからウェブマップまで」のエンドツーエンドのタスクでは、web-delivery.md も確認してください。

グローバルな既定値 — ユーザーから別途指定がない限り適用

• 保存形式： GeoParquet（ベクター解析）、COG（ラスター）、PMTiles（タイル配信）、GeoPackage（デスクトップでのデータ交換）。新しい出力形式としてShapefileを生成しないでください。
• CRS： 保存にはWGS84（EPSG:4326）、ウェブでの描画にはWeb Mercator（EPSG:3857）、距離・面積・バッファーなどの計算にはローカルの投影CRSを使用してください。エストニアではEPSG:3301（L-EST97）を使用します。 DuckDBのGIS座標x/yに対するST_Transformでは、always_xy := trueを指定してください。納品前に、変換後のフィーチャーを元データおよび既知の場所と照合してください。正しいCRSラベルが付いていても、座標が正しいとは限りません。references/formats-and-crs.mdを参照してください。
• 座標の順序： CRSから推測するのではなく、インターフェースの契約として扱ってください。内部ではGISのx,y（地理座標の場合はlon,lat）を優先しますが、外部形式やAPIごとの契約に従ってください。GeoJSON、MapLibreのLngLatLike、OpenLayersの地理座標配列ではlon,latを使用し、LeafletのLatLngとGoogle MapsのLatLngではlat,lngを使用します。EPSG:4326だけを根拠にタプルの順序を推測しないでください。references/formats-and-crs.mdを参照してください。
• レイヤーの配置： 対象エリア（project.aoi）を宣言し、データ読み込み後および再投影のたびに、すべてのローカルレイヤーがその範囲内にあることを確認してください。都市や国のAOIから大きく外れたレイヤーは、軸の入れ替わり、誤ったCRSラベル、または誤ったエリアフィルターの兆候です。報告し、ソースに基づく根拠がある場合にのみ修正してください。
• 計算の配置： 空間結合と集計はPythonのループではなく、DuckDBまたはPostGISで実行してください。大規模な処理ではR-tree／GIST／空間インデックスが必須です。
• まずデータを探す： ダウンロードする前にSTACカタログ（Microsoft Planetary Computer、Earth Search、Overture STAC）を確認してください。odc-stacまたはstackstacを使って遅延読み込みし、必要なものだけを実体化してください。
• クラウドネイティブなアクセス： ダウンロードするよりも、リモートのGeoParquet／COGに対するクエリを優先してください。OvertureなどのS3ホスト型データセットでは、httpfs拡張機能を使用したDuckDBが既定のパターンです。
• まずスケールを考慮： 都市や州の処理にはローカルツールで問題ありません。大陸規模や全球規模では、ローカルのバッチ処理より信頼性が高い場合、クラウドネイティブなパーティション分割済みデータセット、事前計算済みタイル、ホスト型API、またはSaaSを優先してください。
• ライセンスの管理： あらゆる変換でライセンスメタデータを保持してください。OSMはODbL（継承的に同じライセンスで共有）、Overtureのライセンスはソースによって異なり、Sentinelはクレジット表記付きで無償、各国のデータはさまざまです。
• ランタイムの管理： GDAL／PROJ／GEOS／QGISのスタックには、conda-forge環境またはコンテナを優先してください。プロジェクトですでに動作実績が確認されている場合を除き、pipのみの地理空間環境は避けてください。

形式の選択基準

用途	形式
ベクターのクラウド解析	GeoParquet
HTTP経由のストリーミングベクター	FlatGeobuf
デスクトップでのデータ交換	GeoPackage
ウェブマップのベクタータイル	PMTiles（MVTを格納）
ラスターのアーカイブ／配信	COG
n次元ラスター（時系列、気候）	ZarrまたはNetCDF
点群アーカイブ	COPC（クラウド最適化LAZ）
APIレスポンスのペイロード（小規模なものに限る）	GeoJSON
レガシー互換性（入力のみ）	Shapefile

計算方法の選択基準

規模／状況	使用するもの
5,000万未満のフィーチャー、単一マシン、アドホックな処理	DuckDB Spatial
マルチユーザー、ウェブアプリのバックエンド、OLTP	PostGIS
1億を超えるフィーチャー、分散処理	Apache Sedona
大陸規模／全球規模の検索・探索・ルーティング・標高データ	カバレッジ、SLA、利用規約、価格が要件に合うホスト型APIまたはSaaS
地球規模のベースマップ配信	構築済みPMTiles／ベクタータイル、またはマネージド型ベースマップサービス
n次元ラスター、遅延読み込み／daskバックエンド	xarray + rioxarray（+ STAC取り込み用のodc-stac）
ラスターのCLIバッチジョブ	GDALユーティリティ（gdalwarp、gdal_translate -of COG）
点群	PDALパイプライン
gdaldemの範囲を超える地形・水文学処理	WhiteboxToolsまたはGRASS
デスクトップでのスタイリング、地図制作、アドホックな探索	QGIS（qgis.mdを参照）

一般的なアンチパターン — 指摘して修正する

• ユーザーが合成モックテストについて明示的かつ十分な情報に基づいて同意している場合を除き、実際のソースデータを取得せずに、モックの座標やジオメトリを捏造または生成する
• 共有プレゼンテーションレイヤーと一致しない、ベースマップが欠落している、または不正な OGR データソース構文（layername= を付けずに path.gpkg|layer と指定）を使った選択済み QGIS プロジェクトを生成し、レイヤーが空間データのない属性テーブルとして読み込まれる
• <srs> がない、認証 ID のみの CRS ブロックになっている、または ProjectionsEnabled がない .qgs XML を手書きする、あるいはマニフェストのレイヤー順をそのままレイヤーツリーにコピーする — これらは、すべてのレイヤーが有効で、すべてのデータソースが解決されるにもかかわらず、地図に誤った場所が表示されたり、レイヤーが気づかれないまま非表示になったりするプロジェクトを生みます
• 新しい出力形式として Shapefile を生成する（列の切り詰め、2GB の上限、UTF-8 非対応、複数ファイル）
• 地理座標系（EPSG:4326）で .distance()、.buffer()、.area を呼び出す — 度はメートルではありません。ただし、ツールが WGS84 に基づく測地計算を明示的にサポートする場合を除きます
• Web メルカトル（EPSG:3857）の座標を、歪みのない地上計測値として扱う — 座標の単位はメートルですが、地上距離と面積の歪みは緯度によって異なります
• DuckDB、PostGIS、または R-tree ベースの sjoin を使えば一行で済むのに、Python のループで空間結合を行う
• フィーチャーが境界をまたぐ可能性がある面積クエリで、bbox の包含判定を使う — スキャンの絞り込みには bbox の重なりを使い、その後に正確な空間述語を適用します
• STAC とクラウドネイティブ形式を使えば遅延アクセスや範囲リクエストが可能なのに、データセット全体をダウンロードする
• 信頼できるホスト型サービスや事前計算済みの全球データがすでにある検索・照会の問題に対して、惑星規模のローカル処理を実行する
• 新しいウェブ配信のデフォルトとして MBTiles を使う — 現代のデフォルトは PMTiles です
• -of COG のフラグ一つで済むのに、GeoTIFF を使う
• CRS の不一致を黙って許容する — すべての結合で CRS が一致することを検証する必要があります
• Docker pull 一回で OSRM、Valhalla、または Nominatim を利用できるのに、ルーティングやジオコーディングを独自実装する
• 再現可能なパイプラインでデータを「latest」に固定する — コレクションだけでなく、Overture のリリースバージョンと STAC アイテム ID を固定します。Overture では、固定したリリースが引き続き利用可能であることを確認するか、ミラーを作成してください。

クイックトリアージ — リクエストの種類を見分ける

タスクに取りかかる前に、種類を分類します。

1. データの探索（「…のデータはありますか？」「…のデータセットはありますか？」「このカタログを読んで」）→ data-sources.md から始めます。ラスターデータなら STAC 検索、ベクターのベースマップなら Overture または OSM を使います。Portolan カタログの場合は、クエリを実行する前にその AGENTS.md を読んでください。
2. 変換／CRS（「これを…に変換して」「…に再投影して」「投影がおかしい」）→ formats-and-crs.md。通常は ogr2ogr または gdalwarp を一回実行すれば済みます。
3. 分析（「…の平均標高は？」「…から500m以内の建物はいくつ？」「ホットスポットはどこ？」）→ analytics.md と、おそらく processing.md。まず DuckDB／PostGIS で処理します。
4. 配信（「これをウェブマップとして公開して」「…のタイルを生成して」）→ web-delivery.md。デフォルトは PMTiles + Martin + MapLibre です。
5. デスクトップ／地図制作（「QGIS でこれにスタイルを設定して」「印刷用地図を作成して」「QGIS でこれを自動化して」）→ qgis.md。エージェント型ワークフローでは QGIS MCP を検討してください。

実際のタスクの多くは、これらのうち2～3種類にまたがります — 関連するリファレンスを順に読んでください。

作成するあらゆるパイプラインの再現性チェックリスト

• データセットのバージョン（Overture のリリース、STAC アイテム ID、OSM の抽出日）を固定します — 「latest」は使いません
• 各段階で CRS を記録します。推測してはいけません
• conda-forge 環境またはバージョンを固定したコンテナイメージ（GDAL には ghcr.io/osgeo/gdal:alpine-small-latest、PyQGIS には qgis/qgis:<tag>）を使います。pip のみの地理空間環境は頻繁に壊れます
• 出力を検証します。GeoParquet には gpq、COG には rio-cogeo validate、PMTiles には pmtiles show、ジオメトリには is_valid を使います
• ライセンスのメタデータを列またはサイドカー JSON に保持し、必要な帰属表示を地図／API に引き継ぎます

これらの各項目のコマンドレベルの詳細は references/validation-and-ops.md にあります。