WebGISと数値シミュレーションをどうつないでデータ基盤をつくるのかー基本設計

Last updated at 2026-09-17Posted at 2026-09-15

WebGISと数値シミュレーションをどうつないでデータ基盤をつくるのかー基本設計

はじめに

WebGISを作っていると、最初は地図を表示したり、データを編集したりするところから始まります。

そこから少しずつ、

バッファ処理をしたい
空間検索をしたい
ラスタ処理をしたい
数値シミュレーションを動かしたい
条件を変えて何ケースも比較したい
計算結果を地図に戻したい
過去の計算条件を再現したい

と、やりたいことが増えてきます。

個別の機能として追加していくこともできますが、ある程度まで進むと、WebGIS、数値計算、実験管理を別々に考えるより、共通の基盤として整理した方が扱いやすくなります。

今回は、特定のシミュレーションモデルには依存せず、

WebGIS × Simulation × Experiment

をAPIでつなぐ場合に、どのような構成が扱いやすいかを整理してみます。
前回の記事をもう少し拡張して考えてみます。

1. 最初から全部を一体化しない

WebGISとシミュレーションは一緒に使いたくなりますが、役割はかなり違います。

WebGIS側では、

データを見る
データを編集する
属性を変更する
GIS処理を行う
結果を地図に表示する

といった処理が中心です。

一方、シミュレーション側では、

入力条件を作る
計算条件を設定する
ジョブを投入する
計算を実行する
結果を保存する

という処理が中心になります。

さらに、解析を続けていると、

条件Aで計算
条件Bで計算
条件Cで計算
結果を比較
感度を見る
一番良い条件を探す

といった「実験」の管理も必要になります。

そのため、最初から1つの大きなアプリケーションとして作るのではなく、

のように役割を分けておきます。

それぞれは独立して動かせる。

ただし、

Workspace
Dataset
Experiment
Run
Job
Result
API

といった共通概念は同じ基盤で扱う。

このくらいの距離感が、後から拡張しやすいと考えています。

2. 基本はAPI経由にする

システム全体で一番重要にしたいのが、APIをそれぞれのlayerの境界にすることです。

ブラウザから直接データベースへ接続したり、シミュレーションプログラムを直接起動したりするのではなく、必ずAPIを通します。

全体像は次のようになります。

この形にしておけば、Web画面を作り直してもAPIはそのまま使えます。

別のWebアプリ、CLI、バッチ処理、将来的にはAIエージェントから同じAPIを利用することもできます。

3. 「データ」を共通のリソースとして扱う

WebGISとシミュレーションをつなぐときに、まず問題になりやすいのがデータの扱いです。

例えば、

GeoJSON
FlatGeobuf
GeoTIFF
CSV
Parquet
メッシュ
時系列データ

など、形式はどんどん増えていきます。

そこで、ファイル形式そのものではなく、まず「Dataset」という共通概念を作ります。

Dataset
 ├─ Vector
 ├─ Raster
 ├─ TimeSeries
 ├─ Table
 ├─ Mesh
 └─ Network

実際のファイルがGeoTIFFやCSVでも、システム上ではDatasetとして扱います。

APIでは巨大なファイルを毎回サービス間で受け渡すのではなく、

{
  "dataset_id": "ds_00125"
}

のようにIDで参照します。

実データはPostGISやObject Storageに置きます。

この形にしておくと、保存場所がローカルディスクからS3互換ストレージへ変わっても、上位のアプリケーションを大きく変更せずに済みます。

4. Experimentを最初から共通概念に入れる

シミュレーションでは、「1回計算して終わり」というケースは意外と少ないです。

実際には、

パラメータを変える
境界条件を変える
入力データを変える
モデルを変える
結果を比較する

という作業を何度も繰り返します。

そこで、Caseを大量に作るのではなく、まとまりをExperimentとして管理します。

基本的な関係は次のようにします。

Workspace
  │
  ├─ Dataset
  │
  └─ Experiment
       │
       ├─ Run 001
       │    ├─ Parameters
       │    ├─ Job
       │    ├─ Metrics
       │    └─ Artifacts
       │
       ├─ Run 002
       │    ├─ Parameters
       │    ├─ Job
       │    ├─ Metrics
       │    └─ Artifacts
       │
       └─ Run ...

例えば「粗度係数を変えたときの結果比較」や「降雨倍率を変えた感度分析」は、1つのExperimentの中に複数Runを作る形です。

これだけで、解析履歴がかなり整理しやすくなります。

5. RunとJobは分ける

ここは少し細かい話ですが、長く使うシステムでは重要になります。

Runは、

この条件で行った1回の解析

という意味です。

Jobは、

実際にWorkerへ投入した計算処理

という意味にします。

例えば、

Run 012
 ├─ Job 051 : FAILED
 └─ Job 052 : SUCCESS

ということがありえます。

計算条件は同じですが、途中でWorkerが落ちたため再実行したケースです。

RunとJobを同じものにしてしまうと、こうした再実行履歴が分かりにくくなります。

そのため、

Experiment
   ↓
Run
   ↓
Job
   ↓
Result

と分けておく方が後で扱いやすくなります。

6. JobはGIS処理とシミュレーションで共通化する

Jobはシミュレーションだけでなく、WebGISでも使います。

例えば、

バッファ
空間結合
ラスタ変換
統計処理
タイル生成

などは、データ量が増えると非同期処理にしたくなります。

そこでJobを共通モデルにします。

Job
 ├─ GIS Processing
 │    ├─ Buffer
 │    ├─ Spatial Join
 │    └─ Raster Processing
 │
 └─ Simulation
      ├─ Model A
      ├─ Model B
      └─ Model C

Jobには例えば次の情報を持たせます。

job_id
job_type
status
progress
created_at
started_at
finished_at
error_message
input
output

この形なら、GIS処理やシミュレーションでも同じ進捗画面を使えます。

7. 実験計画を使ってRunを自動生成する

Experimentを作ると、次に欲しくなるのがRunの自動生成です。

例えば、

parameter_a = 0.1, 0.2, 0.3
parameter_b = 10, 20, 30

を全組み合わせで計算するなら、

3 × 3 = 9 Runs

を自動で作れます。

概念的には次の流れです。

最初から高度な最適化を入れる必要はありません。

まずは、

Manual
Grid
Random
One-at-a-Time

くらいでも十分です。

その後、

Latin Hypercube
Sobol Sampling
Sensitivity Analysis
Optimization
Calibration

へ広げていけばよいと思います。

8. 個別分野のロジックはPluginへ閉じ込める

今回の構成では、シミュレーションモデルだけでなく、個別分野に依存する処理はできるだけPluginとしてPlatform Coreから切り離す方針にします。

理由は単純で、分野ごとの処理をPlatform本体へ直接書き込んでいくと、

Model Aを追加
   ↓
Platform Coreを修正

Model Bを追加
   ↓
またPlatform Coreを修正

新しい入力形式を追加
   ↓
さらにPlatform Coreを修正

という形になり、機能追加のたびにシステム全体への影響範囲が広がってしまうからです。

そのため、Platform Coreはできるだけ、

Workspace
Dataset
Experiment
Run
Job
Result
Plugin Registry

といった共通概念だけを管理します。

一方で、個別分野に依存する処理はPlugin側へ持たせます。

Platform Plugin System
│
├─ Data Plugins
│   ├─ Data Builder
│   ├─ Data Importer
│   ├─ Data Converter
│   └─ Validator
│
├─ Simulation Plugins
│   ├─ Solver
│   ├─ Preprocessor
│   └─ Postprocessor
│
├─ Experiment Plugins
│   ├─ Experiment Design
│   ├─ Sampler
│   └─ Run Generator
│
└─ Analysis Plugins
    ├─ Metric Extractor
    ├─ Sensitivity Analysis
    ├─ Calibration
    └─ Optimization

この形にしておけば、新しい分野を追加するときも、Platform Coreを大きく変更せずに済みます。

Data BuilderもPluginとして扱う

シミュレーションごとに必要な入力データはかなり違います。

例えば、

1D河川モデル
  ├─ 河道Network
  ├─ 横断形状
  ├─ 境界条件
  └─ 初期条件

に対して、

2Dモデル
  ├─ DEM
  ├─ 計算領域
  ├─ Mesh
  ├─ 粗度
  └─ 境界条件

のように、必要なデータ構造が変わります。

さらに別のモデルでは、物性値や発生源条件などが必要になるかもしれません。

こうした入力データ作成処理をPlatform本体へ直接実装するのではなく、

Data Builder Plugin
        ↓
Dataset

という形にします。

例えば、

River Data Builder
Flood Data Builder
Rainfall Data Builder
Terrain Data Builder
Material Data Builder

といったPluginを追加できるようにします。

Data Builder Pluginには、例えば次のような役割を持たせます。

入力データ作成
入力データ変換
入力データ編集
Validation
Pre-processing
Dataset登録

ローカルツールやQGIS等で作成したデータも、

Local Tool / QGIS
      ↓
Data Builder / Importer Plugin
      ↓
Validation
      ↓
Dataset API
      ↓
Platform Dataset

と考えれば、Platformの外側に完全に切り離す必要はありません。

SolverとData Builderを1対1にしない

Data Builderは必ずしもSolver専用にする必要はありません。

例えば、

Terrain Builder
Rainfall Builder
River Network Builder
Boundary Builder

のような共通Builderは、複数のSolverから利用できます。

そのため、

Solver
   ↓
Required Dataset Types
   ↓
Compatible Data Builder Plugins

という関係にします。

例えば、

solver: model_b

required_datasets:
  - terrain
  - rainfall
  - boundary

という定義に対して、

terrain
  ├─ GeoTIFF Import Builder
  ├─ DEM Processing Builder
  └─ WebGIS Terrain Builder

のように、同じDataset Typeを複数の方法で作成できるようにします。

これにより、

Platformは「何が必要か」を知る
Pluginは「どう作るか」を知る

という責務分担ができます。

Plugin Registryで一元管理する

Pluginが増えてきたら、Platform側ではPlugin Registryを持たせます。

Plugin Registry
   │
   ├─ Data Builder Plugins
   ├─ Solver Plugins
   ├─ Experiment Plugins
   └─ Analysis Plugins

Plugin Registryでは、例えば次の情報を管理します。

plugin_id
plugin_type
name
version
supported_dataset_types
input_schema
output_schema
capabilities
enabled

Web UIはPlugin Registryを参照して、

利用可能なData Builder
利用可能なSolver
利用可能なExperiment Design
利用可能なAnalysis

を動的に表示できます。

こうすると、Plugin追加のたびにWeb画面へ個別ロジックを書き込む必要も減らせます。

Plugin化する目的

Plugin化そのものが目的ではありません。

一番重要なのは、

個別分野の変更を、システム全体の変更にしない

ことです。

例えば新しいSolverを追加しても、

Common Platform Core
WebGIS Platform
Experiment Platform
Job管理
認証
Storage
Monitoring

には基本的に影響を与えない。

Data Builderを追加しても、既存Solverには影響を与えない。

Metric Extractorを追加しても、Simulation実行系には影響を与えない。

このような構成を目指します。

つまり、今回のPlatformでは、

共通部分はCoreへ
個別分野のロジックはPluginへ

という境界を明確にしておくことが重要になります。

9. シミュレーションモデルはPluginとして扱う

シミュレーション側では、モデルごとに実装方法が違います。

Pythonで書かれているものもあれば、

Fortran
C++
外部実行ファイル
Dockerコンテナ
GPUプログラム

などもあります。

ここでPlatform側にモデル固有処理を書き始めると、モデルが増えるたびにシステム本体を変更する必要が出てきます。

そのため、シミュレーションモデルはPluginとして扱います。

Simulation Platform
        ↓
Solver Registry
        ↓
Solver Plugin
        ↓
Model A
Model B
Model C

Plugin側には最低限、

class SolverPlugin:

    def validate_input(self):
        ...

    def preprocess(self):
        ...

    def run(self):
        ...

    def postprocess(self):
        ...

    def outputs(self):
        ...

のような共通インターフェースを持たせます。

Platform側は、モデルの中身を細かく知る必要がありません。

「入力を渡して、実行して、結果を受け取る」

という部分だけを共通化します。

10. ResultだけでなくMetricsも持つ

数値シミュレーションの結果は、かなり大きくなることがあります。

例えば、

GeoTIFF
時系列CSV
メッシュ結果
ベクタデータ

などです。

Experimentで複数Runを比較するときに、毎回すべての結果ファイルを開くのは大変です。

そこで、Resultとは別にMetricsを持たせます。

例えば、

最大値
平均値
ピーク時刻
対象面積
誤差
処理時間

といった比較しやすい数値です。

流れとしては、

Simulation Result
      ↓
Metric Extractor
      ↓
Metrics
      ↓
Run Comparison

となります。

モデルごとにMetric Extractorを持たせておけば、同じExperiment画面でも比較できます。

11. MLflowの考え方は相性がいい

Experimentを管理する仕組みを考えると、MLflowのような

Experiment
  ↓
Run
  ├─ Parameters
  ├─ Metrics
  └─ Artifacts

という考え方はかなり参考になります。

ただし、システム全体をMLflow中心にする必要はないと思っています。

WebGIS側には、

Workspace
Layer
Feature
Raster
Geometry
権限

など、MLflowとは別の管理対象があります。

そのため、Platform側には独自のExperiment Serviceを持たせて、必要ならTracking BackendとしてMLflowを接続する形にします。

Experiment Service
       ↓
Experiment Tracking Adapter
       ↓
 ┌───────────────┐
 │ Built-in      │
 │ MLflow        │
 │ Other Backend │
 └───────────────┘

この形なら、MLflowを使う場合も使わない場合も、Platform全体の構造を変えずに済みます。

12. WebGISとSimulationはDatasetでつなぐ

最終的には、WebGISで作成したデータをそのままシミュレーション入力として使えるようにします。

WebGIS
  ↓
Dataset
  ↓
Experiment
  ↓
Run
  ↓
Simulation
  ↓
Result
  ↓
WebGIS Layer

もう少し具体的にすると、

ここまでつながると、利用者がファイルをダウンロードして別のソフトへ持っていく場面をかなり減らせます。

13. ブラウザだけで完結する構成にする

最終的には、利用者のPCへ専用の解析環境を入れなくても使える形を目指します。

利用者側はブラウザだけ。

サーバー側で、

GIS処理
数値計算
Experiment生成
データ保存
結果変換
Metrics算出
可視化データ生成

を行います。

この構成なら、利用者ごとの環境差を減らせます。

また、モデルやGISライブラリを更新する場合も、サーバー側だけで対応できます。

14. クラウドに依存しすぎない

もう1つ意識しているのが、特定クラウドへ依存しすぎないことです。

最初から、

AWS専用
Azure専用
GCP専用

として作ってしまうと、後から別環境へ移すのが大変になります。

そこでアプリケーション本体から見ると、

Database
Queue
Storage
Execution
Experiment Tracking

だけが見える構成にします。

実際の実装はAdapterで切り替えます。

15. Storageを切り替えられるようにする

例えばファイル保存なら、

StorageBackend
 ├─ Local Storage
 ├─ MinIO
 ├─ S3
 ├─ Azure Blob
 └─ Google Cloud Storage

のようにします。

アプリケーション側では、

storage.put(...)
storage.get(...)

だけを使います。

実際にどこへ保存するかは設定で変更します。

16. 計算環境も切り替えられるようにする

数値計算は、最初は1台のサーバーで十分でも、モデルが大きくなると計算環境を変えたくなります。

例えば、

ExecutionBackend
 ├─ Local
 ├─ Celery
 ├─ Docker
 ├─ Kubernetes
 ├─ Slurm
 └─ Cloud Batch

といった形です。

小さい計算はローカルWorker。

複数RunはCeleryで並列化。

大規模計算はHPC。

GPUが必要な計算はGPU Worker。

という切り替えができるようになります。

Experimentを扱う場合、Runを並列実行できる構成は特に重要になります。

17. Dockerを基本にする

環境差を小さくするため、各サービスはDockerで動かします。

例えば、

frontend
api
worker
redis
postgres
object-storage
tracking
nginx

といった構成です。

ローカルではDocker Composeを使います。

本番では必要に応じて、

Docker Compose
Kubernetes
各クラウドのコンテナサービス

へ移行できます。

18. 技術構成の例

特定の技術でなければいけないわけではありませんが、例えば次のような構成が考えられます。

分類	技術例
WebGIS	OpenLayers
API	FastAPI
Database	PostgreSQL + PostGIS
Queue	Redis
Worker	Celery
Vector配信	FlatGeobuf / GeoJSON
Raster	GeoTIFF / COG
GIS処理	GDAL / GeoPandas / Rasterio
Experiment Tracking	MLflow等
Object Storage	MinIO / S3互換Storage
Reverse Proxy	Nginx
Container	Docker / Docker Compose

できるだけ一般的なOSSを使い、クラウド固有機能はAdapterの後ろへ置く考え方です。

19. 将来的には最適化やキャリブレーションにもつなげられる

ExperimentとMetricsが共通化されると、その先に最適化があります。

例えば、

Parameter
   ↓
Run
   ↓
Simulation
   ↓
Metrics
   ↓
評価
   ↓
次のParameter

というループです。

これを使えば、

パラメータキャリブレーション
感度分析
最適条件探索
多目的最適化

などへ発展できます。

最初からここまで作る必要はありません。

ただ、Experiment / Run / Metricsを最初から分けておけば、後から追加しやすくなります。

20. AIとの連携もExperiment単位にすると分かりやすい

この構造にしておくと、AIから操作する場合も分かりやすくなります。

例えば、

「parameter_aを0.1〜0.5の範囲で感度分析して」

という指示に対して、

自然言語
  ↓
Experiment定義
  ↓
Parameter Space生成
  ↓
Run生成
  ↓
Job実行
  ↓
Metrics
  ↓
比較

という流れを作れます。

AIにSolverを直接操作させるより、

Experiment APIを操作させる

と考えた方が、安全性や再現性の面でも扱いやすいと思います。

21. 開発は段階的に進める

最初から最終形を作ろうとすると、かなり大きな開発になります。

そのため、段階的に進めます。

Step 1

まずWebGISを単独で動かす。現在最新版を作成中です。

地図表示
Feature編集
PostGIS保存
GIS処理
Job管理

ここまでを安定させます。

Step 2

次にシミュレーションを単独で動かす。現在最新版を作成中です。

入力
計算条件
Job投入
計算
結果保存

まず1つのモデルで完成させます。

Step 3

モデル部分をPlugin化する。

最初のモデルをPlatformから切り離します。

Step 4

Experiment / Runを追加する。

まずは手動でRunを作れる程度で構いません。

Experiment
 ├─ Run A
 ├─ Run B
 └─ Run C

この段階でParameters / Metrics / Artifactsを整理します。

Step 5

2つ目のモデルを追加する。

ここでは、高度なモデルを追加することより、

Platform本体を変更せず異種モデルを追加できるか

を確認することが重要です。

Step 6

実験計画を追加する。

Grid
Random
Parameter Sweep

などからRunを自動生成できるようにします。

Step 7

WebGISとSimulationをAPIで接続する。

WebGIS Dataset
      ↓
Experiment
      ↓
Simulation Run
      ↓
Simulation Result
      ↓
WebGIS Layer

という流れを作ります。

Step 8

必要に応じて大規模計算へ拡張する。

2D計算
Raster
GPU
HPC
Kubernetes
Cloud Batch

などは、この段階で追加します。

Step 9

最適化・キャリブレーションへ拡張する。

Experimentで蓄積したRunとMetricsを使って、

Parameter Search
Sensitivity Analysis
Calibration
Optimization

Step 10

プラグインの作成。

システムに追加するプラグインを検討してwebを使って、

Input Builder Plugin
Output Builder Plugin
Data Converter Plugin

へつなげます。

22. 最終的な構成

最終的には次のような形を目指します。

23. この構成でやりたいこと

最終的に目指しているのは、単なるWebGISでも、単なるシミュレーション画面でもありません。

ブラウザ上で、

ところまで一続きで行える環境です。

数値計算そのものも重要ですが、実際の解析では、

入力データを作る
条件を変える
何度も計算する
結果を比較する
過去ケースを確認する
再現する

という一連の作業にかなり時間がかかります。

そこをWeb上でつなげられると、単なる「計算をWeb化したシステム」とは違う価値が出てくると思います。

24. まとめ

今回の構成で特に重要なのは、次の点です。

API-first
Web-first
Docker-first
Cloud-agnostic
Plugin-based
Experiment-aware

WebGIS、Simulation、Experimentは別々の役割として持つ。

ただし、

Workspace
Dataset
Experiment
Run
Job
Result

は共通化する。

シミュレーションモデルはPluginとして追加する。

Storage、Execution、Experiment TrackingはAdapterで切り替える。

この形にしておけば、最初は小さなローカル環境でも始められます。

必要になった段階で、

オンプレミス
クラウド
Kubernetes
HPC
GPU

へ拡張できます。

まずは「1つのWebGIS」と「1つのシミュレーションモデル」をきちんと動かす。

その後、Experiment / Run / Metricsを追加して、複数ケースを比較できるようにする。

最初から完成形を作るより、この順番の方が現実的だと考えています。

次は、この構成をDocker Composeへ落として、

WebGIS、Simulation、Experiment Trackingをどの単位でサービス分割するか

を具体的に整理してみようと思います。

次回はサンプルイメージを作成してみようと考えています。

25. 今回参考にしたもの

すべてを一度に調査する必要はありません。

まずは次の8つを重点的に確認すると、今回のPlatform全体像を考えやすいと思います。

Tethys Platform
WebGISと科学計算をWebアプリ化する考え方
Delft-FEWS
外部SolverをAdapter経由で統合する考え方
OGC API - Processes
Process / Job / ResultをAPI化する考え方
OpenLayers
WebGISフロントエンド
PostgreSQL / PostGIS
地理空間データとPlatform Metadataの管理
Celery
非同期Job・並列Run実行
MLflow
Experiment / Run / Parameters / Metrics / Artifactsの考え方
STAC
地理空間DatasetをCatalogとして管理する考え方

参考にしたプロジェクト・仕様

今回の構成を考えるにあたって、WebGIS、数値シミュレーション、Experiment管理、非同期Job、地理空間データ管理など、近い考え方を持つ既存プロジェクトや仕様を参考にしています。

すべてをそのまま採用するというより、各プロジェクトの設計思想や役割分担を見ながら、今回のプラットフォームに合う部分を取り入れていく想定です。

Tethys Platform

地球科学・水文・GIS系のWebアプリケーションを構築するためのプラットフォームです。

今回の構成では特に、

WebGIS
科学計算
Spatial Data
Web Application
非同期処理
モデル実行

を1つのWeb基盤にまとめる考え方が参考になります。

今回作ろうとしているシステムとは目的が完全に同じではありませんが、

地理空間データと数値モデルをWeb上で扱う

という点ではかなり近い考え方です。

Delft-FEWS

洪水予測や水文・水理モデルを統合するためのシステムです。

特に参考になるのは、外部モデルをAdapter経由で接続する考え方です。

今回の構成でも、

Simulation Platform
        ↓
Solver Registry
        ↓
Solver Plugin
        ↓
Model A / Model B / Model C

という形を想定しています。

既存のPython、Fortran、C++、外部実行ファイルなどをPlatform本体へ直接組み込まず、共通インターフェース経由で接続する設計を考えるうえで参考になります。

OGC API - Processes

Web API経由で処理を実行するためのOGC標準です。

今回のシステムでは、

Job投入
↓
非同期実行
↓
状態確認
↓
Result取得

という流れを重要な共通機能として考えています。

OGC API - Processesには、Processの公開、Jobの生成、状態確認、Result取得といった考え方が含まれているため、Simulation APIやGIS Processing APIを設計するときの参考になります。

OGC API - Features

地理空間FeatureをWeb APIで扱うための標準です。

WebGIS側の、

Layer
Feature
Geometry
Attribute
空間検索

などをREST APIとして設計するときに参考になります。

OpenLayers

WebGISフロントエンドの中心として利用する想定です。

地図表示だけでなく、

Vector表示
Raster表示
Feature編集
Layer管理
WebGL
イベント処理

などをWebブラウザ上で実装できます。

今回の構成では、入力データの作成からSimulation Resultの可視化まで、同じWebGIS上で扱えるようにしたいと考えています。

PostgreSQL / PostGIS

Workspace、Dataset、Layer、Feature、Experiment、Run、Job、Resultなどのメタデータ管理と、地理空間データの正式保存先として利用する想定です。

特にPostGISは、

Geometry
Spatial Index
空間検索
空間演算

をDatabase側で扱えるため、WebGIS Platformの中心になります。

FlatGeobuf

https://flatgeobuf.org/

大量のVectorデータをWebへ配信する方法として参考にしています。

PostGISを正式な保存先としつつ、

PostGIS
   ↓
FlatGeobuf生成
   ↓
Web配信
   ↓
OpenLayers

という役割分担を考えています。

GDAL

https://gdal.org/

GISファイルやRasterデータを扱う基盤ライブラリです。

今回のシステムでは、

GeoTIFF
Vector変換
Raster変換
座標系変換
Simulation結果変換

などで利用することを想定しています。

GeoPandas

https://geopandas.org/

Python側でVector GIS処理を実装するときに利用しやすいライブラリです。

WebGISのバックエンド処理や、Simulation前後のPre/Post Processingで利用できます。

Rasterio

https://rasterio.readthedocs.io/

DEM、浸水深、流速、土地利用などのRasterデータをPythonから扱う場合に利用します。

2D Simulationへ進んだ段階で重要になるライブラリです。

STAC

https://stacspec.org/

地理空間データをCatalogとして管理・検索するための仕様です。

Datasetが増えてくると、

DEM
土地利用
降雨Raster
衛星データ
Simulation Result
GeoTIFF
時系列Raster

などを単なるファイル一覧では管理しにくくなります。

将来的にはDataset ServiceやObject Storageと組み合わせて、STACベースのCatalog管理も検討できます。

Cloud Optimized GeoTIFF

https://cogeo.org/

大きなRasterをWebやObject Storageから効率よく参照するための形式です。

Simulation Resultとして生成したRasterを、

Object Storage
      ↓
COG
      ↓
WebGIS

という形で表示する構成に向いています。

Xarray

https://docs.xarray.dev/

時間、標高、緯度、経度など、多次元データを扱うためのPythonライブラリです。

Simulation結果が、

time × x × y

のような時空間データになった場合に使いやすくなります。

Zarr

https://zarr.readthedocs.io/

大規模な多次元配列をChunk単位で保存できる形式です。

時系列Rasterや大規模Simulation ResultをObject Storageへ置く構成と相性がよいため、将来的な候補として考えています。

Celery

https://docs.celeryq.dev/

非同期Job実行の中心として利用する想定です。

今回のシステムでは、

API
 ↓
Queue
 ↓
Worker
 ↓
GIS Processing / Simulation

という構成を基本にしています。

複数Runの並列実行にも利用できます。

Redis

https://redis.io/docs/latest/

CeleryのBrokerやJob Queueとして利用する想定です。

ローカルDocker Composeから始めやすく、後から構成を変更しやすい点も今回の方針に合っています。

MLflow

Experiment管理の考え方として参考にしています。

特に、

Experiment
  ↓
Run
  ├─ Parameters
  ├─ Metrics
  └─ Artifacts

という構造は、数値シミュレーションの複数ケース管理にも使いやすい考え方です。

ただし、今回のPlatform全体をMLflow中心にするのではなく、

Experiment Service
       ↓
Tracking Adapter
       ↓
MLflow

のように、Tracking Backendの1つとして接続できる構造を想定しています。

Optuna

パラメータ探索や最適化を行うためのライブラリです。

将来的に、

自動キャリブレーション
最適条件探索
多目的最適化

などを行う場合に利用できます。

今回の構成では、

Experiment
   ↓
Run
   ↓
Metrics
   ↓
Optimization

という流れのOptimization部分を担う候補です。

SALib

https://salib.readthedocs.io/

感度分析を行うためのPythonライブラリです。

Sobol法、Morris法、FASTなどを利用できるため、

Parameter Space
      ↓
Run
      ↓
Metrics
      ↓
Sensitivity Analysis

という処理へ発展させる場合に参考になります。

SciPy QMC

https://docs.scipy.org/doc/scipy/reference/stats.qmc.html

Latin HypercubeやSobol Sequenceなど、実験計画・サンプリングに利用できる機能があります。

Experiment PlatformでParameter SpaceからRunを自動生成する部分に利用できます。

MinIO

S3互換のObject Storageです。

ローカルやオンプレミス環境ではMinIOを利用し、クラウドではS3等へ切り替える構成を想定しています。

StorageBackend
 ├─ Local
 ├─ MinIO
 ├─ Amazon S3
 ├─ Azure Blob Storage
 └─ Google Cloud Storage

のように抽象化しておけば、Platform本体を変更せずStorageを切り替えられます。

Docker / Docker Compose

今回のPlatformではDockerを基本単位として考えています。

ローカルでは、

frontend
api
worker
redis
postgres
object-storage
tracking
nginx

などをDocker Composeで起動します。

同じContainer ImageをクラウドやKubernetesでも使えるようにすることで、特定環境への依存を減らします。

Kubernetes

https://kubernetes.io/docs/

将来的にWorker数が増えたり、大規模計算をクラウド上で実行するようになった場合の候補です。

最初からKubernetes前提にはせず、

Docker Compose
      ↓
必要になったら
      ↓
Kubernetes

という順番で考えています。

Open OnDemand

ブラウザからHPC環境や計算Jobを利用するためのプラットフォームです。

今回のSimulation Platformが将来的に、

HPC
Slurm
大規模並列計算
GPU

へ進んだ場合のUIやJob管理の考え方として参考になります。

Nginx

https://nginx.org/en/docs/

Reverse Proxy、静的ファイル配信、API振り分けなどを担当します。

今回の構成では、

Browser
  ↓
Nginx
  ├─ Frontend
  ├─ API
  ├─ FlatGeobuf
  └─ Static Files

のような入口として利用する想定です。

Keycloak

将来的なユーザー管理・認証・権限管理の候補です。

OAuth 2.0 / OpenID Connectを利用し、

User
Organization
Workspace
Role
Permission

をPlatformへ追加するときに利用できます。

OpenTelemetry

https://opentelemetry.io/docs/

API、Job、Worker、Solverをまたいだ処理を追跡するために参考になります。

例えば、

API Request
   ↓
Job
   ↓
Worker
   ↓
Solver
   ↓
Result

を1つのTraceとして追跡できるようにすると、障害解析や性能調査がしやすくなります。

Prometheus

https://prometheus.io/docs/

API、Worker、Database、QueueなどのMetrics収集に利用できます。

Grafana

https://grafana.com/docs/grafana/latest/

Prometheus等で収集したMetricsをDashboardとして表示するために利用できます。

Platform全体の状態監視に利用する想定です。

Grafana Loki

https://grafana.com/docs/loki/latest/

API、Worker、Simulation Solverなどから出るログを集約する候補です。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

WebGISと数値シミュレーションをどうつないでデータ基盤をつくるのか ー 基本設計

WebGISと数値シミュレーションをどうつないでデータ基盤をつくるのか ー 基本設計

はじめに

1. 最初から全部を一体化しない

2. 基本はAPI経由にする

3. 「データ」を共通のリソースとして扱う

4. Experimentを最初から共通概念に入れる

5. RunとJobは分ける

6. JobはGIS処理とシミュレーションで共通化する

7. 実験計画を使ってRunを自動生成する

8. 個別分野のロジックはPluginへ閉じ込める

Data BuilderもPluginとして扱う

SolverとData Builderを1対1にしない

Plugin Registryで一元管理する

Plugin化する目的

9. シミュレーションモデルはPluginとして扱う

10. ResultだけでなくMetricsも持つ

11. MLflowの考え方は相性がいい

12. WebGISとSimulationはDatasetでつなぐ

13. ブラウザだけで完結する構成にする

14. クラウドに依存しすぎない

15. Storageを切り替えられるようにする

16. 計算環境も切り替えられるようにする

17. Dockerを基本にする

18. 技術構成の例

19. 将来的には最適化やキャリブレーションにもつなげられる

20. AIとの連携もExperiment単位にすると分かりやすい

21. 開発は段階的に進める

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Step 10

22. 最終的な構成

23. この構成でやりたいこと

24. まとめ

25. 今回参考にしたもの

参考にしたプロジェクト・仕様

Tethys Platform

Delft-FEWS

OGC API - Processes

OGC API - Features

OpenLayers

PostgreSQL / PostGIS

FlatGeobuf

GDAL

GeoPandas

Rasterio

STAC

Cloud Optimized GeoTIFF

Xarray

Zarr

Celery

Redis

MLflow

Optuna

SALib

SciPy QMC

MinIO

Docker / Docker Compose

Kubernetes

Open OnDemand

Nginx

Keycloak

OpenTelemetry

Prometheus

Grafana

Grafana Loki

WebGISと数値シミュレーションをどうつないでデータ基盤をつくるのかー基本設計

WebGISと数値シミュレーションをどうつないでデータ基盤をつくるのかー基本設計