Performances des processus de création de tuiles Google Map

11

Je sais que cette question est plutôt vague, mais veuillez porter avec moi. J'essaie de me faire une idée du type de performance du produit - en particulier du timing - que les gens ont vu pour diverses méthodologies qu'ils ont utilisées pour créer des tuiles de carte google / bing. Il existe une multitude de méthodes pour le faire (par exemple gdal2tiles, FME, maptiler, etc.). Une première tentative de prendre simplement un grand PNG et de créer des tuiles en utilisant imagemagick, sur un serveur Linux assez décent, a produit des temps de traitement assez longs et j'ai donc voulu voir ce que les autres utilisent en production. De nouvelles tuiles devraient être générées au moins quotidiennement et donc le temps de réponse est assez critique.

La seule vraie exigence est qu'il puisse fonctionner sur un serveur Linux. Évidemment, la gratuité c'est mieux mais je ne veux pas me limiter à ça. L'entrée peut être des données maillées / raster brutes ou une grande image. La sortie doit être des tuiles d'image pouvant être utilisées telles quelles dans google ou bing maps.

Juste à des fins de comparaison, je dirai que les horaires doivent être pour le niveau de zoom 7 de google map.

J'apprécie l'aide de tout le monde et je tiens à nouveau à m'excuser de la façon dont cette question semble probablement vague.

MISE À JOUR: En ce qui concerne les entrées, j'ai actuellement plusieurs sources de données (brutes) dans différents formats: netCDF, GRIB, GRIB2. En plus des données brutes elles-mêmes, j'ai également la possibilité de générer de très grandes images de ces données qui pourraient ensuite être découpées / tuilées.

Idéalement, je couperais simplement l'image mais je suis prêt à essayer tout ce qui me permettra d'obtenir les résultats les plus rapides.

google-maps gdal tiles bing-maps optimization malonso
la source
Nous vous recommandons d'utiliser Adobe Fireworks pour optimiser au maximum les images finales que vous utilisez - adobe.com/products/fireworks - même exportées depuis Photoshop puis optimisées dans Fireworks avec des tailles de fichier réduites jusqu'à 75% (png)
Mapperz
@ Mapperz - élaborer sur "optimisé dans Fireworks"?
Derek Swingley
Je pense que vous devez étendre vos entrées et si un traitement supplémentaire est nécessaire ou si vous les coupez simplement.
Ian Turton
4
@Mapperz: L'équivalent gratuit est pngcrush et pngnq pour la quantification. - Je travaille actuellement sur une tâche similaire et j'ai une chaîne automatique gdal2tiles> pngnq> pngcrush> prégénération de miniatures en utilisant imagemagick pour chaque fichier qui est introduit dans le système - je ne peux pas prétendre que ce soit rapide, mais l'automatisation prend beaucoup de charge . Et dans mon cas il n'y a pas de mises à jour, c'est du feu et oubliez.
relancer
1
@relet - Des horaires que vous pouvez transmettre? Quelle est votre configuration matérielle pour cela? Merci
malonso

Réponses:

3

Voici certains de mes résultats pour le fichier raster suivant:

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 pour chaque tuile, 4500 au total]

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

Oui, c'est en quelques minutes - j'ai optimisé la taille de sortie, pas la vitesse. La machine est un Intel Xeon virtuel 2x3GHz, 4G de mémoire. (Et clairement, gdal2tiles pourrait utiliser une certaine parallélisation.)

relouer
la source
L'exemple de fichier est-il disponible pour téléchargement. Je serais ravi
Klokan Technologies GmbH
Désolé, j'ai changé d'emploi entre-temps. Je pourrais probablement savoir où les tuiles sont publiées, mais pas le fichier d'origine.
relouer le
6

Je rencontrais des problèmes pour gdal2tilesprendre un certain temps à traiter un tiff assez grand (380 Mo, 39K x 10K pixels) en tuiles Google pour les plages de zoom 0-12. Sur Ubuntu 12.04 64 bits sans multitraitement, il a fallu à peu près toute la journée (8 heures) pour traiter le tiff en 1,99 million de tuiles @ 3,3 Go. Comme @Stephan Talpalaru le mentionne ci-dessus, faire la gdal2tiles course en parallèle est la clé. Faites une sauvegarde de votre original gdal2tiles.py, puis installez le correctif à partir du répertoire qui abrite gdal2tiles.py(le mien était /usr/local/bin):

$ sudo patch -p0 -i gdal2tiles_parallelize_base_and_overview_tiles.patch

Maintenant, courez gdal2tilescomme vous le faites normalement. J'ai obtenu une augmentation incroyable des performances, avec tous mes 4 cœurs (Intel Core i7 3,4 GHz) indexés:

$ 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

Donc de ~ 8 heures à 39 MINUTES . Changeur de jeu.

Chad Cooper
la source
5

Essayez la version parallèle de gdal2tiles.py: http://trac.osgeo.org/gdal/ticket/4379

Stefan Talpalaru
la source
1
Avez-vous réussi à exécuter la version parallèle sur Windows? J'obtiens des erreurs d'accès aux fichiers sur les fichiers temporaires générés.
Michalis Avraam
2

Vous avez mentionné FME et il y a quelques chiffres sur la création de tuiles de carte sur FMEpedia

C'est un long article, j'ai donc retiré les parties pertinentes:

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

Il s'agit d'un processus multi-machine avec FME Server. Vous pouvez également consulter cet article de Paul Bissett sur le blog WeoGeo: http://www.weogeo.com/blog/Scaling_FME_Engines_on_WeoGeo.html

Il contient un excellent film montrant comment traiter des données comme celle-ci dans le cloud - essentiellement en allumant un tas de machines virtuelles Amazon pour répartir la charge de traitement et le faire très rapidement.

Mark Ireland
la source