Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à 大規模タイル画像を生成した話（（独）農研機構 寺元郁博様）
Similaire à 大規模タイル画像を生成した話（（独）農研機構 寺元郁博様） (6)
Plus de OSgeo Japan
Plus de OSgeo Japan (20)
大規模タイル画像を生成した話（（独）農研機構 寺元郁博様）
- 2. はじめに ○ 「関東地方の過去130年間の土地利用・景観 変遷データベースの構築と公開」 ○ ○ (農環研主査) JSPS科研費 25292213 土地利用メッシュを作成するのが主目的 ○ 迅速測図、基盤地図の地図タイル画像作成 → 作成過程をご紹介 ○ 前の発表とか後の発表とかの方が良いとか言わ ない。
- 3. 自己紹介 ○ 広島県福山市にいます サイトをやってます ○ FOSS4G Tokyoは初めて ○ http://www.finds.jp/
- 4. なにはともあれ宣伝
- 5. 歴史的農業環境閲覧システム ○ 農業環境技術研究所 http://habs.dc.affrc.go.jp/ ○ 通称「HABS」 ○ 迅速測図の 高精細版が 春にリリース ○ ライセンスが CC-BY に変更
- 8. タイル化の対象 ○ 基盤地図情報 現在の地図 ○ ベクタデータ ○ ○ 関東平野迅速測図 ○ ○ 1880(明治13)年-1896(明治19)年作製 ラスタデータ (紙地図からスキャン) ○ モバイル機器に入れ、通信なしで現地調査 ○ 基盤地図の使用承認は未申請
- 9. 使用した計算機 FreeBSD機 ○ 基盤地図タイル画像で利用 ○ Xeon 2.13GHz, メモリ24G ○ ○ Windows機 ○ 迅速測図タイル画像で利用 • FreeBSD機のハードディスクがいっぱいになったため ○ Xeon 2.80GHz, メモリ12G
- 10. 基盤地図情報
- 11. 方針 ○ とりあえずWebメルカトル ○ 正距円筒は今回は行わない ○ 最大ズームレベル 18 ○ 迅速測図との関係で17でも良いかも ○ できるだけいらないタイルは作らない ○ 空白タイルを置いておくディスク余裕などない ○ 手持ち機材で現実的な時間内に作成
- 13. 要らないタイルを作らない策 ○ PostGISを使ってやればよい ○ SELECT ST_Intersects(geom, タイル範囲) FROM 基 盤地図; • 基盤地図.geom (基盤地図テーブルの地物)と タイル範囲がインタセクト(共通部分がある)している Trueが返る場合のみタイル作成 ※ 基盤地図テーブルは 実際はいくつかのテーブルに分かれています。 ○
- 14. スピードアップ策 #1 ○ PostGIS+MapServerがボトルネック ○ 一度に複数タイル分の画像を作成 → 個別のタイルに分割 ○ Cで記述 (GD利用) ○ しかし1.5ヶ月程度かかりそうで中止
- 15. スピードアップ策 #2 ○ 24G機なのに消費メモリが500MB程度 → マルチプロセスにしてやる ○ プロセス間は完全に独立する ○ 面倒なことを考えない P1 → Y軸で分担を決める P3 P2 P1
- 16. 必死になって計算中
- 18. 基盤地図2万5千タイルの成績 ○ 範囲は全国 ○ 「関東平野のみでないの？」は聞かない ○ ズームレベルは0-18 ○ 4プロセスで8日かかった ○ プロセス間の実行時間の差は1時間以下 ○ サイズでかい ○ 約67G, 35071259 (3500万)ファイル
- 19. その他のタイル ○ 地名 (ズームレベル20) 都道府県・市区町村・字町丁目 ○ 4プロセス 15時間 ○ 大多数のタイルが生成の必要が無い ○ ○ 基盤地図2万5千の太線(ズームレベル18) ○ 6プロセス 約3.5日 • 等高線をレンダリング対象から外したから?
- 20. 迅速測図
- 21. 元データが凄い ○ 旧版はBlueRayで送られてきてたのが 今回はポータブルHDD ○ (余談) 添付のUSBケーブルが壊れてた ピクセル数 101921 *103807 = 10580113247 「10Gピクセル」 ○ 座標系が UTM 54N (JGD2000) → Webメルカトル、正距円筒にしないと ○
- 22. 方針 ○ リサンプリングはlanczos(ランチョシュ)で ○ 高精細画像だし、遅いけどきれいなもので ○ Webメルカトルと正距円筒両方 ○ ズームレベルは 17(Webメルカトル)と16(正距円筒) ○ gdal2tiles (地図タイル画像生成)を 複数プロセスで動くようにいじる ○ 先に gdalwarp で投影変換、拡大縮小実施
- 23. 複数プロセス化は不要だった ○ gdal2tilesパラレル化パッチは存在した ○ http://trac.osgeo.org/gdal/ticket/4379 ○ 元情報 https://twitter.com/tmizu23/statuses/3632539946 65152512 ○ 知ってれば使ってた orz ○ 今回はさわやかに無視
- 24. 簡単でない複数プロセス化 ○ gdal2tilesはタイルからタイルを作ろうとする 最大ズームのタイルはソースデータから作成 ○ ズームレベルZのタイルはZ+1のタイルから作成 ○ ○ ズームレベルごとに同期を取る必要が ○ 今回は手作業で対応 ○ (コマンドラインから) Zを作成 → 全プロセス完了したらZ-1の作成を開始する
- 25. 先にgdalwarpで投影変換する ○ 手戻りできるように ○ 解像度をズームレベルにあわせる ○ unit/pixel = 2*PI*6378137/(256*2^Z) ○ gdal2tiles では nearest neighbor で OK
- 26. 投影変換例 ○ Z=16 ○ リサンプリング = lanczos ○ 空間参照系 = EPSG:3857 (Webメルカトル) ○ 900913だとパラメータがおかしくなった ○ gdalwarp –co “BIGTIFF=yes” ¥ -r lanczos –t_srs epsg:3857 ¥ -tr 2.38865713391 2.38865713391 ¥ src.tif dst-3857-16.tif
- 27. ここでトラブル ○ Windows 64ビット版のgdalwarpで失敗 生成された地図画像の地理範囲がおかしかった ○ 原因等の検討しなかった ○ ○ 32ビットでは使用できるメモリが少ない ○ FreeBSD機で処理してWindows機に戻す ○ gdal2tiles ○ は 32ビット実行 使用メモリが少ない
- 28. 計算にかかった時間 ○ Webメルカトルと正距円筒で2週間かかった 他の処理もあった (背景色修正など) ※ 「それだけ時間がかかるのが理解できない」と思っ た人はリサンプリングをnearで行っていないかチェック して下さい ○ ○ gdal2tiles ○ ○ で1プロセスは必ず遅れた 他のプロセス終了時に50%程度の進捗 原因不明
- 29. 「正攻法」よりは早い ○ 「正攻法」 gdal2tilesを単一プロセスで実行 ○ gdal2tilesでリサンプリングも実行 ○ ○ 倍の速度と見積り ○ 正距円筒で1週間程度の見積り ○ もっと早くなる ○ ○ 手作業を廃すれば FreeBSD機との地図画像転送をなくせば
- 30. 結果(lanczos)
- 31. 結果(near?)
- 41. まとめ ○ 基盤地図と迅速測図の地図タイル画像作成 ○ OSS活用(PostGIS, MapServer, GDAL, GD) ○ 複数プロセス化で時間短縮 ○ こだわりのlanczosは不発気味
- 44. タイルの画像処理 1/2 ○ 透過面で問題2つ ○ Google EarthはPNGがインデックスカラー(パ レット)だと透過してくれない ○ ○ Google Earthさん… optipngが却って仇に ○ gdalwarpでRGBA=(0,0,0,0)がまぎれた ○ ○ (255,255,255,0)とまざるが透過するのでセーフ JPEGにしたとたんアウト
- 45. タイルの画像処理 2/2 ○ 透過部に潜むRGBの確認でGIMPはダメ PNGの背景色よりGIMPの背景色を優先 ○ ImageMagickとかでJPEGに変換するのが吉 ○ ○ 透過部を背景色に統一し、かつインデックス カラーをフルカラーに変更することは可能 ○ ○ ImageMagickを使用 convert –alpha background (src) png32:(dst)