Производительность процессов создания плитки карты Google

11

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

Единственным реальным требованием является то, что он может работать на сервере Linux. Очевидно, что бесплатно лучше, но я не хочу ограничиваться этим. Входными данными могут быть необработанные сеточные / растровые данные или большое изображение. Выходными данными должны быть плитки изображений, которые можно использовать как есть на картах Google или Bing.

Просто для сравнения скажу, что сроки должны быть для уровня масштабирования карты Google 7.

Я ценю помощь каждого и снова хочу извиниться за то, насколько расплывчатым кажется этот вопрос.

ОБНОВЛЕНИЕ: Что касается входных данных, в настоящее время у меня есть несколько (необработанных) источников данных в различных форматах: netCDF, GRIB, GRIB2. В дополнение к самим необработанным данным, у меня также есть возможность генерировать действительно большие изображения этих данных, которые затем можно разрезать на фрагменты.

В идеале, я бы просто искал изображение, но я готов попробовать все, что даст мне самые быстрые результаты.

google-maps gdal tiles bing-maps optimization malonso
источник
Рекомендуем использовать Adobe Fireworks для высокой оптимизации конечных изображений, которые вы используете - adobe.com/products/fireworks - даже экспортируемых из Photoshop и затем оптимизированных в Fireworks, уменьшенные размеры файлов до 75% (png)
Mapperz
@ Mapperz - уточните, "оптимизированы ли фейерверки"?
Дерек Суингли
Я думаю, что вам нужно расширить свои входные данные, и если требуется дополнительная обработка или если вы просто их измельчаете.
Ян Тертон
4
@Mapperz: свободный эквивалент pngcrush и pngnq для квантования. - В настоящее время я работаю над аналогичной задачей, и у меня есть автоматическая цепочка gdal2tiles> pngnq> pngcrush>, предварительно создающая миниатюры с использованием imagemagick для каждого файла, который подается в систему - я не могу утверждать, что это быстро, но автоматизация берет на себя много бремени , А в моем случае обновлений нет, это огонь и забудь.
relet
1
@relet - Какие-нибудь моменты вы можете передать? Какая у вас аппаратная настройка для этого? Спасибо
Малонсо

Ответы:

3

Вот некоторые из моих результатов для следующего растрового файла:

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

$ time 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 может использовать некоторую распараллеливание.)

пересдавать
источник
Доступен ли образец файла для скачивания? Я хотел бы сравнить производительность с maptiler.com
Klokan Technologies GmbH
Извините, я поменял работу. Я мог бы, вероятно, узнать, где плитки опубликованы, но не оригинальный файл.
Рет
6

У меня были проблемы с gdal2tilesтем, что мне потребовалось немало времени, чтобы обработать довольно большой (380 МБ, 39K x 10K пикселей) TIFF на плитки Google для диапазонов масштабирования 0-12. На 64-битной Ubuntu 12.04 без многопроцессорной обработки весь день (8 часов) потребовался для обработки tiff до 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как обычно. Я получил невероятное увеличение производительности со всеми четырьмя моими ядрами (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 МИНУТ . Изменитель игры.

Чед Купер
источник
5

Попробуйте параллельную версию gdal2tiles.py: http://trac.osgeo.org/gdal/ticket/4379

Стефан Талпалару
источник
1
У вас был какой-нибудь успех в работе с параллельной версией в Windows? Я получаю ошибки доступа к файлу на сгенерированные временные файлы.
Михалис Авраам
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. Вы также можете проверить это сообщение Пола Биссетта в блоге WeoGeo: http://www.weogeo.com/blog/Scaling_FME_Engines_on_WeoGeo.html

В нем есть отличный фильм, показывающий, как обрабатывать подобные данные в облаке - в основном запускается куча виртуальных машин Amazon, чтобы распределить нагрузку обработки и выполнить ее очень быстро.

Марк Ирландия
источник