Google Map Tile创建过程的性能

11

我知道这个问题很模糊，但是请耐心等待。我试图弄清什么样的产品性能-特别是时间-人们已经看到了他们用来创建google / bing地图图块的各种方法。有很多方法可以做到这一点（例如，gdal2tiles，FME，maptiler等）。最初尝试仅使用大型PNG并在相当不错的linux服务器上使用imagemagick创建图块，却产生了相当长的处理时间，因此我想看看其他人在生产中使用了什么。新的图块至少需要每天生成一次，因此周转时间非常关键。

唯一真正的要求是它可以在linux服务器上运行。显然，自由是更好的选择，但我不想局限于此。输入可以是原始栅格化/栅格数据或大图像。输出必须是能够在Google或必应地图中按原样使用的图像图块。

只是为了比较，我会说时间应该是针对Google地图的缩放级别7。

我感谢每个人的帮助，对于这个问题可能看起来有多模糊，我再次表示歉意。

更新：就输入而言，我目前有多种格式的（原始）数据源：netCDF，GRIB，GRIB2。除了原始数据本身之外，我还能够生成该数据的非常大的图像，然后可以对其进行切片/平铺。

理想情况下，我只是将图像切碎，但我愿意尝试任何可以使我获得最快结果的方法。

— 马隆索
source

建议您使用Adobe fireworks对正在使用的最终图像进行高度优化-adobe.com/products/fireworks-甚至从Photoshop导出，然后在Fireworks中进行优化，减小的文件大小最多可减少75％（png）

— Mapperz

@ Mapperz-详细介绍“在Fireworks中优化”吗？

— Derek Swingley 2011年

我认为您需要扩展您的输入，是否需要更多处理或只是将它们切碎。

— 伊恩·特顿

4

@Mapperz：免费等效的是pngcrush和pngnq进行量化。-我目前正在执行类似的任务，并且有一个自动链gdal2tiles> pngnq> pngcrush>使用imagemagick为输入到系统中的每个文件预生成缩略图-我不能声称它很快，但是自动化会带来很多负担。就我而言，没有任何更新，这是一发不可收拾。

— 载入

1

@relet-您可以传递任何时间？您对此的硬件设置是什么？谢谢

— malonso

3

以下是以下栅格文件的一些结果：

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

$时间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

$ time [每个图块的pngnq && pngcrush，总共4500个]

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

是的，只需几分钟-我针对输出大小（而非速度）进行了优化。该机器是虚拟的Intel Xeon 2x3GHz，4G内存。（显然，gdal2tiles可以利用一些并行化。）

— 重新开始
source

样本文件是否可供下载。我希望与maptiler.com

— Klokan Technologies GmbH

抱歉，在此期间我换了工作。我可能会发现磁贴的发布位置，而不是原始文件。

— 转租

6

我在gdal2tiles花相当长的时间将相当大的（380MB，39K x 10K像素）tiff处理到Google磁贴中以获得0-12缩放范围时遇到问题。在没有进行多处理的Ubuntu 12.04 64bit上，花了整整一天（8个小时）的时间将tiff处理为199万个磁贴@ 3.3GB。就像上面提到的@Stephan Talpalaru一样gdal2tiles ，并行运行是关键。备份原始文件gdal2tiles.py，然后从存放目录（我的原为）中安装补丁：gdal2tiles.py/usr/local/bin

$ sudo patch -p0 -i gdal2tiles_parallelize_base_and_overview_tiles.patch

现在像平常一样运行gdal2tiles。我的所有4个核心（英特尔酷睿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分钟。改变游戏规则的人。

— 乍得·库珀
source

5

尝试gdal2tiles.py水货版本：http://trac.osgeo.org/gdal/ticket/4379

— 斯蒂芬·塔帕拉鲁（Stefan Talpalaru）
source

1

在Windows上运行并行版本是否成功？我在生成的临时文件上遇到文件访问错误。

— Michalis Avraam

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 Server一起使用多机处理。您也可以在WeoGeo博客上查看Paul Bissett的这篇文章：http : //www.weogeo.com/blog/Scaling_FME_Engines_on_WeoGeo.html

它有一部很棒的电影，展示了如何在云中处理此类数据-基本上是启动一堆Amazon虚拟机来分散处理负载并非常快地完成它。

— 马克·爱尔兰
source