<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Almeno per come li conosco io i raster, gli indici spaziali su essi non
servono a nulla. A prescindere dal formato di archiviazione.<br>
<br>
Un indice serve a mettere ordine ad un'informazione distribuita in
maniera pi&ugrave; o meno casuale.<br>
<br>
In un raster non vedo alcun disordine.<br>
Dal TopLeft al BottomRight ci sono tutti i pixel (diciamo al 99%).<br>
<br>
Cosa diversa dal vettoriale dove le feature ci possono essere o meno.<br>
<br>
Quindi perch&egrave; 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?<br>
<br>
O mi sbaglio?<br>
<br>
Cristoforo<br>
<br>
Il 20/07/2010 13.24, <a class="moz-txt-link-abbreviated" href="mailto:a.furieri@lqt.it">a.furieri@lqt.it</a> ha scritto:
<blockquote cite="mid:20100720110854.M82677@lqt.it" type="cite">
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
  <meta content="OPENWEBMAIL" name="GENERATOR">
  <font size="2"><b>On Tue, 20 Jul 2010 12:56:33 +0200, Andrea Peri
wrote</b>
  <br>
&gt; Invece nel db non esiste sovrastruttura, tutte le immagii o se si
vuole tutti i tiles sono nel medeismo db.
  <br>
&gt; Per qui l'efficienza e' massimizzata.
  <br>
&gt; <br>
&gt; Su oracle aggiungo un particolare,
  <br>
&gt; nella versione 10 (l'ultima che conosco),
  <br>
&gt; addirittura quando vi si carica una immagine raster esos non la
lascia intonsa, ma se la sbriciolava in tile fisici.
  <br>
&gt; 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)
  <br>
&gt; Questo per dire come i dati vengono archiviati in un db per
massimizzare le performances.
  <br>
&gt; <br>
  <br>
Esattamente come fa anche rasterlite: alla fine hai un visibilio di
tiles individuali (anche svariati milioni,
  <br>
se la coverage &egrave; bella grossa), ma tutte di piccole dimensioni (e
quindi facilmente elaborabili), e tutte <br>
spatially index (e quindi celermente selezionabili).
  <br>
E poi, naturalmente, rasterlite si auto-genera anche una struttura
piramidale interna di supporto.
  <br>
  <br>
  <span style="font-family: arial,helvetica,sans-serif;"></span>&gt;
Come dicevo non conosco in dettaglio rasterlite e quindi se usi la jpeg
certamente hai i limiti di tale compressione.
  <br>
&gt; 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.
  <br>
&gt; <br>
  <br>
infatti, &egrave; esattamente cos&igrave;: posso solo aggiungere che rasterlite non
ti costringe affatto ad usare <br>
per forza la compressione JPEG: puoi anche scegliere di usare "non
compresso", oppure la buona
  <br>
vecchia DEFLATE (quella di PNG, per capirsi), ma anche una Wavelet open
source (epsilon).
  <br>
EPSILON pu&ograve; anche essere "loseless", ma in questo caso ti devi
accontentare di un <br>
rapporto di compressione 50% [assai modesto, ma sicuramente migliore di
DEFLATE]:
  <br>
se invece decidi di utilizzare EPSILON in modalit&agrave; "lossy", allora puoi
anche raggiungere
  <br>
rapporti di compressione inferiori al 10%, pur mantenendo una qualit&agrave;
decente.
  <br>
  <br>
  <br>
&gt; 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.
  <br>
&gt; <br>
  <br>
OK: e questo &egrave; il "punto doloroso" di rasterlite, che non adottando
nessuna architettura
  <br>
client server ti costringe a tenere il file-DB in locale, sulla
medesima piattaforma usata
  <br>
per l'elaborazione. altrimenti i tempi di accesso p.es. via network
filesystem diventano
  <br>
sicuramente proibitivi.
  <br>
  <br>
Ma se p.es. rasterlite viene usato per alimentare un servizio WMS il
problema
  <br>
ovviamente non si pone: BTW, mica qualcuno ha fatto qualche test
???????
  <br>
  <br>
ciao Sandro
  <br>
  </font>
  <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Iscriviti all'associazione GFOSS.it: <a class="moz-txt-link-freetext" href="http://www.gfoss.it/drupal/iscrizione">http://www.gfoss.it/drupal/iscrizione</a>
<a class="moz-txt-link-abbreviated" href="mailto:Gfoss@faunalia.it">Gfoss@faunalia.it</a>
<a class="moz-txt-link-freetext" href="http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss">http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss</a>
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</pre>
</blockquote>
<br>
</body>
</html>