Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie 大規模タイル画像を生成した話（（独）農研機構 寺元郁博様）
Ähnlich wie 大規模タイル画像を生成した話（（独）農研機構 寺元郁博様） (6)
Mehr von OSgeo Japan
Mehr von 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)