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

[Cristoforo Abbattista]

Almeno per come li conosco io i raster, gli indici spaziali su essi non 
servono a nulla. A prescindere dal formato di archiviazione.

Un indice serve a mettere ordine ad un'informazione distribuita in 
maniera più o meno casuale.

In un raster non vedo alcun disordine.
Dal TopLeft al BottomRight ci sono tutti i pixel (diciamo al 99%).

Cosa diversa dal vettoriale dove le feature ci possono essere o meno.

Quindi perchè scandire uin indice spaziale (I/O quindi) se posso con due 
conticini (200 cicli di clock?) sapere dove si trova l'informazione che 
mi serve?

O mi sbaglio?

Cristoforo

Il 20/07/2010 13.24, a.furieri a lqt.it ha scritto:
> *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
> Gfoss a faunalia.it
> 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

-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.faunalia.it/pipermail/gfoss/attachments/20100720/9d9448df/attachment-0001.htm>