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.