구글 맵 타일 생성 프로세스의 성능

나는 그 질문이 다소 모호하다는 것을 알고 있지만 w / me를 부담하십시오. 사람들이 Google / bing 맵 타일을 만드는 데 사용한 다양한 방법론에서 어떤 종류의 제품 성능, 특히 타이밍을 보았는지에 대한 아이디어를 얻으려고합니다. 이를 수행하는 방법에는 여러 가지 방법이 있습니다 (예 : gdal2tiles, FME, maptiler 등). 꽤 괜찮은 리눅스 서버에서 단순히 큰 PNG를 가져 와서 imagemagick을 사용하여 타일을 만들려는 초기 시도로 처리 시간이 꽤 길어 졌으므로 다른 사람들이 프로덕션에서 사용하는 것을보고 싶었습니다. 새로운 타일은 최소한 매일 생성해야하므로 처리 시간은 매우 중요합니다.

유일한 실제 요구 사항은 Linux 서버에서 실행할 수 있다는 것입니다. 분명히, 자유가 더 나아지지만 나는 그것에 국한하고 싶지 않습니다. 입력은 원시 그리드 / 래스터 데이터 또는 큰 이미지 일 수 있습니다. 출력은 Google 또는 bing 맵에서 그대로 사용할 수있는 이미지 타일이어야합니다.

비교를 위해 타이밍은 Google지도의 확대 / 축소 수준 7이어야한다고 말하겠습니다.

모든 사람의 도움에 감사 드리며이 질문이 어떻게 모호하게 보일지 사과드립니다.

업데이트 : 입력에 관해서는 현재 netCDF, GRIB, GRIB2와 같은 다양한 형식의 여러 (원시) 데이터 소스가 있습니다. 원시 데이터 자체 외에도 슬라이스 / 타일링 할 수있는 해당 데이터의 실제로 큰 이미지를 생성 할 수 있습니다.

이상적으로는 이미지를 자르고 있지만 가장 빠른 결과를 얻을 수있는 모든 것을 기꺼이 시도합니다.

다음 래스터 파일에 대한 결과 중 일부는 다음과 같습니다.

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

$ 시간 [모든 타일에 대한 pngnq && pngcrush, 총 4500 개]

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

그렇습니다. 몇 분 만에 속도가 아닌 출력 크기에 최적화되었습니다. 머신은 가상 Intel Xeon 2x3GHz, 4G 메모리입니다. (그리고 분명히 gdal2tiles는 병렬화를 사용할 수 있습니다.)

gdal2tiles확대 / 축소 범위 0-12의 Google 타일에서 상당히 큰 (380MB, 39K x 10K 픽셀) 크기를 처리하는 데 시간이 오래 걸리는 문제가있었습니다 . 다중 처리없이 Ubuntu 12.04 64 비트에서 tiff를 3.3GB @ 190 만 타일로 처리하는 데 하루 종일 (8 시간) 걸렸습니다. 위의 @Stephan Talpalaru와 같이 gdal2tiles 병렬 로 실행하는 것이 핵심입니다. 원본을 백업 gdal2tiles.py한 다음 보관소 (mine was ) 가 있는 디렉토리에서 패치 를 설치 하십시오 .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 분까지 입니다. 게임 체인저.

병렬 버전의 gdal2tiles.py를 사용해보십시오 : http://trac.osgeo.org/gdal/ticket/4379

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에서 다중 머신 프로세스를 사용하고 있습니다. Paul Bissett의 WeoGeo 블로그 ( http://www.weogeo.com/blog/Scaling_FME_Engines_on_WeoGeo.html) 에서이 게시물을 확인할 수도 있습니다 .

클라우드에서 이와 같은 데이터를 처리하는 방법을 보여주는 훌륭한 영화가 있습니다. 기본적으로 많은 Amazon 가상 머신을 실행하여 처리 부하를 분산시키고 매우 빠르게 처리합니다.