[Gfoss] ecw con geoserver/gdal: Erdas ha rimosso ecw3.3 runtime lib

a.furieri a lqt.it a.furieri a lqt.it
Mar 20 Lug 2010 13:24:16 CEST


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
 
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.faunalia.it/pipermail/gfoss/attachments/20100720/2748538f/attachment.htm>


Maggiori informazioni sulla lista Gfoss