LiDARで木の影まで計算するShadeMapの実験
(tedpiotrowski.svbtle.com)- ShadeMapは、世界中で入手しやすいレーダーベースの標高データで影を計算してきたが、木の多い地域では直射日光の予測が大きく外れることがあった
- LiDARは地面だけでなく、木や建物のような物体の高さまでより精密に反映できるため、季節や時間帯ごとの植生の影のシミュレーションを可能にする
- ワシントン州の公開LiDARデータセットのおかげで、Seattle metropolitan areaのような実際の地域で、木の影を含めたレンダリングを実験できた
- 実サービスへの適用には、100GB単位のGeoTIFFをブラウザ向け画像タイルに変換する作業や、メモリ制限、ストレージ容量の問題が伴う
- Seattle metropolitan areaの変換も12時間後に半分程度にとどまり、タイルが15GBを超えたため、公開提供はコスト負担から小さなデモに限定されている
ShadeMapに木の影がなかった理由
- ShadeMapは標高データを使って影をシミュレートしており、世界的に入手しやすい標高データセットはSRTMのようなレーダーベースのデータである
- レーダーは夜間でも動作し、雲を通過できるため、衛星が宇宙から24時間データを収集できる
- Bainbridge Islandの7月9日午前7時9分のレンダリング比較では、レーダーベースのデータが植生を十分に反映できず、影のかなりの部分が抜け落ちていた
- レーダーは地面だけで反射するという当初の説明に対し、HNユーザーがレーダーも植生のような表面で反射すると指摘し、その後訂正が追加された
- SRTMレーダーデータセットが地面標高データの出典として引用されていたため、そのような仮定が生じた
- 一方でLiDARはより正確だが、飛行機やドローンで収集する必要があり、霧や雲を通過できない
- 収集には時間と費用がかかるため、各地方政府が測量費用を負担する構造になっている
LiDARデータをブラウザ向けタイルに変換する負担
- ワシントン州は広い地域をカバーするLiDARデータセットを提供しており、これを活用すればShadeMapの木の影シミュレーションを改善できる
- 元データは従来のGISソフトウェア向けのGeoTIFF形式で、ブラウザで高速に読み込むのに適したJPGやPNGとは程遠い
- 変換作業は、数百GBの浮動小数点・imperial feet単位のGeoTIFFファイルを小さな画像タイルに切り分け、metric metersの値を赤・緑・青のピクセル値としてエンコードする方式である
- 作業の過程では1TBのハードドライブを購入し、ChatGPTに変換方法を尋ねながら進めた
- 16GB RAMでは大きなデータファイルを一度にロードするのが難しく、地図全体ではなく小さな領域単位で処理するよう変換コードを書き直す必要があった
- Seattle metropolitan areaだけを変換しても、12時間後に半分程度しか完了せず、生成されたタイルは15GBを超えた状態で増え続けた
- 成果物は印象的だが、データを公開ホスティングする費用が負担となるため、現在は小さな領域だけをデモとして提供している
- 更新後、shademap.appでは地球の大きな部分について、1平方キロメートルブロック単位のLiDARデータを提供できるようになった
1件のコメント
Hacker Newsのコメント
デモがものすごく格好よくて速い。いま過去の地図と航空写真を分析するための大規模なリポジトリ／プラットフォーム（https://pastmaps.com - まだごく初期なので、あまり厳しく見ないでほしい）を作っていて、タイリングのパイプラインとGeoTIFFをかなり扱っている
同じように元のGeoTIFFファイルをソースとして使っていて問題が起きたが、S3に置いた静的ファイルにHTTP Rangeリクエストを組み合わせ、MapLibre内にカスタムのタイリングフックを作ることで、タイリングの必要性を回避できた。計算をクライアント側に押し出す形にはなるが、古いモバイル端末でもかなり速く動いた
MapLibreのGeoTIFFソース対応に興味があるなら、基本コードやその作業の一部をオープンソースとして共有できる。ネットでこんなものをいじっている変人は自分だけだと思っていた :D
自分の場合、LiDAR GeoTIFFは英フィート単位で、32ビット浮動小数点精度。海面からエベレストまでの標高範囲をメートル（8848）で取り、int16に収めれば0.2m精度が得られる。ShadeMapには十分なので、float32をint16に変えれば理論上クラウドストレージ容量は半分になり、PNG圧縮まで考慮すればさらに減る可能性がある
https://www.cogeo.org/
OpenLayersは対応している: https://openlayers.org/en/latest/examples/cog.html
MapLibreやLeafletには組み込み対応はないと理解している
この分野に非常に関心があり、いくつかのプロジェクトを資金面で支援することも含めて考えている。すでにTedにはメールを送ったが、こういう作業をしている人なら誰とでも話してみたい。メールはプロフィールにある
幸い、十分ニッチな分野なので受信箱がパンクする心配はしていない
GeoTIFF形式のどこに正確に問題があるのか、もっと学ぶ必要がありそうだ。2つのプロジェクトの間で純粋な変換パイプラインのインフラを共有すると役に立つかもしれない
2人いるなら、同じ壁にぶつかった人はほかにもいるかもしれない
「レーダーは植生を含まないため、生じる影の90%を明らかに取り逃がす。レーダーは地面からしか反射しないので、木や建物のような物体は見えない」という説明は正しくないと思う
レーダーは特定の帯域では葉を透過して見ることができる。いわゆるFOPENだ。地形マッピングに必要な距離とカバレッジ速度で、レーダーが建物を透過して見られるかはよく知らない
記事で言及されているShuttle Radar Topography MissionはCバンドかXバンドのレーダーを使っていたはずで、どちらも植生や建物から反射が出るはずだ
さらに掘り下げていない段階では、レーダーデータに植生や建物の影がない理由は、1) レーダーデータの解像度が低すぎる（数十メートル以上）、2) 複数の幾何条件のレーダーパスを後処理する過程で除去された、3) レーダーの低い入射角のため、そもそも影があまり生じなかった、のいずれかかもしれない
レーダーが樹冠をサンプリングしたのか、地面をサンプリングしたのかについて、FAQは厚い植生キャノピーを透過して見ることはできなかったと説明している。多少はキャノピー内に入り込んだ可能性はあるが、概ねキャノピー上部付近を追っていたという
問題は、レーダー信号が樹冠で反射したのか、地形で反射したのか、あるいはその組み合わせなのかだった。測地学者は地形に関心があり、森林研究者はキャノピー高に関心がある
使用された波長である5.6cmは植生をあまり透過しないため、中程度〜密な植生ではキャノピー上部付近をマッピングしていた。レーザー高度計と比較した研究では、若干透過したことは示されたが、地面までは届いていなかった。植生がまばらだったり葉がなかったりする場合は、地面からの反射が得られることもあった。Earth Observing Systemの一部として予定されていたVegetation Canopy Lidarはこの機能を提供し、興味深いデータセット比較を可能にするかもしれない
https://www2.jpl.nasa.gov/srtm/faq.html
山岳の影は実際に問題になる。一部のリリースには、特にヒマラヤ周辺のようにレーダー反射がなかった場所に空白領域が含まれている。興味があるなら、SRTMデータの空白領域補完に関する論文はかなりある
GeoTIFF を前処理することになり、すでにユーザーに地形標高を提供するパイプラインがあるなら、タイルには LiDAR とレーダーの差分だけをエンコードして、既存の地形データの上に樹木データだけを重ねることもできそう。エンコードする対象と必要な精度は 4 ビット程度にも収まりそうだし、0 が多いので圧縮で消えるはず。単なるブレインストーミングに近い考えだけど
height = -10000 + ((R * 256 * 256 + G * 256 + B) * 0.1)[mapbox/maptiler]height = (R * 256 + G + B / 256) - 32768[mapzen terrarium]海面上の標高（0〜8848m）だけが必要なら、2 バイトにデータを収めつつ 0.13m の精度を維持できる。Mapbox の精度は 0.1m
height = (R * 256 + B) / (256 * 256) * 8848[shademap]このエンコーディングを使う予定。すでに試していて、容量を節約できる。処理時間はよく分からない
最良のエンコーディングは、タイル全体の最低標高をヘッダーに入れ、タイルの最低標高と各ピクセル標高の差分値だけを保存すること。空間効率は最も良いが、最低標高を見つけるためにタイルデータ全体をメモリに載せる必要があり、ピクセルを 1 つずつストリーミングしながらエンコードするよりは効率が落ちる
位相データ科学に習熟するには何を学べばよいか教えてほしい
Shademaps が好きだ。これを使っている自分のプロダクトがもっと成功していればよかったけれど、Ted と Shademaps は素晴らしい。樹木を追加するのは非常に実用的だ。このツールが使われる地域の多くは都市部ではあるが、そうでない場合は、樹木データが建物や標高よりほぼ常に重要になる。Ontario はかなり平坦で、自分のユーザーの 99% はそこにいる
GIS 企業の面接質問に出そうだ。「レーダーと LiDAR のデータがあり、メモリが制限された機器でそれらを統合したい場合、どうするか？」
フランスの地図サービスがフランス全土の HD LiDAR 撮影を開始しており、一部はすでに提供されている: https://geoservices.ign.fr/lidarhd 下の方にある
いつかこのデータをアプリに含める計画があるのか気になる
今の主な障害は、婚約者が夏休み中で（教師なので）外に出ることが多いのと、オンラインで LiDAR データセットを見つけるのも難しいこと
Washington のデータはかなり前からあったようだが、数週間前まで存在を知らなかった
いつか LiDAR データセットについて ASK HN を投稿して、できるだけ多くのデータをクラウドソーシングできればと思っている
素晴らしいプロジェクトだ
データを Requester Pays が有効な S3 バケットでホストするのはどうだろう？ そうすれば保存コストだけを負担すればよい
匿名アクセスはできなくなるが（Dropbox 共有も同様）、コストは大きく下がる
https://docs.aws.amazon.com/AmazonS3/latest/userguide/Reques...
読み取り専用なので必ずしも SQL フロントエンドは必要ないだろうし、SQLite に S3 バケット上のデータベースへアクセスさせる方法もいくつかある。例: https://github.com/michalc/sqlite-s3-query
デモはとても見事だが、出力の大半は価値が低い。影を地面ではなく樹冠の上端から計算しているためだ。そのため、密な森でも夜明けに日が差しているように見える
それでも、森の縁や都市の植生など、さまざまな用途には非常に有用だろう。そうしたユースケースでは地図タイルをずっと小さくできるし、LiDAR データを必要に応じて取得して変換することもできそうだ
SQLite データベースに変換して、はるかに低コストの静的ファイルとして提供できるのでは？
https://news.ycombinator.com/item?id=27016630
HTTP の範囲リクエストが重要な魔法を担っているが、その部分はすでに「解決済み」だ
今日の業界の「標準状態」に近いアプローチだが、小規模な開発者、つまり自分のような人間には依然として欠点がある
第一に、タイルリクエストを受けて内部的に SQL リクエストや mbtile リクエストに変換する別個のタイルサーバーを運用しなければならない。動く部品が増えるのはあまり好きではない
第二に、10TB を超え、増え続けている GeoTIFF をすべて mbtiles に処理しなければならず、計算コストと実際の所要時間が大きい
第三に、結果の mbtiles はよくても元の GeoTIFF と同程度のサイズで、悪ければはるかに大きくなる。より速いリクエストと引き換えに、ホスティングと転送のコストが増える。興味があれば、GeoTIFF 圧縮最適化を分かりやすく説明した記事がある: https://blog.cleverelephant.ca/2015/02/geotiff-compression-f...
Ted にも彼なりの考えがあるだろうが、この数カ月この分野を新たに掘り下げて自分が得た結論はこのくらいだ
良い
かつて地理空間技術に携わっていた人間の視点から、少し関連がありつつ退屈かもしれない話をすると、2000年代から地方自治体が区域単位、または一部区域単位のLiDAR航空測量を発注し、さらにその成果であるデジタルデータを一般公開しようとする流れが生まれていました
10年以上前から、民間部門の技術者は都市全体のLiDARデータセットを大量に受け取り、小規模な分析、地図、図面に日常的に活用していました
地方自治体のデータ共有方針は地域によって大きく異なり、今もそうである可能性が高いですが、LiDARデータは時に「地表地形」「建物」「樹冠」のような複数のレイヤーとして提供されていました。これはLiDARの運用者がさまざまな周波数で最初に取得し、計算した結果でした
オフィスの技術者たちは、依頼に合わせてデータを調整する手順を見つけて実行していました。通常は商用ソフトウェアとルーチンで小規模な成果物を作成しており、ここで扱われているものと非常によく似た日照/陰影分析や可視領域分析も、当時すでに依頼されるサービスでした
小さな地区規模の作業で樹冠LiDARを含めようとする初期の動きが民間部門に浸透し始めていましたが、新しく珍しいことでした。今こうした作業が大規模に行われているのを見ると励みになります
大規模データをオンラインで提供することについては、私の恐竜のように古い経験はほとんど役に立ちませんが、より大きな規模の生の地理空間データセットを扱うことは、この分野の中核的な課題であり続けてきました。結局のところ、すべての作業はそうしたソースを、効率的で理解しやすく、目的に合うよう焦点を絞った出力へ翻訳または抽象化することに行き着きます
そういう意味で、このようなイノベーションを大規模に実用化するうえで実際に推進力となっているのは、コンピューターサイエンス、より具体的にはデータサイエンスの側面です