Ridurre dimensione ed ottimizzazione tiff per webgis
Locked
Ridurre dimensione ed ottimizzazione tiff per webgis
 
|
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 _______________________________________________ [hidden email] 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 |
|
|
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 ;) 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 _______________________________________________ [hidden email] 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 |
R: Ridurre dimensione ed ottimizzazione tiff per webgis
|
|
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 ;) 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 _______________________________________________ [hidden email] 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. _______________________________________________ [hidden email] 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 |
|
|
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 _______________________________________________ [hidden email] 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 |
Re: R: Ridurre dimensione ed ottimizzazione tiff per webgis
|
|
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 |
|
|
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 _______________________________________________ [hidden email] 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 |
R: R: Ridurre dimensione ed ottimizzazione tiff per webgis
|
|
Ok, ricevuto, grazie!
pietro -----Messaggio originale----- Da: [hidden email] [mailto:[hidden email]] Per conto di [hidden email] Inviato: martedì 14 luglio 2015 14:01 A: [hidden email] 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 _______________________________________________ [hidden email] 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. _______________________________________________ [hidden email] 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 |
Re: R: Ridurre dimensione ed ottimizzazione tiff per webgis
|
|
In reply to this post by pietro rossin
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 <[hidden email]> 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. > _______________________________________________ > [hidden email] > 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 àèìòù ----------------- _______________________________________________ [hidden email] 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 |
|
|
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 _______________________________________________ [hidden email] 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 |
R: R: Ridurre dimensione ed ottimizzazione tiff per webgis
|
|
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: [hidden email] [mailto:[hidden email]] Per conto di Paolo Cavallini Inviato: martedì 14 luglio 2015 14:55 A: [hidden email] 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 _______________________________________________ [hidden email] 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. _______________________________________________ [hidden email] 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 |
Re: 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.. _______________________________________________ [hidden email] 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 |
R: R: R: Ridurre dimensione ed ottimizzazione tiff per webgis
|
|
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:[hidden email]] Inviato: martedì 14 luglio 2015 18:11 A: Rossin Pietro; [hidden email] 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. _______________________________________________ [hidden email] 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 |
Re: R: R: Ridurre dimensione ed ottimizzazione tiff per webgis
|
|
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 <[hidden email]> 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:[hidden email]] > Inviato: martedì 14 luglio 2015 18:11 > A: Rossin Pietro; [hidden email] > 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 àèìòù ----------------- _______________________________________________ [hidden email] 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 |
|
|
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 _______________________________________________ [hidden email] 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 |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |