第1回　衛星画像の探索

AIMMearthではSentinel-2の衛星画像を利用しています。データの探索にはCDSE（Copernicus Data Space Ecosystem）を利用します。

衛星画像を扱い始めた当初は、地名や場所を指定すれば簡単に目的の画像が見つかると思っていました。しかし、日本全国のSentinel-2画像を体系的に集めようとすると、MGRSグリッドについてある程度理解する必要があることが分かりました。

Sentinel-2のデータでは、例えば54SUEのようなタイル番号が使用されます。この番号がどの地域を表しているか分からないと、目的地域の画像を効率よく探すことができません。

一つの地域だけを調べるのであれば、MGRSを深く理解しなくても何とかなるかもしれません。しかし、日本全国を対象にすると100枚を超える規模のタイルを扱うことになり、どの地域がどのタイルに対応しているかを把握する必要が出てきます。

一方、MGRSそのものを完全に理解しようとするとかなり奥が深い仕組みです。

そこでAIMMearth制作では、MGRSを完全に理解することより、「この場所のSentinel-2画像が欲しいなら、このタイルを探せばよい」と判断できる程度の実用的な理解を優先しました。

この記事ではMGRSの理論を網羅的に解説するのではなく、実際にCDSEから目的地域のSentinel-2画像を探すために必要だった範囲を中心に説明します。

関連技術・キーワード：CDSE / Copernicus / Sentinel-2 / MGRS / 54SUE / Tile / 衛星データ

第2回　画像の選定

Sentinel-2は同じ地域を繰り返し観測しています。そのため、同じ地域について2025年の画像を検索しても、年間を通じれば数十枚の候補画像が存在します。

AIMMearthでは、その中から実際に掲載する画像を選ぶ必要があります。

最も重要な条件の一つが雲量です。雲が多い画像では地表が見えないため、原則として雲が少ない画像を優先します。

雲量についてはCDSE上で条件指定や並べ替えができるため、比較的機械的に候補を絞ることができます。

一方で難しかったのが雪や氷です。

雲量が非常に少ない画像でも、冬季であれば地表が雪で覆われている場合があります。逆に雪が少ない時期でも、雲が多ければ衛星画像としては使いにくくなります。

つまり、雲の少なさと積雪の少なさにはある程度トレードオフがあります。

そこでAIMMearthでは、雪の有無を高度な画像解析で完全自動判定するのではなく、まず撮影時期を限定する方法を取りました。

例えば2025年版では、3月から11月までを基本的な候補期間とし、その中から雲量の少ない画像を優先します。

こうすると、年間に数十枚存在する候補から、上位数枚程度までかなり機械的に絞ることができます。

最終確認には人間の判断も必要ですが、毎回「何となく一番きれいな画像」を選ぶのではなく、なるべく主観に依存しない選定ルールを作ることを重視しました。

また、2025年版AIMMearthでは、MGRSタイル単位で観測日を選んでいます。市区町村ごとに個別に最適な撮影日を選んでいるわけではありません。

関連技術・キーワード：Sentinel-2 / CDSE / Cloud Cover / Snow / Ice / 撮影時期 / 画像選定 / MGRS

第3回　座標系

衛星画像を扱い始めた頃、かなり苦労したのが座標系でした。

最初は、緯度経度、CRS、EPSG、UTM、MGRSなどが、すべて似た「場所を表す仕組み」のように見えていました。

EPSG:32651、EPSG:32652、EPSG:32653、EPSG:32654といった数字も、当初は何を意味しているのかよく分かりませんでした。

そのため、QGISで衛星画像を表示するときにも、「狙った場所を表示したいのに、どの座標系を使えばいいのか」が分からず苦戦しました。

実際に画像を扱っていくうちに、地球上の位置を緯度経度で表すことと、地球表面を平面の画像として表現するための投影法は別の問題であることが分かってきました。

UTMでは地球を複数のゾーンに分け、地域ごとに適した投影を利用します。そのため、日本国内でも地域によって利用するEPSGコードが異なります。

この記事では、測地学を完全に解説することを目的にはしません。

AIMMearth制作に必要だった範囲として、CRS、EPSG、UTM、MGRSがそれぞれ何を意味し、実際の衛星画像処理でどのように関係するのかを説明します。

関連技術・キーワード：CRS / EPSG / UTM / WGS84 / QGIS / EPSG:32651 / EPSG:32652 / EPSG:32653 / EPSG:32654

第4回　UTMゾーンの割り振り

UTMゾーンの基本を理解した後にも、全国の市区町村画像を実際に作る段階では別の問題が出てきました。

都道府県単位で一つのEPSGコードを決めればよいとは限らないからです。

典型的なのが長野県や静岡県です。

これらの県は東西に広いため、県全体をEPSG:32653だけで処理するのも、EPSG:32654だけで処理するのも適切とは限りません。

そこでAIMMearthでは、市区町村単位で使用するUTMゾーンを分けました。

例えば、西側の市区町村ではEPSG:32653、東側ではEPSG:32654を利用する、といった形です。

一般的なUTMの説明では、ゾーンの仕組みを理解すれば終わりですが、実際に全国の画像を作ろうとすると、「境界付近のこの市区町村はどちらに割り振るのか」という運用判断が必要になります。

AIMMearthでは、市区町村ごとに使用する座標系を決めること自体が一つの制作ノウハウになりました。

関連技術・キーワード：UTM / EPSG:32653 / EPSG:32654 / CRS / 長野県 / 静岡県 / 市区町村 / 投影

第5回　画像の切り抜き

CDSEから取得したSentinel-2のラスタ画像を、そのままAIMMearthに掲載するわけではありません。

市区町村単位で画像を作るため、市区町村境界のベクタデータを利用してラスタ画像を切り抜きます。

基本的な構造は、Sentinel-2のラスタ画像に、市区町村境界のベクタデータを重ね、QGISで境界に沿って切り抜くというものです。

この処理ではPyQGISをかなり利用しました。

制作初期には、まだ処理方法に慣れていなかったため、市区町村を一つずつ指定して切り抜いていました。

しかし全国分をこの方法で処理すると非常に時間がかかります。

何度も処理しているうちに、結局やっていることは毎回ほぼ同じであることが分かりました。

そこで処理をPythonスクリプト化し、最初は数市区町村、次第に数十市区町村、最終的には一つの都道府県単位でまとめて処理するようになりました。

後半になると、基本的には同じスクリプトを使用し、都道府県名や入力条件だけを変更すれば次の地域を処理できるようになりました。

この段階まで来ると画像制作速度はかなり向上しました。

重要だったのはPythonそのものだけではありません。ファイル配置、入力データ、CRS、出力名などの条件を標準化し、繰り返し作業を自動化できる状態にしたことです。

またQGISでは通常のPythonに加えてPyQGISというQGIS固有のAPIを使用します。Pythonの文法は同じでも、レイヤー、CRS、ラスタ、ベクタ、Processingなどを操作するQGIS独自の使い方は別に覚える必要がありました。

関連技術・キーワード：QGIS / PyQGIS / Python / Raster / Vector / Clip / 市区町村境界 / Processing / GeoTIFF / 一括処理

第6回　離島の分割

通常の市区町村であれば、一自治体につき一つの画像という形で処理できます。

しかし小笠原村では、この方法がうまくいきませんでした。

小笠原村には父島・母島周辺、硫黄島、南鳥島、沖ノ鳥島など、非常に離れた地域が含まれています。

これらすべてを一つの巨大な画像にまとめ、一つのUTM座標系で処理しようとすると、地域によって投影歪みが大きくなります。

実際、作成した画像を通常の地図上へ重ねると、地図と衛星画像の位置が合わなくなる問題が発生しました。

そこで小笠原村については例外的に複数のタイルへ分割し、それぞれ別の画像として扱うようにしました。

父島・母島周辺、硫黄島周辺、南鳥島周辺、沖ノ鳥島周辺など、地理的に離れた範囲を分離して処理します。

この経験から、市区町村という行政単位と、画像処理に適した地理的な単位は必ずしも一致しないことが分かりました。

関連技術・キーワード：小笠原村 / 父島 / 母島 / 硫黄島 / 南鳥島 / 沖ノ鳥島 / CRS / UTM / Tile / 投影歪み

第7回　画像仕様の標準化

全国規模で衛星画像を大量に生成すると、一枚ずつ作っている段階では気にならなかった問題が出てきます。

その一つがファイル名です。

日本の市区町村には正式な日本語名称がありますが、それをローマ字へ変換すると、必ずしも一つの表記に決まりません。

例えば大阪市をどのようにローマ字表記するかについても複数の考え方があります。

AIMMearthでは、一般的な英語表記として最も自然かどうかより、日本語名称から必ず同じ文字列へ変換できることを重視しました。

例えば「おおさかし」であればoosakashiとする、といった独自の一貫した変換ルールを使用します。

利用者に表示する名称は「大阪市」のままで構いません。内部ファイル名だけをASCII文字列に統一します。

PNG画像についても仕様を統一しました。

アルファバンドを付けるかどうか、透明部分をどう扱うか、空白部分を白にするか黒にするかなどによって、地図上での表示やサムネイルの見え方が変わります。

そのため画像ごとにその場で判断するのではなく、QGISやPythonで変換する段階で一定のルールに統一しました。

さらに重要なのがファイル容量です。

全国の市区町村について2025年版PNGを作成すると、全体でおよそ8GBになります。

一方、利用しているXServer VPSのディスク容量は限られています。50GBクラスのVPSであれば、OS、Apache、ログ、その他のファイルも同じディスクを使用します。

そのため、衛星画像を何年分でも無制限に保存することはできません。

ローカルPCでは500GB程度、外付けディスクでは5TB程度を使っていても、VPSでは容量を増やすほどサーバー料金も上がります。

そこでAIMMearthでは、何でも公開するのではなく、一般利用者が実際に使う可能性の高い画像を選んで公開する方針を取っています。

関連技術・キーワード：PNG / Alpha Band / ファイル命名 / ローマ字 / PyQGIS / Thumbnail / Storage / VPS / 画像容量 / 標準化