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, [email protected] 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
[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
_______________________________________________
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
