On Tue, 20 Jul 2010 12:56:33 +0200, Andrea Peri wrote > Invece nel db non esiste sovrastruttura, tutte le immagii o se si vuole tutti > i tiles sono nel medeismo db. > Per qui l'efficienza e' massimizzata. > > Su oracle aggiungo un particolare, > nella versione 10 (l'ultima che conosco), > addirittura quando vi si carica una immagine raster esos non la lascia > intonsa, ma se la sbriciolava in tile fisici. > Ovvero una immagine TIFF come si conosce noi, diventava qualche migliaio di > records in una tabella (di tipo particolare, in cui i records non erano > accedibili dall'esterno singolarmente, ma sempre una tabella) > Questo per dire come i dati vengono archiviati in un db per massimizzare le > performances. >
Esattamente come fa anche rasterlite: alla fine hai un visibilio di tiles individuali (anche svariati milioni, se la coverage è bella grossa), ma tutte di piccole dimensioni (e quindi facilmente elaborabili), e tutte spatially index (e quindi celermente selezionabili). E poi, naturalmente, rasterlite si auto-genera anche una struttura piramidale interna di supporto. > Come dicevo non conosco in dettaglio rasterlite e quindi se usi la jpeg > certamente hai i limiti di tale compressione. > Riduci il problema se sbricioli l'immagine in tanti tiles distinti , come > fossero tante immaginine piccole, ognuna di tipo jpeg. A quel punto riduci > l'onere computazionale alla porzione che ti serve effettivamente, e sfrutti > gli indici del db sqlite per raggiungere rapidamente le porzioni che ti > servono. > infatti, è esattamente così: posso solo aggiungere che rasterlite non ti costringe affatto ad usare per forza la compressione JPEG: puoi anche scegliere di usare "non compresso", oppure la buona vecchia DEFLATE (quella di PNG, per capirsi), ma anche una Wavelet open source (epsilon). EPSILON può anche essere "loseless", ma in questo caso ti devi accontentare di un rapporto di compressione 50% [assai modesto, ma sicuramente migliore di DEFLATE]: se invece decidi di utilizzare EPSILON in modalità "lossy", allora puoi anche raggiungere rapporti di compressione inferiori al 10%, pur mantenendo una qualità decente. > Il problema nel tuo caso del rasterlite, e' caso mai che il rasterlite non si > presta a un utilizzo tramite un flusso, ovvero essendo in un db quando accedi > al db via rete devi scaricare sempre tuttoo il db prima di potervi accedere e > decodificare quello che cerchi. > OK: e questo è il "punto doloroso" di rasterlite, che non adottando nessuna architettura client server ti costringe a tenere il file-DB in locale, sulla medesima piattaforma usata per l'elaborazione. altrimenti i tempi di accesso p.es. via network filesystem diventano sicuramente proibitivi. Ma se p.es. rasterlite viene usato per alimentare un servizio WMS il problema ovviamente non si pone: BTW, mica qualcuno ha fatto qualche test ??????? ciao Sandro
_______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [email protected] http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 460 iscritti al 15.7.2010
