Googleマップタイル作成プロセスのパフォーマンス

11

私は質問がかなり曖昧であることを知っていますが、w / meを負担してください。私は、Google / Bingマップタイルを作成するために使用したさまざまな方法論について、人々がどのような製品パフォーマンス（特にタイミング）を見てきたかを把握しようとしています。これを実行する方法は多数あります（gdal2tiles、FME、maptilerなど）。まともなLinuxサーバー上で、単に大きなPNGを取得し、imagemagickを使用してタイルを作成するという最初の試みでは、かなり長い処理時間が生じました。新しいタイルは少なくとも毎日生成する必要があるため、これに要する時間は非常に重要です。

唯一の実際の要件は、Linuxサーバーで実行できることです。明らかに、無料の方が良いのですが、私はそれだけに制限したくありません。入力には、生のグリッド/ラスターデータまたは大きな画像を使用できます。出力は、GoogleまたはBingマップでそのまま使用できる画像タイルである必要があります。

比較のためだけに、タイミングはGoogleマップのズームレベル7に合わせるべきだと言います。

皆様のご協力に感謝します。この質問がいかに曖昧であるかをおaび申し上げます。

更新：入力に関しては、現在、NetCDF、GRIB、GRIB2などのさまざまな形式の複数の（生の）データソースがあります。生データ自体に加えて、そのデータの非常に大きな画像を生成し、その画像をスライス/タイル化することもできます。

理想的には、画像を切り刻むだけですが、最速の結果が得られるものであれば何でも試してみたいと思います。

google-maps  gdal  tiles  bing-maps  optimization 
— マロンソ
ソース
-あなたは非常にあなたが使用している最後の画像最適化するためのAdobeの花火を使用することをお勧めadobe.com/products/fireworks -でも、ファイルは75％（PNG）までのサイズ縮小FireworksでのPhotoshopからエクスポートして、最適化された
— Mapperz
@ Mapperz-「Fireworksで最適化」について詳しく説明してください。
— デレクスウィングレー
入力を拡張する必要があると思います。さらに処理が必要な場合、または単に切り詰める場合。
— イアンタートン
4
@Mapperz：量子化のための無料の同等物はpngcrushとpngnqです。-現在、同様のタスクに取り組んでおり、自動チェーンgdal2tiles> pngnq> pngcrush>システムにフィードされるすべてのファイルに対してimagemagickを使用してサムネイルを事前生成しています-高速であるとは言えませんが、自動化には多くの負担がかかります。そして、私の場合、更新はありません、それは火事であり忘れています。
— relet
1
@relet-引き継ぐことができるタイミングはありますか？このためのハードウェア設定は何ですか？ありがとう
— マロンソ

回答:

3

以下は、次のラスターファイルに対する私の結果の一部です。

JPEG 14456x14490 14456x14490+0+0 DirectClass 62mb

$ time gdal2tiles [...]

Generating Base Tiles:
0...10...20...30...40...50...60...70...80...90...100 - done.
Generating Overview Tiles:
0...10...20...30...40...50...60...70...80...90...100 - done.

real    5m7.675s
user    5m5.070s
sys  0m2.060s

$時間[すべてのタイルのpngnq && pngcrush、合計4500]

real    9m32.827s
user    18m34.190s
sys  0m27.230s

うん、それは数分で-速度ではなく出力サイズに最適化されました。マシンは、仮想Intel Xeon 2x3GHz、4Gのメモリです。（そして明らかに、gdal2tilesは並列化を利用できます。）

— リレ
ソース
サンプルファイルをダウンロードできますか。パフォーマンスをmaptiler.com
— Klokan Technologies GmbH
申し訳ありませんが、その間に職を変えました。おそらく、タイルが公開されている場所を見つけることができましたが、元のファイルは見つかりませんでした。
— relet
6

gdal2tiles0〜12のズーム範囲でかなり大きい（380MB、39K x 10Kピクセル）TIFFをGoogleタイルに処理するのにかなり時間がかかるという問題がありました。マルチプロセッシングなしのUbuntu 12.04 64ビットでは、TIFFを3.3GBで199万タイルに処理するのにほぼ1日（8時間）かかりました。@Stephan Talpalaruが上記で言及したように、gdal2tiles 並行して実行することが重要です。オリジナルのバックアップを作成しgdal2tiles.py、それが格納されているディレクトリ内からパッチをインストールしますgdal2tiles.py（私の場合は/usr/local/bin）：

$ sudo patch -p0 -i gdal2tiles_parallelize_base_and_overview_tiles.patch

これでgdal2tiles、通常どおりに実行できます。4つのコアすべて（Intel Core i7 3.4GHz）が固定され、パフォーマンスが驚くほど向上しました。

$ time gdal2tiles.py -p raster -z 0-12 -w none ds1105-2235df023_23_b.tif gdal-tiles12
Generating Base Tiles:
0...10...20...30...40...50...60...70...80...90...100 - done.
Generating Overview Tiles:
0...10...20...30...40...50...60...70...80...90...100 - done.

real    39m8.242s
user    104m6.808s
sys 9m16.036s

だから〜8時間から39分まで。ゲームチェンジャー。

— チャド・クーパー
ソース
2

FMEに言及しましたが、FMEpediaでマップタイルを作成する際にいくつかの数字があります

長い記事なので、関連する部分を抜粋しました。

Level             Tiles           Minutes (hours)
    8            24,500           18 (0.3)
   10           245,000          105 (1.75)
   11         1,000,000          384 (6.4)

これは、FMEサーバーでマルチマシンプロセスを使用しています。WeoGeoブログのPaul Bissettによるこの投稿もご覧ください：http ://www.weogeo.com/blog/Scaling_FME_Engines_on_WeoGeo.html

クラウドでこのようなデータを処理する方法を示す優れたムービーがあります-基本的に、多数のAmazon仮想マシンを起動して処理負荷を分散し、非常に迅速に処理します。

— マーク・アイルランド
ソース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.