[Gfoss] Ridurre dimensione ed ottimizzazione tiff per webgis

Local Chapters GFOSS.it
1

Buon giorno

Ho un file tiff di batimetria che vorrei usare come immagine di sfondo, possibilmente interrogabile, in un applicativo web.

La dimensione di questo file è circa 1,3Gb, credo tantino per un applicativo di un’area di circa 30Km per 6 di larghezza media

La colpa di sicuro è della risoluzione, siamo ad 1m di pixel.

Il tiff non è compresso, il tipo di dato è Float32 - numero in virgola mobile di 32 bit, singola banda valori in scala.

I valori sono compresi tra 0 e -14,3m

Quali ottimizzazioni potrei adottare, mantenendo la risoluzione, perché sia reso velocemente in un servizio web (qgis-server) magari riducendone le dimensioni?

I valori hanno 16 cifre dopo la virgola, a me ne basterebbero molte meno.

Vedevo che gdal_translate ha come opzioni del file di output {Byte/Int16/UInt16/UInt32/Int32/Float32/Float64/CInt16/CInt32/CFloat32/CFloat64}

Byte sarà booleano, quindi non va bene

Int16/32 sono numeri interi (anche C e U int dovrebbero essere interi) quindi niet

Float32 è il decimale precisione singola, giusto? Non esiste il modo di usare un float16? Si ridurrebbero i bit e la dimensione dell’immagine?

Conviene tenerlo come tiff?

Se si, immagino convenga comprimerlo come LZW (jpg crea artefatti, va bene per immagini RGB)…

Conviene usare l’opzioone “TILED=YES” per creare dei tif a tasselli e non leggere l’immagine intera?

Conviene tagliare in più immagini e fare un raster virtuale vrt?

Aggiungere piramidi??

Che altro?

Grazie per ogni suggerimento

Saluti

Pietro Rossin

2

Il 10/07/2015 14:07, Rossin Pietro ha scritto:

Conviene tenerlo come tiff?

Se si, immagino convenga comprimerlo come LZW (jpg crea artefatti, va
bene per immagini RGB)..

Conviene usare l’opzioone “TILED=YES” per creare dei tif a tasselli e
non leggere l’immagine intera?

La questione dimensioni vs performances e' complicata, e a volte
controintuitiva (un file grande non compresso potrebbe anche essere, in
certe condizioni, piu' rapido da caricare rispetto ad uno compresso).
Negli archivi di questa lista ci sono ampie ed approfondite analisi,
soprattutto da parte di Sandro Furieri AKA Rasterlite :wink:
Se non ti serve la precisione decimale, potresti trasformarlo in un Int,
li' risparmi sicuramente spazio.
Se vuoi comprimerlo, di solito meglio DEFLATE che LZW.
Saluti.

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html

3

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.

Se lo metto su filesystem, in che formato lo posso salvare?
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

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??)

Grazie

La questione dimensioni vs performances e' complicata, e a volte controintuitiva (un file grande non compresso potrebbe anche essere, in certe condizioni, piu' rapido da caricare rispetto ad uno compresso).
Negli archivi di questa lista ci sono ampie ed approfondite analisi, soprattutto da parte di Sandro Furieri AKA Rasterlite :wink: Se non ti serve la precisione decimale, potresti trasformarlo in un Int, li' risparmi sicuramente spazio.
Se vuoi comprimerlo, di solito meglio DEFLATE che LZW.
Saluti.

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

4

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

5

Buon giorno Alessandro..
Azz... il cambio di unità di misura, sono proprio senza fantasia, non ci
avevo pensato....
Convertite a cm andrà sicuramente benissimo!

La stringa potrebbe essere:

gdal_translate -of GTiff -a_srs EPSG:32633 -b 1 -co TILED=YES -co
BLOCKXSIZE=512 -co BLOCKYSIZE=512 -co TFW=YES -co COMPRESS=DEFLATE -co
ZLEVEL=1 -co PREDICTOR=2 file_in.tif file_out.tif

Da questo post
http://linfiniti.com/2011/05/gdal-efficiency-of-various-compression-algorithms/
risulta che comunque con ZLEVEL=1 si raggiunge un file che è attorno
all'11-13% dell'originale
Sempre da Linfiniti vedo che il predictor (che di default è 1=inattivo) se
attivato aumenta i tempi di lettura del file.. Non so se vale la pena sempre
nell'ottica di ottenere non la compressione più spinta, ma un buon
compromesso tra compressione e prestazione..

Grazie infinite per i suggerimenti!
Pietro

--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Ridurre-dimensione-ed-ottimizzazione-tiff-per-webgis-tp7593118p7593146.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.

6

On Tue, 14 Jul 2015 04:12:30 -0700 (MST), pietro rossin wrote:

Sempre da Linfiniti vedo che il predictor (che di default è 1=inattivo) se
attivato aumenta i tempi di lettura del file..

Pietro,

il discorso e' abbastanza semplice:
- se vuoi essere assolutamente certo di ottenere il massimo della velocita'
   allora lascia perdere qualsiasi compressione, tieniti i dati non compressi.
- se invece hai assolutamente bisogno di comprimere (p.es. perche' hai poco
   storage disponibile) allora fai in modo che ne valga realmente la pena,
   e quindi cerca di "strizzare" al massimo.

una deflate senza delta encoding (aka predictor) rischia di non essere ne
carne ne pesce: paghi un costo certo per avere benefici probabimente
assai dubbi (=compressione scarsa e poco significativa).
se invece attivi il delta encoding paghi un costo sicuramente piu' alto
ma solo in misura molto marginale: pero' almeno sei sempre sicuro di
avere una compressione realmente incisiva.

se guardi i benchmarks [1] vedrai che il risparmio di spazio e' sempre
molto significativo, mentre il rallentamento e' poco avvertibile.

[1] https://www.gaia-gis.it/fossil/librasterlite2/wiki?name=benchmarks

ciao Sandro

7

Ok, ricevuto, grazie!
pietro

-----Messaggio originale-----
Da: gfoss-bounces@lists.gfoss.it [mailto:gfoss-bounces@lists.gfoss.it] Per conto di a.furieri@lqt.it
Inviato: martedì 14 luglio 2015 14:01
A: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] R: Ridurre dimensione ed ottimizzazione tiff per webgis

On Tue, 14 Jul 2015 04:12:30 -0700 (MST), pietro rossin wrote:

Sempre da Linfiniti vedo che il predictor (che di default è
1=inattivo) se
attivato aumenta i tempi di lettura del file..

Pietro,

il discorso e' abbastanza semplice:
- se vuoi essere assolutamente certo di ottenere il massimo della
velocita'
   allora lascia perdere qualsiasi compressione, tieniti i dati non
compressi.
- se invece hai assolutamente bisogno di comprimere (p.es. perche' hai
poco
   storage disponibile) allora fai in modo che ne valga realmente la
pena,
   e quindi cerca di "strizzare" al massimo.

una deflate senza delta encoding (aka predictor) rischia di non essere
ne
carne ne pesce: paghi un costo certo per avere benefici probabimente
assai dubbi (=compressione scarsa e poco significativa).
se invece attivi il delta encoding paghi un costo sicuramente piu' alto
ma solo in misura molto marginale: pero' almeno sei sempre sicuro di
avere una compressione realmente incisiva.

se guardi i benchmarks [1] vedrai che il risparmio di spazio e' sempre
molto significativo, mentre il rallentamento e' poco avvertibile.

[1] https://www.gaia-gis.it/fossil/librasterlite2/wiki?name=benchmarks

ciao Sandro
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

8

Non dimenticare di costruire la piramide.
Ti aiutera' a essere veloce quando guardi la mappa a scale basse.
I tiles da soli non bastano per la performance a tutta scala.

Ecco un esempio tratto dai parametri usati per le nostre OFC2K.
Le ns ofc sono a 4 bande e quindi nel comando ci vedi anche il
parametro che descrive quante bande mettere nel tif risultante.

gdal_translate -ot Byte -of GTiff -b 1 -b 2 -b 3 -b 4 -a_nodata none
-stats -co COMPRESS=DEFLATE -co PREDICTOR=2 -co INTERLEAVE=PIXEL -co
PROFILE=GDALGeoTIFF -co TILED=YES -co BLOCKXSIZE=512 -co
BLOCKYSIZE=512 -co SPARSE_OK=TRUE -co TFW=NO nomefile.tif

gdaladdo -ro -r average nomefile.tif 2 4 8 16 32 64 128 256 512

Anche io ho fatto innumerevoli prove con tanti tipi di tiffs.
Alla fine ho concluso che il rallentamento della deflate con
predictor=2 e' sopportabile, in compenso il risparmio in termini di
spazio disco e' importante.
Le mie prove sono state fatte su mapserver, ma anche mapserver, come
qgis usa gdal e quindi immagino che le conclusioni siano riciclabili
anche su qgis.
QGIS e' sicuramente piu' lento di mapserver, ma sui rasters non
dovrebbe esserlo molto.

A.

Il 14 luglio 2015 13:12, pietro rossin <pietro.rossin@arpa.fvg.it> ha scritto:

Buon giorno Alessandro..
Azz... il cambio di unità di misura, sono proprio senza fantasia, non ci
avevo pensato....
Convertite a cm andrà sicuramente benissimo!

La stringa potrebbe essere:

gdal_translate -of GTiff -a_srs EPSG:32633 -b 1 -co TILED=YES -co
BLOCKXSIZE=512 -co BLOCKYSIZE=512 -co TFW=YES -co COMPRESS=DEFLATE -co
ZLEVEL=1 -co PREDICTOR=2 file_in.tif file_out.tif

Da questo post
http://linfiniti.com/2011/05/gdal-efficiency-of-various-compression-algorithms/
risulta che comunque con ZLEVEL=1 si raggiunge un file che è attorno
all'11-13% dell'originale
Sempre da Linfiniti vedo che il predictor (che di default è 1=inattivo) se
attivato aumenta i tempi di lettura del file.. Non so se vale la pena sempre
nell'ottica di ottenere non la compressione più spinta, ma un buon
compromesso tra compressione e prestazione..

Grazie infinite per i suggerimenti!
Pietro

--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Ridurre-dimensione-ed-ottimizzazione-tiff-per-webgis-tp7593118p7593146.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

9

Il 14/07/2015 14:52, Andrea Peri ha scritto:

Alla fine ho concluso che il rallentamento della deflate con
predictor=2 e' sopportabile, in compenso il risparmio in termini di
spazio disco e' importante.

Ovviamente questo coinvolge un altro parametro: se occupi meno spazio
disco, puoi usare dischi SSD, che in lettura danno performances
strepitose, che dovrebbero più che compensare il piccolo rallentamento
dovuto alla decompressione.
Saluti.
Saluti.

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html

10

Allora ho fatto delle prove grazie anche ad Andrea Peri che mi ha gentilmente mandato una stringa che ho adattato alle mie esigenze..

Modoficata è
gdal_translate -ot Int16 -of GTiff -b 1 -a_nodata none -stats -co COMPRESS=DEFLATE -co PREDICTOR=2 -co INTERLEAVE=PIXEL -co PROFILE=GDALGeoTIFF -co TILED=YES -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 -co SPARSE_OK=TRUE -co TFW=YES file_in.tif file_out.tif

SPARSE_OK=TRUE non ho ben capito a che serve, ma l'ho lasciato..

Poi ho aggiunto le piramidi
gdaladdo -ro -r average file_out.tif 2 4 8 16 32 64 128 256 512

Risultato
Il file tiff che era 1.3Gb è diventato 16.6Mb...
Le piramidi sono risultate circa 224Mb.
Il file originale (credo fosse stato fatto in arcgis con LZW) era senza piramidi 475Mb. Con le piramidi fatte in qgis arrivava a 934Mb

Messo sul server con lizmap va molto veloce, sono soddisfatto..

Per chi usa lizmap, si possono interrogare i raster?
Ho provato ad abilitare il popup, ma non mi compaiono valori cliccando la batimetria..

@Paolo
Il server Debian/Lizmap è virtualizzato su macchina INSIEL che credo abbia performances che non oso immaginare..

Grazie a tutti
pietro

-----Messaggio originale-----
Da: gfoss-bounces@lists.gfoss.it [mailto:gfoss-bounces@lists.gfoss.it] Per conto di Paolo Cavallini
Inviato: martedì 14 luglio 2015 14:55
A: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] R: Ridurre dimensione ed ottimizzazione tiff per webgis

Il 14/07/2015 14:52, Andrea Peri ha scritto:

Alla fine ho concluso che il rallentamento della deflate con
predictor=2 e' sopportabile, in compenso il risparmio in termini di
spazio disco e' importante.

Ovviamente questo coinvolge un altro parametro: se occupi meno spazio disco, puoi usare dischi SSD, che in lettura danno performances strepitose, che dovrebbero più che compensare il piccolo rallentamento dovuto alla decompressione.
Saluti.
Saluti.

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

11

Ciao,

il raster ha sicuramente senso che possa essere interrogabile.

In alcuni casi, li abbiamo messi interrogabili sui nostri servers wms.
Su mapserver la cosa e' possibile ed e' possibile personalizzare l'output, ad esempio facendogli ritornare il valore RGB, separatamente, oppure facendogli ritornare il valore float.

Pensa al casoin cui servi con il wms un dato DTM come ascii-grid configurato a raster.
In tal caso ha perfettamente senso che il WMS a fronte di una interrogazione ritorni il valore della cella (intero o float che sia), che tipicamente corrisponderebbe alla quota sul punto clicckato.

Se vuoi un esempio puoi provare a collegarti con qgis al nostro server wms che propone il DTM10metri.
http://www502.regione.toscana.it/wmsraster/com.rt.wms.RTmap/wms?map=wmsmorfologia

Lo puoi vedere come elemento wms raster colorato (con le soglie previste dall'istat), se provi a interrogarlo, ti ritorna la quota del punto dove hai clicckato.

A.

Il 14/07/2015 17:54, Rossin Pietro ha scritto:

Messo sul server con lizmap va molto veloce, sono soddisfatto..

Per chi usa lizmap, si possono interrogare i raster?
Ho provato ad abilitare il popup, ma non mi compaiono valori cliccando la batimetria..

12

Grazie Andrea
Immagino che vi siano dei sistemi che restituiscono il valore del raster interrogato, sicuramente mapserver è uno strumento molto potente.
Io purtroppo (o per fortuna) sono biologo, non ho le conoscenze informatiche necessarie a mettere in piedi un'infrastruttura completa basata su mapserver & C.
E se aspetto che i colleghi informatici si interessino della vicenda sto fresco..

Trovo Lizmap una soluzione molto semplice e veloce per strutturare un portale cartografico/web...

Quindi per il momento stavo cercando informazioni su se/come rendere gli strati raster interrogabili tramite quello strumento.

Buona giornata
Pietro

-----Messaggio originale-----
Da: aperi2007 [mailto:aperi2007@gmail.com]
Inviato: martedì 14 luglio 2015 18:11
A: Rossin Pietro; gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] R: R: Ridurre dimensione ed ottimizzazione tiff per webgis

Ciao,

il raster ha sicuramente senso che possa essere interrogabile.

In alcuni casi, li abbiamo messi interrogabili sui nostri servers wms.
Su mapserver la cosa e' possibile ed e' possibile personalizzare l'output, ad esempio facendogli ritornare il valore RGB, separatamente, oppure facendogli ritornare il valore float.

Pensa al casoin cui servi con il wms un dato DTM come ascii-grid configurato a raster.
In tal caso ha perfettamente senso che il WMS a fronte di una interrogazione ritorni il valore della cella (intero o float che sia), che tipicamente corrisponderebbe alla quota sul punto clicckato.

Se vuoi un esempio puoi provare a collegarti con qgis al nostro server wms che propone il DTM10metri.
http://www502.regione.toscana.it/wmsraster/com.rt.wms.RTmap/wms?map=wmsmorfologia

Lo puoi vedere come elemento wms raster colorato (con le soglie previste dall'istat), se provi a interrogarlo, ti ritorna la quota del punto dove hai clicckato.

A.

Il 14/07/2015 17:54, Rossin Pietro ha scritto:

Messo sul server con lizmap va molto veloce, sono soddisfatto..

Per chi usa lizmap, si possono interrogare i raster?
Ho provato ad abilitare il popup, ma non mi compaiono valori cliccando la batimetria..

AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

13

Volevo solo dimostrarti che la specifica WMS permette l'interrogazione
del raster.

Ovvio che deve poterlo fare anche qgis-server.
Se non lo fa' e' un bug.

Ci sta che il programmatore di qgis che ha scritto la parte wms
pensasse che l'interrogazione fosse una prerogativa solo dei
vettoriali e quindi , nel getcapabilities di risposta del qgis-server,
quando lo strato e' raster forzi il parametro "queriable" a false,
mentre invero potrebbe essere anche true.

Prova a servire uno strato raster con qgis-server e a interrogarlo con
qgis (non con lizmap).

E vedi un po' se ti riporta l' rgb o il floating value del punto clicckato.

Se te lo ritorna e' un bug del lizmap, se non te lo ritorna o se non
ti abilita' l'identificazione sullo strato raster potrebbe essere un
bug di qgis-server.

A.

Il 15 luglio 2015 09:01, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Grazie Andrea
Immagino che vi siano dei sistemi che restituiscono il valore del raster interrogato, sicuramente mapserver è uno strumento molto potente.
Io purtroppo (o per fortuna) sono biologo, non ho le conoscenze informatiche necessarie a mettere in piedi un'infrastruttura completa basata su mapserver & C.
E se aspetto che i colleghi informatici si interessino della vicenda sto fresco..

Trovo Lizmap una soluzione molto semplice e veloce per strutturare un portale cartografico/web...

Quindi per il momento stavo cercando informazioni su se/come rendere gli strati raster interrogabili tramite quello strumento.

Buona giornata
Pietro

-----Messaggio originale-----
Da: aperi2007 [mailto:aperi2007@gmail.com]
Inviato: martedì 14 luglio 2015 18:11
A: Rossin Pietro; gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] R: R: Ridurre dimensione ed ottimizzazione tiff per webgis

Ciao,

il raster ha sicuramente senso che possa essere interrogabile.

In alcuni casi, li abbiamo messi interrogabili sui nostri servers wms.
Su mapserver la cosa e' possibile ed e' possibile personalizzare l'output, ad esempio facendogli ritornare il valore RGB, separatamente, oppure facendogli ritornare il valore float.

Pensa al casoin cui servi con il wms un dato DTM come ascii-grid configurato a raster.
In tal caso ha perfettamente senso che il WMS a fronte di una interrogazione ritorni il valore della cella (intero o float che sia), che tipicamente corrisponderebbe alla quota sul punto clicckato.

Se vuoi un esempio puoi provare a collegarti con qgis al nostro server wms che propone il DTM10metri.
http://www502.regione.toscana.it/wmsraster/com.rt.wms.RTmap/wms?map=wmsmorfologia

Lo puoi vedere come elemento wms raster colorato (con le soglie previste dall'istat), se provi a interrogarlo, ti ritorna la quota del punto dove hai clicckato.

A.

Il 14/07/2015 17:54, Rossin Pietro ha scritto:

Messo sul server con lizmap va molto veloce, sono soddisfatto..

Per chi usa lizmap, si possono interrogare i raster?
Ho provato ad abilitare il popup, ma non mi compaiono valori cliccando la batimetria..

AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

14

Il 15/07/2015 09:14, Andrea Peri ha scritto:

Volevo solo dimostrarti che la specifica WMS permette l'interrogazione
del raster.

Concordo, credo sia un limite di Lizmap. Consiglio "caldamente" di
contattare gli sviluppatori, non dovrebbe essere complicata da
aggiungere. E' una funzione non molto nota, e di cui molti non
realizzano l'utilita', quindi e' possibile che semplicemente non ci
abbiano pensato.
Saluti.

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html