[Gfoss] R: Ridurre dimensione ed ottimizzazione tiff per webgis

[a.furieri a lqt.it]

On Tue, 14 Jul 2015 09:35:59 +0000, Rossin Pietro wrote:
> Buon giorno Paolo
>
> Mettiamola così
> La pubblicazione deve avvenire via Lizmap (qgis server)
> Sulla macchina in cui gira lizmap non abbiamo messo postgis e quindi
> escluderei l'archiviazione come postgis raster (sempre che abbia 
> senso
> parlarne  nel mio caso - credo di no)
>
> L'idea è di metterlo su filesystem sul server, a questo punto devo
> scegliere il formato e la compressione
> Non posso utilizzare numeri interi, poiché è una batimetria di una
> laguna, con una buona parte della sue superfice che è meno di un 
> metro
> di profondità. Il battente massimo è sui 13m ma è una piccola fossa,
> diciamo che quasi tutta l'area è compresa tra 0 e 5m.
>

Ciao Pietro,

questo non e' rigorosamente vero: basta solo che tu converta le tue
misura da metri a centimetri e scoprirai che a te basta un range
di valori compresi tra 0 e -1300
o magari passi a millimetri, ed in questo caso oscilli tra 0 e -13000

se sei in grado di considerare accettabile il cambio dell'unita' di
misura questi valori si adatterebbero perfettamente ad un Int16, ed
in questo modo risparmieresti direttamente il 50% degli ingombri
senza nessuna perdita significativa di precisione (dubito molto che
le tue misure batimetriche abbiano un'accuratezza superiore al cm)

se vicervsa sei costretto a mantenere le misure in metri allora
non hai alternative: un float a 32 bit e' l'unico formato che si
puo' adattare alle tue necessita'.


> Se lo metto su filesystem, in che formato lo posso salvare?
>

se capisco bene hai un singolo TIFF, grandicello ma non certo
mostruosamente enorme (esiste ben di peggio al giro per il mondo).
usa un TIFF e vai sereno; se vuoi la massima velocita' lo lasci
non compresso.
se pensi che sia accettabile un modesto rallentamento che ti
consente pero' di risparmiare spazio disco prezioso allora
comprimilo con DEFLATE (se usi GDAL ricordati di usare l'opzione
"predictor" per avere una compressione realmente efficace).

in tutti i casi, e' vitale che tu strutturi il tuo TIFF per TILE,
perche' il segreto per rendere veloci i TIFF e' tutto nell'uso
sapiente delle tiles con dimensioni ben calibrate.
tiles troppo grosse sono pesanti da gestire e rallentano.
tiles troppo piccole "ingolfano" ed oltretutto danno  rapporti di
compressione molto deludenti..
l'ottimale dovrebbe essere una dimensione di circa 512x512 pixels,
o magari 1024x1024 ... fatti qualche prova di calibrazione.


> Per Rasterlite ti riferisci a questa serie di test?
> https://www.gaia-gis.it/fossil/librasterlite2/wiki?name=benchmarks
> Interessante come formato, anche per la possibilità di fare
> tematizzazioni al volo..
> Vedo anche che il deflate sembra essere il sistema di compressione
> più performante in termini di rapporto dimensioni/prestazioni in
> lettura
>
> Tutti i test sono stati fatti con immagini con pixel tipo integer
> (8/16 bit) o 1 bit
>

per DEFLATE non cambia nulla anche se usi Float o Double, perche'
comunque e' un algoritmo che lavora per singoli bytes; beninsteso,
devi stare ben attento a specificare sempre il delta encoding
(aka "predictor" come lo chiama GDAL), perche' e' l'unico modo
per ottenre rapporti di compressione realmente incisivi.


> Potrebbe rasterlite essere un formato valido nella gestione dei
> raster su server da dare a qgis-server/lizmap (che magari faccia 
> anche
> funzioni di server WMS??)
>

potra' sicuramente in prospettiva: ma ancora RasterLite2 e' in fase di
sviluppo e non e' pienamente maturo.
e soprattutto non e' ancora supportato da GDAL, per cui per ora 
scordatelo;
magari ne riparliamo ad inizio 2016.

ciao Sandro