Leistung der Erstellungsprozesse für Google Map-Kacheln

Ich weiß, dass diese Frage ziemlich vage ist, aber bitte tragen Sie mich. Ich versuche eine Vorstellung davon zu bekommen, welche Art von Produktleistung - insbesondere Timing - Menschen für verschiedene Methoden gesehen haben, die sie zum Erstellen von Google / Bing-Kartenkacheln verwendet haben. Hierfür gibt es eine Reihe von Methoden (z. B. gdal2tiles, FME, maptiler usw.). Ein erster Versuch, einfach ein großes PNG zu nehmen und Kacheln mit imagemagick auf einem recht anständigen Linux-Server zu erstellen, führte zu ziemlich langen Verarbeitungszeiten, und deshalb wollte ich sehen, was andere Leute in der Produktion verwenden. Neue Kacheln müssten mindestens täglich generiert werden, daher ist die Bearbeitungszeit hierfür ziemlich kritisch.

Die einzige wirkliche Voraussetzung ist, dass es auf einem Linux-Server ausgeführt werden kann. Natürlich ist kostenlos besser, aber ich möchte mich nicht darauf beschränken. Die Eingabe kann rohe Raster- / Rasterdaten oder ein großes Bild sein. Die Ausgabe muss aus Bildkacheln bestehen, die unverändert in Google- oder Bing-Maps verwendet werden können.

Nur zum Vergleich werde ich sagen, dass die Timings für die Zoomstufe 7 von Google Map sein sollten.

Ich schätze die Hilfe aller und möchte mich noch einmal dafür entschuldigen, wie vage diese Frage wahrscheinlich erscheint.

UPDATE: Was die Eingaben betrifft, habe ich derzeit mehrere (Roh-) Datenquellen in verschiedenen Formaten: netCDF, GRIB, GRIB2. Zusätzlich zu den Rohdaten selbst habe ich auch die Möglichkeit, wirklich große Bilder dieser Daten zu generieren, die dann in Scheiben geschnitten / gekachelt werden könnten.

Im Idealfall würde ich nur das Bild zerhacken, aber ich bin bereit zu versuchen, was auch immer mir die schnellsten Ergebnisse bringt.

Hier sind einige meiner Ergebnisse für die folgende Rasterdatei:

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 für jede Kachel, insgesamt 4500]

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

Ja, das ist in Minuten - ich habe für die Ausgabegröße optimiert, nicht für die Geschwindigkeit. Die Maschine ist eine virtuelle Intel Xeon 2x3GHz, 4G Speicher. (Und natürlich könnten gdal2tiles eine gewisse Parallelisierung verwenden.)

Ich hatte Probleme gdal2tiles, eine Weile zu brauchen, um ein ziemlich großes Tiff (380 MB, 39 KB x 10 KB Pixel) in Google-Kacheln für Zoombereiche von 0 bis 12 zu verarbeiten. Unter Ubuntu 12.04 64bit ohne Multiprocessing dauerte es fast den ganzen Tag (8 Stunden), um das TIFF in 1,99 Millionen Kacheln mit 3,3 GB zu verarbeiten. Wie oben bei @Stephan Talpalaru erwähnt, ist es der Schlüssel, gdal2tiles parallel zu laufen . Erstellen Sie eine Sicherungskopie Ihres Originals gdal2tiles.pyund installieren Sie den Patch aus dem Verzeichnis, in dem sich befindet gdal2tiles.py(meins war /usr/local/bin):

$ sudo patch -p0 -i gdal2tiles_parallelize_base_and_overview_tiles.patch

Laufen gdal2tilesSie jetzt wie gewohnt. Ich habe eine unglaubliche Leistungssteigerung erzielt, da alle 4 meiner Kerne (Intel Core i7 3.4GHz) angeschlossen waren:

$ 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

Also von ~ 8 Stunden bis 39 Minuten . Game Changer.

Probieren Sie die parallele Version von gdal2tiles.py aus: http://trac.osgeo.org/gdal/ticket/4379

Sie haben FME erwähnt und es gibt einige Zahlen zum Erstellen von Kartenkacheln in FMEpedia

Es ist ein langer Artikel, also habe ich die relevanten Teile herausgezogen:

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

Hierbei wird ein Prozess mit mehreren Maschinen mit FME Server verwendet. Sie können diesen Beitrag von Paul Bissett auch im WeoGeo-Blog lesen: http://www.weogeo.com/blog/Scaling_FME_Engines_on_WeoGeo.html

Es gibt einen großartigen Film, der zeigt, wie solche Daten in der Cloud verarbeitet werden - im Grunde genommen werden eine Reihe von virtuellen Amazon-Maschinen gestartet, um die Verarbeitungslast zu verteilen und sie sehr schnell zu erledigen.