Google Earth Engine (GEE) へのいくつかの不満
AIMMGoogle Earth Engine（GEE）は、Googleが提供する地理空間データの解析プラットフォームである。SentinelやLandsatなどの衛星画像をGoogleのサーバ上で利用でき、大量のデータを自分のPCにダウンロードすることなく処理できる。
衛星画像の解析環境として非常に強力な仕組みであることは間違いない。しかし、実際にローカルPCのPythonからGEEに接続して利用してみると、いくつか不満を感じる点があった。
特に、データの内部構造の理解、画像表示の永続性、データのローカル保存という3点である。
1. データの中身を理解しにくい
通常のPythonプログラミングでは、変数の内容を確認したければ、print() などを使って表示することができる。
ところが、GEEでは事情が異なる。
GEEには ee.Image、ee.ImageCollection、ee.FeatureCollection などの独自のオブジェクトがある。これらは通常のPythonオブジェクトとは異なり、基本的にはGoogleのサーバ側に存在するデータや計算処理を表現している。
そのため、例えば次のように記述しても、
print(image)画像の属性情報などが、そのまま分かりやすく表示されるわけではない。GEEの内部的な処理定義を表す複雑な構造が表示されることがある。
実際の情報を取得するには、次のように記述する必要がある。
print(image.getInfo())この getInfo() によって、サーバ側のオブジェクトを評価し、その結果をローカルのPythonで扱えるデータとして取得できる。
もちろん、この仕組みには理由がある。GEEは膨大なデータをサーバ側で処理するように設計されており、すべてのデータをローカルPCに転送するわけにはいかない。
しかし、データの構造や処理の仕組みを詳しく理解しようとすると、通常のPythonプログラミングとは異なる考え方を要求される。
単に用意された機能を使って解析結果を得るだけであればよいが、データの中身を一つずつ確認しながら理解したい場合には、かなり面倒に感じられた。
2. Foliumで表示した衛星画像が、時間の経過とともに表示できなくなる
ローカルPCのPythonからGEEを利用する場合、Foliumを使って衛星画像を地図上に表示することができる。
Foliumは、Pythonからインタラクティブな地図を作成するためのライブラリであり、HTML形式で地図を保存することもできる。
しかし、GEEの衛星画像をFoliumで表示した場合、そのHTMLファイルを保存しておいても、時間が経過すると衛星画像が表示されなくなることがある。
これは、GEEの画像表示の仕組みに起因する。
GEEでは、地図表示用の画像タイルを取得するために、Map IDなどの情報を発行する。このMap IDには有効期限があり、Googleの公式資料によれば、数時間程度で失効する。
つまり、Foliumで作成したHTMLファイルの中に衛星画像そのものが保存されているわけではなく、ブラウザがGoogleのサーバにアクセスして画像タイルを取得しているのである。
Map IDの有効期限が切れると、そのHTMLファイルを開いても衛星画像を取得できなくなる。
これは、解析結果を地図として保存し、後日同じ状態で閲覧したい場合には不便である。
もちろん、新しいMap IDを取得する仕組みを構築すれば、継続的な表示は可能である。しかし、単にHTMLファイルを保存しておけば、いつでも同じ衛星画像を表示できるというわけではない。
3. 大量の衛星画像をローカルPCに保存するのが面倒
私がGEEについて最も不満を感じたのは、この点である。
GEEでは、大量の衛星画像をGoogleのサーバ上で処理できる。しかし、処理したデータを自分のPCに保存しようとすると、途端に手間がかかる。
例えば、GEEのエクスポート機能を使えば、衛星画像をGoogle Driveに出力できる。
しかし、この場合には、GEEからGoogle Driveへエクスポートした後、さらにGoogle DriveからローカルPCへダウンロードする必要がある。
少数の画像であれば大きな問題ではないが、大量の衛星画像を継続的に取得する場合には、この工程が煩雑になる。
また、GEEには getDownloadURL() という、画像を直接ダウンロードするための機能もある。しかし、Googleの公式資料によれば、1回の要求で取得できるデータ量は最大32MBである。
32MBという容量は、実際の衛星画像処理で扱うデータの規模からすると、非常に小さい。
例えば、AIMMでは、Copernicus Data Space Ecosystem（CDSE）からSentinel-2の衛星画像を取得している。
取得したデータはMGRSタイル単位で管理しており、54SUEなどのタイル1個当たりのダウンロード容量は、おおむね100MB前後である。
また、埼玉県の市区町村について衛星画像を切り出し、PNG形式で保存したところ、その合計容量は約90MBになった。
埼玉県の市区町村別PNG画像だけで90MBである。これを全国の市区町村について作成し、さらに複数年分を整備するとなれば、扱うデータ量は相当な規模になる。
そのような処理を行う立場からすると、1回32MBというダウンロード制限は、実用上かなり厳しい。
もちろん、これは getDownloadURL() に固有の制限であり、GEE全体で32MB以上のデータを出力できないという意味ではない。大容量の画像については、バッチエクスポートなどの方法が用意されている。
しかし、衛星画像を大量に取得し、自分のPCで加工・管理したい利用者にとって、GEEのデータ出力の仕組みが必ずしも使いやすいとは思えない。
4. GEEとローカル処理では、基本的な設計思想が異なる
これらの問題は、GEEの設計思想と関係していると考えられる。
GEEは、巨大な衛星画像データセットをGoogleのサーバ上に置き、利用者がその場所で計算する仕組みを基本としている。
大量の衛星画像を処理する場合、データをすべてローカルPCに転送する必要がないという点は、大きな利点である。
一方、AIMMでは、CDSEから衛星画像の元データを取得し、ローカルPCで加工している。必要なデータは自分で保存・管理し、そのデータを使って市区町村別の画像を作成する。
この方式では、データの取得や加工に必要な計算資源とストレージを自分で用意しなければならない。しかし、取得したデータの構造を直接調べることができ、加工方法も自由に決められる。
また、一度保存した衛星画像は、外部サービスの一時的な表示URLに依存せず、繰り返し利用できる。
GEEのようなクラウド上の解析プラットフォームと、ローカルPCを中心とした処理環境では、得意とする用途が異なるのである。
5. おわりに
実際のところ、これらの不満が、AIMMの衛星画像ビューアを独自開発する直接の動機となった。
Google Earth Engineの仕組みに合わせて衛星画像を扱うのではなく、Copernicus Data Space Ecosystem（CDSE）から元データを直接ダウンロードし、自分のPCで加工・保存する。そして、加工した衛星画像を自由に閲覧できるビューアも自分で構築する。
そのような方針を採用した結果、現在のAIMMの衛星画像と独自ビューアが生まれた。
つまり、AIMMの衛星画像ビューアは、単に新しい閲覧ツールを作ろうとして開発したものではない。Google Earth Engineを実際に利用する中で感じた制約を解消し、衛星画像を自分の管理下で自由に扱える環境を実現しようとしたことが、その出発点なのである。
参考資料
- Google Earth Engine Documentation — Client vs. Server
https://developers.google.com/earth-engine/guides/client_server - Google Earth Engine Documentation — Image Visualization
https://developers.google.com/earth-engine/guides/image_visualization - Google Earth Engine API — ee.Image.getDownloadURL
https://developers.google.com/earth-engine/apidocs/ee-image-getdownloadurl - Google Earth Engine Documentation — Exporting Images
https://developers.google.com/earth-engine/guides/exporting_images
