Hiệu suất của quá trình tạo gạch bản đồ google


11

Tôi biết câu hỏi đó khá mơ hồ nhưng xin vui lòng chịu đựng tôi. Tôi đang cố gắng để có được ý tưởng về loại hiệu suất sản phẩm - cụ thể là thời gian - mọi người đã thấy các phương pháp khác nhau mà họ đã sử dụng để tạo các lát bản đồ google / bing. Có một loạt các phương pháp để làm điều này (ví dụ gdal2tiles, FME, maptiler, v.v.). Một nỗ lực ban đầu chỉ đơn giản là lấy một PNG lớn và tạo các ô bằng cách sử dụng hình ảnh, trên một máy chủ linux khá tốt, mang lại một số thời gian xử lý khá dài và vì vậy tôi muốn xem những gì người khác đang sử dụng trong sản xuất. Gạch mới sẽ cần phải được tạo ra ít nhất là hàng ngày và vì vậy thời gian quay vòng trên này là khá quan trọng.

Yêu cầu thực sự duy nhất là nó có thể chạy trên máy chủ linux. Rõ ràng, miễn phí là tốt hơn nhưng tôi không muốn hạn chế điều đó. Đầu vào có thể là dữ liệu thô / dữ liệu raster hoặc hình ảnh lớn. Đầu ra cần phải là các ô hình ảnh có khả năng được sử dụng như trong google hoặc bing maps.

Chỉ để so sánh, tôi sẽ nói rằng thời gian nên dành cho mức thu phóng 7 của google map.

Tôi đánh giá cao sự giúp đỡ của mọi người và một lần nữa tôi muốn xin lỗi vì câu hỏi này có vẻ mơ hồ như thế nào.

CẬP NHẬT: Theo như các đầu vào, tôi hiện có nhiều nguồn dữ liệu (thô) ở các định dạng khác nhau: netCDF, GRIB, GRIB2. Ngoài dữ liệu thô, tôi cũng có khả năng tạo ra hình ảnh thực sự lớn của dữ liệu đó sau đó có thể được cắt / lát.

Lý tưởng nhất là tôi sẽ cắt hình ảnh lên nhưng tôi sẵn sàng thử bất cứ điều gì sẽ giúp tôi có kết quả nhanh nhất.


Đề nghị bạn sử dụng pháo hoa Adobe để tối ưu hóa cao những hình ảnh cuối cùng bạn đang sử dụng - adobe.com/products/fireworks - thậm chí được xuất từ ​​Photoshop và sau đó được tối ưu hóa trong Fireworks giảm kích thước tệp lên tới 75% (png)
Mapperz

@ Mapperz- giải thích chi tiết về "tối ưu hóa trong pháo hoa"?
Derek Swingley

Tôi nghĩ rằng bạn cần mở rộng (các) đầu vào của mình và nếu cần xử lý nhiều hơn hoặc nếu bạn chỉ cắt chúng ra.
Ian Turton

4
@Mapperz: Tương đương miễn phí là pngcrush và pngnq cho lượng tử hóa. - Tôi hiện đang làm việc với một nhiệm vụ tương tự và có một chuỗi tự động gdal2tiles> pngnq> pngcrush> tạo hình thu nhỏ bằng cách sử dụng hình ảnh cho mọi tệp được đưa vào hệ thống - Tôi không thể cho rằng nó nhanh, nhưng việc tự động hóa phải chịu rất nhiều gánh nặng . Và trong trường hợp của tôi không có bản cập nhật, nó sẽ cháy và quên đi.
tái lập

1
@relet - Bạn có thể vượt qua thời gian nào không? Thiết lập phần cứng của bạn cho việc này là gì? Cảm ơn
malonso

Câu trả lời:


3

Dưới đây là một số kết quả của tôi cho tệp raster sau:

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

$ thời gian 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 cho mỗi ô, tổng cộng 4500]

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

Yup, đó là trong vài phút - Tôi đã tối ưu hóa cho kích thước đầu ra, không phải tốc độ. Máy là bộ nhớ ảo Intel Xeon 2x3GHz, bộ nhớ 4G. (Và rõ ràng, gdal2tiles có thể sử dụng một số song song.)


Là tập tin mẫu có sẵn để tải về. Tôi rất muốn so sánh hiệu suất với maptiler.com
Klokan Technologies GmbH

Xin lỗi, tôi đã thay đổi công việc trong thời gian đó. Tôi có thể tìm ra nơi gạch được xuất bản, nhưng không phải là tập tin gốc.
phát lại

6

Tôi đã gặp vấn đề với gdal2tilesviệc mất khá nhiều thời gian để xử lý một tiff khá lớn (380MB, 39K x 10K pixel) vào các ô của Google cho phạm vi thu phóng 0-12. Trên Ubuntu 12.04 64 bit mà không cần đa xử lý, chỉ mất khoảng cả ngày (8 giờ) để xử lý tiff thành 1.99 triệu gạch @ 3.3GB. Giống như @Stephan Talpalaru đã đề cập ở trên, thực hiện gdal2tiles chạy song song là chìa khóa. Tạo một bản sao lưu của bản gốc của bạn gdal2tiles.py, sau đó cài đặt bản vá từ trong thư mục chứa gdal2tiles.py(của tôi /usr/local/bin):

$ sudo patch -p0 -i gdal2tiles_parallelize_base_and_overview_tiles.patch

Bây giờ chạy gdal2tilesnhư bạn thường làm. Tôi đã tăng hiệu suất đáng kinh ngạc, với tất cả 4 lõi của tôi (Intel Core i7 3,4GHz) được chốt:

$ 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

Vì vậy, từ ~ 8 giờ đến 39 PHÚT . Người thay đổi trò chơi.



2

Bạn đã đề cập đến FME và có một số con số về việc tạo các ô bản đồ trên FMEpedia

Đó là một bài viết dài, vì vậy tôi đã rút ra những phần có liên quan:

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

Đây là sử dụng quy trình nhiều máy với FME Server. Bạn cũng có thể xem bài đăng này của Paul Bissett trên blog WeoGeo: http://www.weogeo.com/blog/Scaling_FME_Engines_on_WeoGeo.html

Nó có một bộ phim tuyệt vời cho thấy cách xử lý dữ liệu như thế này trên đám mây - về cơ bản bắn ra một loạt các máy ảo Amazon để truyền tải tải xử lý và hoàn thành nó rất nhanh.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.