この記事の目次
NetCDFは多次元の科学データの保存に適する一方、ブラウザはインタラクティブな地図表示に向いているため、海洋データWebアプリでは、性質の異なる両者をどう結ぶかが設計上の課題になります。
信頼できるアプリを作るには、どの観測値を採用するかを決め、単位と来歴を引き継ぎ、利用者が探しやすい形へデータを変換し、必要な分だけを配信して、画面を軽快に動かす必要があります。これらの判断をフロントエンドまで先送りすると、ブラウザの動作が遅くなり、値の意味も曖昧になります。
この記事では、NetCDFに保存されたプロファイル観測データを、Web画面へ表示するまでの構成を説明します。Argoを例にしますが、グライダー、CTD、係留系、モデル出力にも同じ考え方を応用できます。
フロントエンドだけでなく、データ経路全体を設計する
5段階には、それぞれ異なる役割があります。
- NetCDFソース：観測値、次元、メタデータ、生の値・補正済みの値、品質情報を保持する。
- 科学的な前処理：プロファイル選択、QC、単位を踏まえた計算、妥当な範囲での補間、検証を行う。
- Web向けストレージ：画面での利用方法に合わせ、軽量JSON、列指向データ、タイル、再利用可能な図などから選んで保存する。
- 配信：検索とメタデータにはAPI、容量が大きく内容が変わらないファイルにはオブジェクトストレージ、再利用できる応答にはキャッシュを使う。
- ブラウザ：地図、鉛直プロファイル、時系列断面図、詳細情報のほか、何を表示しているか分かる操作UIを提供する。
処理段階の設計だけでなく、段階間でデータをどう受け渡すかを定める仕様も同様に重要です。たとえば、圧力座標のない水温の配列は使えず、観測IDのない点から元データをたどることもできません。また、欠損値の扱いを定めずに断面図を補間すると、観測で裏づけられる範囲を超えて値が連続しているように見えてしまいます。
NetCDFをそのままブラウザへ送るだけでは足りない理由
一部のNetCDFデータは、ブラウザ上でも読み込めます。ただし、それが基本構成として最適とは限りません。
ArgoはプロファイルデータをNetCDFで配布しています。ファイルには、座標、圧力・水温・塩分などの観測値、品質フラグ、補正済み変数、データモードの情報が含まれます。Argoデータファイルの公式ガイドでは、これらの項目がどう組み合わさるのかを説明しています。
一方、ブラウザ向けアプリで必要なデータ形式は、用途ごとに違います。
- 地図に必要なのは、多数の観測点の位置と識別子をまとめた軽量なデータです。
- プロファイル図に必要なのは、選択した1サイクルについて、圧力または深度座標に対応づけた水温・塩分などの観測変数の配列です。
- 鉛直断面に必要なのは、多数のプロファイルを共通の圧力軸または深度軸にそろえたデータです。
- 観測点やプロファイルを説明する表示に必要なのは、ファイル属性をすべて並べることではなく、観測日時、位置、識別子、品質情報など、人が読めるメタデータです。
ユーザー操作のたびに元のファイルをすべてダウンロードする設計では通信量が増えるうえ、QC、単位変換、補間、欠損処理などをブラウザで繰り返し実行することになり、表示までの負荷も大きくなります。これらの処理をデータ生成時に済ませておけば、処理ルールを一元管理し、用途に合わせたデータをブラウザへ返せます。
利用者の操作から必要なデータを決める
データベースやJavaScriptフレームワークを決める前に、利用者が画面で日常的に行う操作を書き出します。
| 利用者の操作 | 最小限必要なデータ |
|---|---|
| この海域・期間のプロファイルを表示 | ID、位置、日時、データの有無 |
| 1件のプロファイルを開く | 圧力・深度座標、選択変数、単位、プロファイルメタデータ |
| 1台のフロートの観測時期と位置を確認 | サイクル番号、日時、位置 |
| 複数サイクルのプロファイルを比較 | 圧力・深度座標、選択変数の値、単位、品質情報 |
| 時系列の鉛直断面図を描画 | 共通鉛直グリッド、時間・サイクル軸、値、欠損マスク |
| 表示された観測値の出典と品質を確認 | 元プロファイル、変数、採用値、QC・来歴の概要 |
この表が示すように、画面の操作ごとに必要なデータの形は異なります。すべての情報を1つのAPIレスポンスやファイルにまとめるのではなく、地図表示用の軽量な一覧、選択したプロファイルの詳細、鉛直断面用のまとまったデータを分けて用意します。地図用の一覧は小さく保ち、プロファイルの詳細は選択されたときに読み込み、容量の大きい断面データはキャッシュまたは再利用できるファイルとして保存します。
扱う範囲を絞ることも有効です。たとえばOceanGraphは、前処理済みArgoデータを詳しい解析へ進む前に概観するための道具であり、汎用の数値解析APIを提供するものではありません。範囲を絞れば必要な操作を明確にできるため、それに合わせてデータモデルを最適化できます。
科学的な処理規則を再現可能なパイプラインに組み込む
前処理では、データの選択や品質管理、補間などの規則をまとめて適用し、結果と適用条件を記録します。Argoでは次のような規則を定めます。
- 補正済みの値と生の値のどちらを選ぶか
- どのQCフラグを許容するか
- 圧力、水温、塩分の対応を保ったまま処理できているか
- fill valueをどのように欠損値へ変換するか
- 観測範囲が足りないプロファイルを除外するか
- 派生深度や熱力学変数をどの方法で計算するか
- どこで補間を許し、どこを欠損のまま残すか
これらはフロントエンドの表示形式ではなく、画面に表示される海洋データの内容を決める規則です。Argoデータの品質管理ガイド：QCフラグと補正済みデータの選び方では値の選び方を詳しく扱い、初心者向けArgo NetCDF形式の解説ではソース構造を説明しています。
パイプラインの出力は一式として固定するか、バージョンを付けて管理します。ある実行のインデックスと別の実行のプロファイルを同時に公開すると、存在しないデータへのリンクやデータの食い違いが生じます。ソーススナップショット、使用したコードのバージョン、設定、生成日時、検証結果をリリース記録に含めます。
実際の観測データと照らし合わせて表示を確認する
この水温断面図は、WMO 5904935について、OceanGraphで処理したArgoデータのスナップショットから作成しました。利用できるプロファイルでは値を裏づけられない領域は、白いまま残しています。
Web実装では、この図を表示検証の基準として使えます。ブラウザの表示がパイプラインの出力と一致しているか、サイクルの並び、鉛直軸の向き、色の範囲、欠損箇所を確認します。さらに、表示されたパターンを元の観測値と照合できるよう、プロファイルIDとソースのバージョンも表示します。
Argoデータは自由に利用できますが、論文やデータサービスではArgoの謝辞・引用ガイドに従い、必要に応じてデータセットDOIも示します。
役割に応じてストレージを選ぶ
どの用途にも使えるストレージ技術はありません。データの役割に合わせて保存先を選びます。
検索メタデータ
識別子、サイクル、日時、位置、データの有無、公開バージョンなど、絞り込みに使う項目にはリレーショナルデータベースや検索インデックスが適しています。実際の検索条件に合わせてインデックスを設計し、海域検索がある場合は地理空間インデックスも検討します。
プロファイルのデータ
中規模の配列なら、軽量JSONはブラウザで扱いやすく、キャッシュもしやすい形式です。解析用にもっと大きなデータを転送する場合は、列指向形式やチャンク形式が適することもあります。形式は、実際のペイロード量とブラウザでの動作を測定して選びます。
事前に生成しておくデータと図
内容が変わらないSVG、PNG、JSON、バイナリチャンクには、固定したパスで参照できるオブジェクトストレージが適しています。データセットバージョンごとにURLが変われば、CDNでも効率よくキャッシュできます。
元データであるNetCDFアーカイブは、Web向けに変換したデータとは別に保管します。Web向けに変換したデータだけが、いつの間にか唯一の科学的な記録になってしまう事態を防げます。
APIが行う処理と行わない処理を決める
利用者が指定した条件や権限、最新のメタデータに応じて返す内容を変える場合は、APIが必要になります。海域・期間フィルターを検証し、返す件数を制限して、一定のスキーマでデータを返せます。
同じ断面図が繰り返し閲覧されるなら、リクエストごとに数百のソースファイルから再生成しないようにします。データパイプラインで再利用できるファイルを作り、APIは生成済みデータへのバージョン付き参照を返します。一方、変数・深度範囲・カラースケールの組み合わせを無制限に事前計算する必要もありません。負荷の軽い表示上の選択は、ブラウザに残します。
役割分担の例は次のとおりです。
- パイプライン：元データの解析、QC、科学的な前処理と派生値の計算、計算負荷の高い補間、集約データの生成
- API：海域・期間などの検索条件の確認、インデックスを使った検索、レスポンスの組み立て、公開中のデータバージョンの提示
- ブラウザ：表示範囲に応じた絞り込み、データの選択、軸・単位ラベルの表示、誰もが操作しやすいUI、元データを変更しない表示上の調整
段階的に読み込む
最初のページを表示するときに、全プロファイルの配列は必要ありません。たとえば、次の順序で読み込みます。
- アプリの基本画面と、件数を制限した地図・検索用の一覧を読み込む。
- 利用者が観測点を選んだときに、そのプロファイルの詳細データを読み込む。
- 断面図や比較画面を開いたときに、それらに必要な詳細データを読み込む。
- 選択内容が変わったら、古いリクエストをキャンセルするか、その結果を使わない。
- 内容が変わらないデータは、バージョン付きでキャッシュする。
地図上の矩形範囲、日付範囲、件数には上限を設けます。条件が広すぎるときは、ブラウザやAPIワーカーがメモリ不足に陥るのを待つのではなく、範囲を狭めるようはっきり伝えます。
圧縮も重要ですが、それ以前に不要な項目を送らないことが効果的です。そのうえで、通信時間が短いだけではグラフを軽快に描画できるとは限らないため、圧縮後の応答サイズ、JSON解析時間、描画時間、操作遅延を分けて測ります。
ブラウザ上でデータの意味を説明する
高速に表示できるグラフでも、意味を誤って伝えることがあります。画面から次を確認できるようにします。
- 変数名と単位
- 日時と水平位置
- 鉛直座標が圧力か深度か
- 塗りつぶさずに残した欠損領域
- プロファイルID、フロートのWMO ID、サイクル番号
- 絞り込みと処理の簡潔な説明
- 詳細な来歴やソース文書への導線
OceanGraphのデータソース（英語）とデータフィルタリングポリシー（英語）は、データの出典やフィルタリングの基準を表示とは分けて文書化し、必要なときに参照できるようにした例です。
これらの表示を支えるデータ仕様については、海洋データの意味を保つWebアプリ設計：単位・欠損値・QC・来歴で詳しく説明しています。
ソースから画面まで一貫してテストする
各層を個別にテストするだけでは十分ではありません。ソースから画面まで追跡するための検証用プロファイルを1件用意します。
- 選択した変数とQC規則を、ソースの期待値と照合する
- 出力スキーマを検証し、
NaNや無限大など、JSONで表現できない値が混じらないようにする - APIフィルターが指定範囲内のプロファイルだけを返すことを確認する
- 欠損値、空のプロファイル、日付変更線をまたぐ海域をテストする
- ブラウザのグラフを、パイプラインが生成した参照図と比較する
- キーボード操作、凡例、単位、読み込み中の表示、エラーを確認する
- 固定した環境で同じスナップショットを再生成する
研究の解析環境を再現可能にする方法：Docker入門では、ソフトウェア環境も解析結果を支える条件の一つである理由を説明しています。
小さく始めて検証できる構成
海洋プロファイルアプリは、最初から大規模にせず、次のような構成から始められます。
- ソースNetCDFは読み取り専用で扱う。
- バージョン管理した前処理ジョブを実行する。
- 検索用インデックスと、プロファイルごとのコンパクトなデータを公開する。
- 繰り返し利用する表示だけを事前に生成する。
- APIで検索条件に応じたメタデータを返し、内容が変わらないファイルはオブジェクトストレージから配信する。
- ブラウザは必要なデータだけをその時点で読み込み、単位、欠損、来歴を表示する。
- データ全体へ拡張する前に、既知の観測値1件をソースから画面まで通して検証する。
特別な仕組みを増やさなくても、これらの構成で始められます。大切なのは、操作の快適さを保ちながら、単位、欠損、来歴といった科学的な文脈を値から切り離さないことです。
この構成を自組織だけで設計・実装するのが難しい場合は、設計・実装支援についてご相談ください。
お問い合わせ
構築・実装支援とアノテーション業務
環境構築や設計・実装の支援、アノテーション業務の委託について、ご相談いただけます。
よくある質問
WebアプリではすべてのNetCDFをJSONへ変換するべきですか？
必ずしも必要ではありません。画面で提供する操作に必要な範囲と形式だけを変換し、ソースファイルは残したまま、使わない変数まで複製しないようにします。
補間はブラウザで行うべきですか？
計算量が大きい補間や、科学的な意味を左右する補間は、テスト済みの前処理パイプラインに置くのが一般的です。表示だけの再サンプリングは、処理内容を明示でき、表示を元に戻せるならクライアントに置けます。
APIは必ず必要ですか？
いいえ。小規模で内容が変わらないデータセットは、バージョン付きの静的ファイルでも配信できます。検索件数の制限、メタデータの組み立て、アクセス制御、頻繁に変わる検索条件が必要になったときにAPIが役立ちます。
最も起きやすい設計ミスは何ですか？
科学データの配列だけで意味が伝わると考えることです。しかし実際には、値とともに座標、単位、欠損の意味、QC判断、識別子、来歴を扱う必要があります。
