Kinerja proses pembuatan ubin peta google

11

Saya tahu bahwa pertanyaan itu agak kabur tetapi tolong beri saya. Saya mencoba untuk mendapatkan gambaran tentang kinerja produk seperti apa - khususnya pengaturan waktu - yang telah dilihat orang untuk berbagai metodologi yang mereka gunakan untuk membuat ubin peta google / bing. Ada beberapa metode untuk melakukan hal ini (mis. Gdal2tiles, FME, maptiler, dll). Upaya awal hanya mengambil PNG besar dan membuat ubin menggunakan imagemagick, pada server linux yang lumayan, menghasilkan beberapa waktu pemrosesan yang cukup lama dan jadi saya ingin melihat apa yang orang lain gunakan dalam produksi. Ubin baru perlu dihasilkan setidaknya setiap hari dan waktu penyelesaian hal ini sangat penting.

Satu-satunya persyaratan nyata adalah dapat dijalankan di server linux. Jelas, gratis lebih baik tetapi saya tidak ingin membatasi diri saya untuk itu. Input dapat berupa data grid / raster mentah atau gambar besar. Keluaran harus berupa ubin gambar yang dapat digunakan apa adanya di google atau di peta.

Hanya sebagai perbandingan, saya akan mengatakan bahwa waktunya harus untuk tingkat zoom peta google 7.

Saya menghargai bantuan semua orang dan sekali lagi saya ingin meminta maaf atas betapa kaburnya pertanyaan ini.

UPDATE: Sejauh input, saya saat ini memiliki beberapa sumber data (mentah) dalam berbagai format: netCDF, GRIB, GRIB2. Selain data mentah itu sendiri, saya juga memiliki kemampuan untuk menghasilkan gambar yang sangat besar dari data itu yang kemudian dapat diiris / ubin.

Idealnya, saya hanya akan memotong gambar tetapi saya bersedia mencoba apa pun yang akan memberi saya hasil tercepat.

google-maps gdal tiles bing-maps optimization malonso
sumber
Rekomendasikan Anda menggunakan Adobe fireworks untuk mengoptimalkan gambar akhir yang Anda gunakan - adobe.com/products/fireworks - bahkan diekspor dari Photoshop dan kemudian dioptimalkan dalam Fireworks mengurangi ukuran file hingga 75% (png)
Mapperz
@ Mapperz- menguraikan "dioptimalkan dalam Fireworks"?
Derek Swingley
Saya pikir Anda perlu memperluas input Anda dan jika diperlukan lebih banyak pemrosesan atau jika Anda hanya memotongnya.
Ian Turton
4
@Mapperz: Setara gratis adalah pngcrush dan pngnq untuk kuantisasi. - Saat ini saya mengerjakan tugas yang sama dan memiliki rantai otomatis gdal2tiles> pngnq> pngcrush> thumbnail pregenerasi menggunakan imagemagick untuk setiap file yang dimasukkan ke dalam sistem - Saya tidak dapat mengklaimnya cepat, tetapi otomatisasi mengambil banyak beban . Dan dalam kasus saya tidak ada pembaruan, itu api dan lupakan.
Relet
1
@relet - Adakah timing yang bisa Anda sampaikan? Apa pengaturan perangkat keras Anda untuk ini? Terima kasih
malonso

Jawaban:

3

Berikut adalah beberapa hasil saya untuk file raster berikut:

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

$ waktu 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 untuk setiap ubin, totalnya 4.500]

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

Yup, itu dalam hitungan menit - saya dioptimalkan untuk ukuran output, bukan kecepatan. Mesin tersebut adalah Intel Xeon virtual 2x3GHz, memori 4G. (Dan jelas, gdal2tiles dapat memanfaatkan beberapa paralelisasi.)

relet
sumber
Apakah file sampel tersedia untuk diunduh. Saya ingin membandingkan kinerja dengan maptiler.com
Klokan Technologies GmbH
Maaf, saya berganti pekerjaan sementara itu. Saya mungkin bisa mencari tahu di mana ubin diterbitkan, tetapi bukan file aslinya.
Relet
6

Saya mengalami masalah dengan gdal2tileswaktu yang cukup lama untuk memproses tiff yang cukup besar (380MB, 39K x 10K piksel) ke ubin Google untuk rentang zoom 0-12. Di Ubuntu 12,04 64bit tanpa multiprosesor, hanya dibutuhkan sepanjang hari (8 jam) untuk memproses tiff menjadi 1,99 juta ubin @ 3,3GB. Seperti @Stephan Talpalaru disebutkan di atas, gdal2tiles menjalankan secara paralel adalah kuncinya. Buat cadangan asli Anda gdal2tiles.py, lalu instal tambalan dari dalam direktori yang menampung gdal2tiles.py(milik saya /usr/local/bin):

$ sudo patch -p0 -i gdal2tiles_parallelize_base_and_overview_tiles.patch

Sekarang jalankan gdal2tilesseperti biasa. Saya mendapat peningkatan kinerja yang luar biasa, dengan keempat inti saya (Intel Core i7 3.4GHz) dipatok:

$ 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

Jadi dari ~ 8 jam hingga 39 MENIT . Pengubah game.

Chad Cooper
sumber
5

Coba versi paralel dari gdal2tiles.py: http://trac.osgeo.org/gdal/ticket/4379

Stefan Talpalaru
sumber
1
Apakah Anda berhasil menjalankan versi paralel pada Windows? Saya mendapatkan kesalahan akses file pada file temp yang dihasilkan.
Michalis Avraam
2

Anda menyebutkan FME dan ada beberapa nomor untuk membuat petak peta di FMEpedia

Artikel yang panjang, jadi saya mengeluarkan bagian-bagian yang relevan:

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

Ini menggunakan proses multi-mesin dengan Server FME. Anda juga dapat melihat posting ini oleh Paul Bissett di blog WeoGeo: http://www.weogeo.com/blog/Scaling_FME_Engines_on_WeoGeo.html

Ini memiliki film yang bagus yang menunjukkan bagaimana memproses data seperti ini di cloud - pada dasarnya meluncurkan banyak mesin virtual Amazon untuk menyebarkan beban pemrosesan dan menyelesaikannya dengan sangat cepat.

Tandai Irlandia
sumber