Rendimiento de los procesos de creación de mosaicos de google map

11

Sé que esa pregunta es bastante vaga, pero por favor tengan paciencia conmigo. Estoy tratando de tener una idea de qué tipo de rendimiento del producto, específicamente el tiempo, las personas han visto para diversas metodologías que han utilizado para crear mosaicos de mapas de google / bing. Existen varios métodos para hacerlo (por ejemplo, gdal2tiles, FME, maptiler, etc.). Un intento inicial de simplemente tomar un PNG grande y crear mosaicos usando imagemagick, en un servidor Linux bastante decente, arrojó algunos tiempos de procesamiento bastante largos, por lo que quería ver qué usan otras personas en la producción. Sería necesario generar nuevos mosaicos al menos diariamente, por lo que el tiempo de respuesta es bastante crítico.

El único requisito real es que puede ejecutarse en un servidor Linux. Obviamente, gratis es mejor, pero no quiero limitarme a eso. La entrada puede ser datos de cuadrícula / ráster sin procesar o una imagen grande. La salida debe ser mosaicos de imágenes capaces de usarse tal cual en google o bing maps.

Solo por el bien de la comparación, diré que los tiempos deben ser para el nivel de zoom 7 del mapa de Google.

Aprecio la ayuda de todos y nuevamente quiero disculparme por lo vago que parece esta pregunta.

ACTUALIZACIÓN: En cuanto a las entradas, actualmente tengo múltiples fuentes de datos (en bruto) en varios formatos: netCDF, GRIB, GRIB2. Además de los datos en bruto en sí, también tengo la capacidad de generar imágenes realmente grandes de esos datos que luego podrían dividirse en mosaicos.

Idealmente, solo estaría cortando la imagen, pero estoy dispuesto a intentar lo que sea que me dé los resultados más rápidos.

google-maps gdal tiles bing-maps optimization malonso
fuente
Recomiendo que use Adobe Fireworks para optimizar las imágenes finales que está utilizando - adobe.com/products/fireworks - incluso exportado desde Photoshop y luego optimizado en Fireworks redujo los tamaños de archivo hasta un 75% (png)
Mapperz
@ Mapperz- elabora sobre "optimizado en Fireworks"?
Derek Swingley
Creo que necesita expandir su (s) entrada (s) y si se necesita más procesamiento o si solo los está cortando.
Ian Turton
44
@Mapperz: El equivalente gratuito es pngcrush y pngnq para la cuantización. - Actualmente trabajo en una tarea similar y tengo una cadena automática gdal2tiles> pngnq> pngcrush> pregenerando miniaturas usando imagemagick para cada archivo que se introduce en el sistema - No puedo afirmar que sea rápido, pero la automatización conlleva una gran carga . Y en mi caso no hay actualizaciones, es disparar y olvidar.
relet
1
@relet - ¿Alguna oportunidad que puedas pasar? ¿Cuál es su configuración de hardware para esto? Gracias
malonso

Respuestas:

3

Estos son algunos de mis resultados para el siguiente archivo ráster:

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 por cada ficha, 4500 en total]

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

Sí, eso es en minutos: optimicé el tamaño de salida, no la velocidad. La máquina es una Intel Xeon virtual de 2x3GHz, 4G de memoria. (Y claramente, gdal2tiles podría hacer uso de cierta paralelización).

realquilar
fuente
Es el archivo de muestra disponible para descargar. Me gustaría comparar el rendimiento con maptiler.com
Klokan Technologies GmbH
Lo siento, mientras tanto cambié de trabajo. Probablemente podría averiguar dónde se publican los mosaicos, pero no el archivo original.
relet
6

Estaba teniendo problemas para gdal2tilestomar bastante tiempo para procesar un tiff bastante grande (380MB, 39K x 10K píxeles) en los mosaicos de Google para rangos de zoom 0-12. En Ubuntu 12.04 de 64 bits sin multiprocesamiento, tomó casi todo el día (8 horas) procesar el tiff en 1.99 millones de mosaicos a 3.3GB. Como @Stephan Talpalaru menciona anteriormente, hacer la gdal2tiles carrera en paralelo es la clave. Haga una copia de seguridad de su original gdal2tiles.py, luego instale el parche desde el directorio que alberga gdal2tiles.py(el mío era /usr/local/bin):

$ sudo patch -p0 -i gdal2tiles_parallelize_base_and_overview_tiles.patch

Ahora corre gdal2tilescomo lo haces normalmente. Obtuve un aumento increíble en el rendimiento, con mis 4 núcleos (Intel Core i7 3.4GHz) vinculados:

$ 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

Entonces, de ~ 8 horas a 39 MINUTOS . Cambiador de juego.

Chad Cooper
fuente
5

Pruebe la versión paralela de gdal2tiles.py: http://trac.osgeo.org/gdal/ticket/4379

Stefan Talpalaru
fuente
1
¿Tuviste algún éxito al ejecutar la versión paralela en Windows? Obtengo errores de acceso a los archivos temporales generados.
Michalis Avraam
2

Usted mencionó FME y hay algunos números sobre la creación de mosaicos de mapas en FMEpedia

Es un artículo largo, así que saqué las partes relevantes:

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

Esto está utilizando un proceso de múltiples máquinas con el servidor FME. También puede consultar esta publicación de Paul Bissett en el blog de WeoGeo: http://www.weogeo.com/blog/Scaling_FME_Engines_on_WeoGeo.html

Tiene una gran película que muestra cómo procesar datos como este en la nube, básicamente disparando un montón de máquinas virtuales de Amazon para distribuir la carga de procesamiento y hacerlo muy rápidamente.

Mark Ireland
fuente