Prestazioni dei processi di creazione delle tessere google map


11

So che questa domanda è piuttosto vaga ma per favore abbi pazienza. Sto cercando di farmi un'idea di quale tipo di prestazioni del prodotto - in particolare i tempi - le persone hanno visto per varie metodologie che hanno usato per creare tessere google / bing map. Esistono molti metodi per eseguire questa operazione (ad es. Gdal2tiles, FME, maptiler, ecc.). Un tentativo iniziale di prendere semplicemente un grande PNG e creare tessere usando imagemagick, su un server Linux abbastanza decente, ha prodotto tempi di elaborazione piuttosto lunghi e quindi volevo vedere cosa usano gli altri in produzione. Le nuove tessere dovrebbero essere generate almeno quotidianamente e quindi i tempi di risposta sono piuttosto critici.

L'unico vero requisito è che può essere eseguito su un server Linux. Ovviamente, la libertà è migliore ma non voglio limitarmi a questo. L'input può essere dati grezzi con griglia / raster o un'immagine di grandi dimensioni. L'output deve essere riquadri immagine che possono essere utilizzati così come sono in google o bing maps.

Solo per motivi di confronto, dirò che i tempi dovrebbero essere per il livello di zoom 7 di google map.

Apprezzo l'aiuto di tutti e di nuovo voglio scusarmi per quanto vaga questa domanda sembri.

AGGIORNAMENTO: Per quanto riguarda gli input, attualmente ho più fonti di dati (non elaborate) in vari formati: netCDF, GRIB, GRIB2. Oltre ai dati grezzi stessi, ho anche la possibilità di generare immagini molto grandi di quei dati che potrebbero essere suddivise / affiancate.

Idealmente, taglierei semplicemente l'immagine, ma sono disposto a provare qualunque cosa mi dia i risultati più veloci.


Ti consiglio di utilizzare Adobe Fireworks per ottimizzare le immagini finali che stai utilizzando - adobe.com/products/fireworks - anche esportato da Photoshop e ottimizzato in Fireworks con dimensioni del file ridotte fino al 75% (png)
Mapperz

@ Mapperz- elaborato su "ottimizzato in Fireworks"?
Derek Swingley,

Penso che devi espandere i tuoi input e se è necessaria una maggiore elaborazione o se li stai semplicemente tagliando.
Ian Turton

4
@Mapperz: l'equivalente gratuito è pngcrush e pngnq per la quantizzazione. - Attualmente lavoro su un compito simile e ho una catena automatica gdal2tiles> pngnq> pngcrush> anteprime di pregenerazione usando imagemagick per ogni file che viene inserito nel sistema - Non posso affermare che sia veloce, ma l'automazione prende molto onere . E nel mio caso non ci sono aggiornamenti, è fuoco e dimentica.
Rilasciato il

1
@relet - Qualche tempistica che puoi trasmettere? Qual è la tua configurazione hardware per questo? Grazie
Malonso,

Risposte:


3

Ecco alcuni dei miei risultati per il seguente file raster:

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 per ogni riquadro, 4500 in totale]

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

Sì, è in pochi minuti: ho ottimizzato per le dimensioni dell'output, non per la velocità. La macchina è un Intel Xeon virtuale 2x3GHz, 4G di memoria. (E chiaramente, gdal2tiles potrebbe fare uso di un po 'di parallelismo.)


Il file di esempio è disponibile per il download. Mi piacerebbe confrontare le prestazioni con maptiler.com
Klokan Technologies GmbH,

Spiacente, nel frattempo ho cambiato lavoro. Potrei probabilmente scoprire dove sono pubblicate le tessere, ma non il file originale.
Rilasciato il

6

Avevo problemi a gdal2tilesimpiegare un po 'di tempo per elaborare un tiff abbastanza grande (380 MB, 39 K x 10 K pixel) nei riquadri di Google per intervalli di zoom 0-12. Su Ubuntu 12.04 a 64 bit senza elaborazione multipla è stato impiegato quasi tutto il giorno (8 ore) per elaborare il tiff in 1,99 milioni di riquadri a 3,3 GB. Come menziona @Stephan Talpalaru sopra, gdal2tiles correre in parallelo è la chiave. Fai un backup del tuo originale gdal2tiles.py, quindi installa la patch dalla directory che ospita gdal2tiles.py(la mia era /usr/local/bin):

$ sudo patch -p0 -i gdal2tiles_parallelize_base_and_overview_tiles.patch

Ora corri gdal2tilescome fai normalmente. Ho ottenuto un incredibile aumento delle prestazioni, con tutti e 4 i miei core (Intel Core i7 3.4GHz) collegati:

$ 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

Quindi da ~ 8 ore a 39 MINUTI . Cambio di gioco.



2

Hai citato FME e ci sono alcuni numeri sulla creazione di riquadri di mappe su FMEpedia

È un lungo articolo, quindi ho estratto le parti pertinenti:

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

Questo sta usando un processo multi-macchina con FME Server. Puoi anche leggere questo post di Paul Bissett sul blog WeoGeo: http://www.weogeo.com/blog/Scaling_FME_Engines_on_WeoGeo.html

Ha un ottimo film che mostra come elaborare dati come questo nel cloud - fondamentalmente accendendo un sacco di macchine virtuali Amazon per diffondere il carico di elaborazione e farlo molto rapidamente.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.