Продуктивність процесів створення плиток google map

Я знаю, що питання досить розпливчасте, але будь ласка, майте на увазі мене. Я намагаюся скласти уявлення про те, яку продуктивність продукту - конкретно про терміни - люди бачили за різними методологіями, якими вони користувалися для створення плиток карти Google / bing. Існує низка методів, як це зробити (наприклад, gdal2tiles, FME, maptiler тощо). Початкова спроба просто взяти великий PNG та створити плитки за допомогою imagemagick на досить пристойному сервері Linux дала досить тривалий час обробки, і тому я хотів побачити, що інші люди використовують у виробництві. Нові плитки потрібно генерувати щонайменше щодня, і тому час повороту щодо цього є досить важливим.

Єдина реальна вимога - вона може працювати на сервері Linux. Очевидно, що безкоштовно - це краще, але я не хочу обмежуватися цим. Вхідними даними можуть бути сирі / растрові дані або велике зображення. Вихідні дані повинні бути плитковими зображеннями, які можуть використовуватися як в google, так і в бінг-картах.

Тільки заради порівняння я скажу, що терміни повинні відповідати рівню масштабування google map 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витрачанням досить тривалого часу на обробку досить великого (380 МБ, 39 К х 10 К пікселів) тифів у плитки Google для діапазону масштабування 0-12. На 64-бітній Ubuntu 12.04 без багатопроцесорної обробки було потрібно майже весь день (8 годин), щоб обробити тиф на 1,99 мільйона плиток при 3,3 ГБ. Як згадує @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,4 ГГц):

$ 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. Ви також можете ознайомитись із цим дописом Полом Біссеттом у блозі WeoGeo: http://www.weogeo.com/blog/Scaling_FME_Engines_on_WeoGeo.html

У ньому є чудовий фільм, який показує, як обробляти подібні дані у хмарі - в основному вистрілюючи купу віртуальних машин Amazon, щоб розповсюдити навантаження на обробку та зробити це дуже швидко.