ECW e qgis su ubuntu

[Andrea Peri]

 >> I tempi di rendering erano sempre a favore del TIFF, con differenze
 >di
 >> circa un 30%.

 >Tanto meglio, mi pare che questo renda piu' facile disintossicarsi,
 >anche per i piu'
 >dipendenti.
 >Sottolineo che se ECW e' cosi' usato in alcune regioni d'Italia, ed in
 >alcuni stati
 >esteri, e' perche' alcune amministrazioni pubbliche lo hanno scelto.
 >Ci sono molte situazioni in cui ECW e' praticamente sconosciuto. In
 >alcuni casi e'
 >molto usato MrSID, in altri nessun formato proprietario.
 >Questo per sottolineare il ruolo cruciale, come motore trainante,
 >della Pubblica
 >Amministrazione. Una volta che le PPAA si saranno disintossicate,
 >vedrete che di ECW
 >non se ne parlera' piu'.

Le sperimentazioni sono roba difficile, e ancora piu' difficile e'
saperne trarre' una lezione senza commettere errori ingenui.

Nello specifico la sperimentazione citata dimostra solo che l' ECW e'
piu' lento a essere decompresso.

E questo si indovinava facilmente peche' un formato uncompressed e'
sempre piu' rapido a decomprimersi di un formato compressed :))

Questo risultato non va' forzato dentro dei vestiti differenti, perche'
non si rischia di non entrarci...

Per restare nelle ipotesi di partenza di tale sperimentazione e
applicarla alle nostre ipotesi occorrerebbe ipotizzare che
ogni utente tenesse copiato sul proprio pc TUTTI I DATI RASTER.

E allora i famosi 500euro che costa 1Tbyte scopri che va moltiplicato
per ... (quanti PC usa una singola amministrazione ?).
E conteggiarci anche il costi di gestione...

Invece ogni persona che ha una certa idea dei costi di gesitone immagina
subito che piuttosto che copiare su tanti computers i medesimi dati
raster e' forse meglio metterli su un pc in rete e condividerli...

Ecco il punto !

Prova a fare questa sperimentazione.

Punto a)

Metti il tuo TIFF da 100Mbyte in un PC, collegati ad esso da un altro PC
via samba e prova ad aprirlo con QGIS.


Punto b)
Il WMS:

Ora prendi il tuo tiff tagliuzzalo in tutti i tiles che vuoi,
poi esponilo via WMS.
A questo punto prendi qgis, prepara un progetto con tale TIFF e prova a
richiedere una stampa in A0. Vedi un po' che ti dice ... :)

Poi facci sapere come e' andata....

Andrea.
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
518 iscritti al 3.6.2011

[Giovanni Manghi]

> E allora i famosi 500euro che costa 1Tbyte scopri che va moltiplicato
> per ... (quanti PC usa una singola amministrazione ?).
> E conteggiarci anche il costi di gestione..

1TB costa 50 euro, non 500. Vabbé per un desktop normale, per un server
no so.


> Punto b)
> Il WMS:
>
> Ora prendi il tuo tiff tagliuzzalo in tutti i tiles che vuoi,
> poi esponilo via WMS.
> A questo punto prendi qgis, prepara un progetto con tale TIFF e prova a
> richiedere una stampa in A0. Vedi un po' che ti dice ... :)

questo problema di qgis é giá stato risolto:

ora quando ci si collega ad server WMS é ora possibile specificare la
dimensione massima dell'imagine da scaricare ad ogni richiesta. In
questo modo un layer wms viene scaricato come se fosse "tiled" e, quando
si stampa um grande , qgis e il server wms non si lamentano piú.

-- G --

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
518 iscritti al 3.6.2011

[Andrea Peri]

Il 12/06/2011 16:59, Giovanni Manghi ha scritto:

>
> questo problema di qgis é giá stato risolto:
>
> ora quando ci si collega ad server WMS é ora possibile specificare la
> dimensione massima dell'imagine da scaricare ad ogni richiesta. In
> questo modo un layer wms viene scaricato come se fosse "tiled" e, quando
> si stampa um grande , qgis e il server wms non si lamentano piú.
>
> -- G --
>

Cosi' si fa' ,
si propone un problema si ipotizza una soluzione.

Vediamo nel dettaglio e cerchiamo di capire se puo' essere la soluzione
oppure no...

Io ho capito che se
che se vuoi stamparti un A0 ovvero una immagine da
10.000 x 10.000 px.

Ti devi fare a mano 100 chiamate da

1000 x 1000 px cadauna
e poi costruirti un progetto sempre a mano che
contenga questi 100 raster che ti sei scaricato localmente.

E' questo che dici ?

Immagino che per fare le chiamate farai uso di qualche strumento
software che tile-izza l'immagine (gdal forse ?).

Se e' cosi', diciamo che e' un "work-around" per bypassare il problema,
in questo trucco vai incontro ad altri problemi, che esulano dal
dibattito di questo thread.

E resta sempre sullo sfondo che si sta' ipotizzando di una situazione di
utilizzo non su internet, ma in rete locale.
Per cui ritornando all'obiettivo originale di questa discussione:

però , mentre un utente che dispone dell'ecw accedibile in rete locale
puo' fruire dei files ECW messi in condivisione in rete locale e quindi
ha a disposizione il pulsante "stampa" e si stampa un A0.
La soluzione alternativa per fare a meno degli ecw e' mettere in piedi
un WMS che manda immagini e che pero' costringe un utente, sempre in
rete locale a scaricarsi a mano qualche centinaio di files di mappe che
rappresentano la mappa in A0 e poi costruirsi un progetto dummy che le
contempli tutte e solo a quel punto mandare il tutto in stampa.

A me pare che ci sia una notevole differenza in termini di efficienza di
esecuzione e di tempo necessario per arrivare al risultato.
Oltre al fatto che si richiede che l'utente abbia una certa competenza e
quindi si restringe il campo di chi puo' fare queste cose.

Per cui restando sull'argomento:

capisci perche' alla fine l'ecw si e' affermato in certi ambiti ?

Per poter fare a meno dell' ecw occorre avere una soluzione pratica ed
efficiente che metta l'ecw in condizioni di essere ritenuto "peggio".

Non basta dire esiste una soluzione, occorre che sia quantomeno
paragonabile in termini di efficienza di praticità.

Andrea.
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
518 iscritti al 3.6.2011

[Giovanni Manghi]

> Io ho capito che se
> che se vuoi stamparti un A0 ovvero una immagine da
> 10.000 x 10.000 px.
>
> Ti devi fare a mano 100 chiamate da
>
> 1000 x 1000 px cadauna
> e poi costruirti un progetto sempre a mano che
> contenga questi 100 raster che ti sei scaricato localmente.
>
> E' questo che dici ?

no,
quando si carica un layer wms si sceglie una dimensione massima, diciamo
250x250px. Se l'immagine a schermo é 500x500px allora qgis, in modo del
tutto trasparente per l'utente, fa 4 chiamate creando il mosaico che
serve per comporre l'immagine richiesta. Il layer aggiunto al progetto é
sempre solo uno.

Se é necessario stampare un formato grande lui fa la stessa cosa, peró
in questo modo si risolve il rifiuto di certi server WMS di servire
immagini sopra una certa dimensione in px.

> Immagino che per fare le chiamate farai uso di qualche strumento
> software che tile-izza l'immagine (gdal forse ?).
>
> Se e' cosi', diciamo che e' un "work-around" per bypassare il problema,
> in questo trucco vai incontro ad altri problemi, che esulano dal
> dibattito di questo thread.
>
> E resta sempre sullo sfondo che si sta' ipotizzando di una situazione di
> utilizzo non su internet, ma in rete locale.
> Per cui ritornando all'obiettivo originale di questa discussione:
>
> però , mentre un utente che dispone dell'ecw accedibile in rete locale
> puo' fruire dei files ECW messi in condivisione in rete locale e quindi
> ha a disposizione il pulsante "stampa" e si stampa un A0.
> La soluzione alternativa per fare a meno degli ecw e' mettere in piedi
> un WMS che manda immagini e che pero' costringe un utente, sempre in
> rete locale a scaricarsi a mano qualche centinaio di files di mappe che
> rappresentano la mappa in A0 e poi costruirsi un progetto dummy che le
> contempli tutte e solo a quel punto mandare il tutto in stampa.

come ho detto sopra, non é necessario fare a mano centinaia di chiamate,
ci pensa qgis a fare il mosaico, con una solo chiamata.

> A me pare che ci sia una notevole differenza in termini di efficienza di
> esecuzione e di tempo necessario per arrivare al risultato.
> Oltre al fatto che si richiede che l'utente abbia una certa competenza e
> quindi si restringe il campo di chi puo' fare queste cose.
>
> Per cui restando sull'argomento:
>
> capisci perche' alla fine l'ecw si e' affermato in certi ambiti ?
>
> Per poter fare a meno dell' ecw occorre avere una soluzione pratica ed
> efficiente che metta l'ecw in condizioni di essere ritenuto "peggio".
>
> Non basta dire esiste una soluzione, occorre che sia quantomeno
> paragonabile in termini di efficienza di praticità

non so se il chiarimento risponde anche alle questioni successive.

La mia opinione é che per la maggior parte degli utenti il problema
dello spazio occupato é un falso problema (ok, ci sará pure chi ha
realmente questo problema, ma mi sembra possano essere decisamente una
piccola parte del totale) e che in termini di prestazioni i due formati
sono perlomeno comparabili (tiff con overviews, ovviamente).


-- G --

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
518 iscritti al 3.6.2011

Il 12 giugno 2011 19:16, aperi2007 <[hidden email]> ha scritto:

> Il 12/06/2011 16:59, Giovanni Manghi ha scritto:
>>
>> questo problema di qgis é giá stato risolto:
>>
>> ora quando ci si collega ad server WMS é ora possibile specificare la
>> dimensione massima dell'imagine da scaricare ad ogni richiesta. In
>> questo modo un layer wms viene scaricato come se fosse "tiled" e, quando
>> si stampa um grande , qgis e il server wms non si lamentano piú.
>>
>> -- G --
>>
>
> Cosi' si fa' ,
> si propone un problema si ipotizza una soluzione.
>
> Vediamo nel dettaglio e cerchiamo di capire se puo' essere la soluzione
> oppure no...
>
> Io ho capito che se
> che se vuoi stamparti un A0 ovvero una immagine da
> 10.000 x 10.000 px.
>
> Ti devi fare a mano 100 chiamate da
>
> 1000 x 1000 px cadauna
> e poi costruirti un progetto sempre a mano che
> contenga questi 100 raster che ti sei scaricato localmente.
>
> E' questo che dici ?
>
> Immagino che per fare le chiamate farai uso di qualche strumento software
> che tile-izza l'immagine (gdal forse ?).
>
> Se e' cosi', diciamo che e' un "work-around" per bypassare il problema,
> in questo trucco vai incontro ad altri problemi, che esulano dal dibattito
> di questo thread.
>
> E resta sempre sullo sfondo che si sta' ipotizzando di una situazione di
> utilizzo non su internet, ma in rete locale.
> Per cui ritornando all'obiettivo originale di questa discussione:
>
> però , mentre un utente che dispone dell'ecw accedibile in rete locale puo'
> fruire dei files ECW messi in condivisione in rete locale e quindi ha a
> disposizione il pulsante "stampa" e si stampa un A0.
> La soluzione alternativa per fare a meno degli ecw e' mettere in piedi un
> WMS che manda immagini e che pero' costringe un utente, sempre in rete
> locale a scaricarsi a mano qualche centinaio di files di mappe che
> rappresentano la mappa in A0 e poi costruirsi un progetto dummy che le
> contempli tutte e solo a quel punto mandare il tutto in stampa.
>
> A me pare che ci sia una notevole differenza in termini di efficienza di
> esecuzione e di tempo necessario per arrivare al risultato.
> Oltre al fatto che si richiede che l'utente abbia una certa competenza e
> quindi si restringe il campo di chi puo' fare queste cose.
>
> Per cui restando sull'argomento:
>
> capisci perche' alla fine l'ecw si e' affermato in certi ambiti ?
>
> Per poter fare a meno dell' ecw occorre avere una soluzione pratica ed
> efficiente che metta l'ecw in condizioni di essere ritenuto "peggio".
>
> Non basta dire esiste una soluzione, occorre che sia quantomeno paragonabile
> in termini di efficienza di praticità.

Esatto..erroneamente non avevo considerato il problema della stampa e
ringrazio Andrea per averlo messo in evidenza.
Però possiamo iniziare a pensare che, se il mio scopo è la semplice la
pubblicazione del dato per la consultazione (ad esempio con un
semplice WMS, più i vari sistemi di cache) , posso tranquillamente
fare a meno dell'ECW?
Questo è già un punto di partenza per dire: ok l'ECW non è
indispensabile se devi fare questo, questo e questo.

Grazie a tutti per gli spunti della discussione.

Ciao
L.

--
Luca Casagrande
twitter: lucacasagrande
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
518 iscritti al 3.6.2011

[Giovanni Manghi]

> Esatto..erroneamente non avevo considerato il problema della stampa e
> ringrazio Andrea per averlo messo in evidenza.

come giá detto il problema della stampa su grandi formati di layers wms
é risolto (in qgis, cosí come credo giá fosse in altri sw).

-- g --

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
518 iscritti al 3.6.2011

[Andrea Peri]

Il 12/06/2011 19:33, Giovanni Manghi ha scritto:
> Se é necessario stampare un formato grande lui fa la stessa cosa, peró
> in questo modo si risolve il rifiuto di certi server WMS di servire
> immagini sopra una certa dimensione in px.
>

Se capisco quelloche dici,
qgis fa al massimo 4 chiamate.

Ovvero se la mappa e' 10.000 x 10.000 px,

lui vorrebbe fare 4 chiamate da
5.000 x 5.000 px.

E' sempre roba di grande formato e ' corretto che il server wms faccia
difficolta'.

I server wms sono sequenziali, mettono le richieste in attesa e le
eseguono una per una.

per fare una mappa di 5000x5000 visot che viene prodotta in memroia
occorrono almeno, 25.000.000 Byte di memoria , ma probabilmente molto di
piu'.

questo significa che se un utente chiede la produzione di 4 immagini da
5000x5000 mette in attesa tutti gli altri utneti a cui non importa un
fico secco se tizio vuole stampare, ma piuttosto vogliono panneggiare ,
zoomare e si aspetterebbero di avere una risposta entra tre-quattro
secondi al massimo.

Per questo vengono limitate le dimensioni dei raster.

In realta' il difetto e'del client.

La produzione di un plottaggio e' un compito che spetta al client GIS.

Il client GIS dovrebbe arrangiarsi lui a fare tante richieste di massimo
1000x1000 px e poi rimetterle insieme, poiche' sono richieste distinte
esse verrebbero eseguite inframmezzate da altre richieste di altri
utenti e quindi non altererebbero sensibilmente il responsive-time del
server.

Chi lancia una stampa A0 si pone nella condizione di attendere del tempo
per avere il risultaot e quindi fa poco caso se invece di 1 ora ce ne
impiega due.
Ma chi panneggia o zooma non puo' certo mettersi in attesa che il
cliente che lo precede abbia finito di farsi produrre una mappa gigantesca.

A.
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
518 iscritti al 3.6.2011

[Giovanni Manghi]

> Se capisco quelloche dici,
> qgis fa al massimo 4 chiamate.

no, non hai capito.

QGIS fa il numero di chiamate necessarie a seconda della dimensione
massima dell'immagine scelta, che puó essere piccola a piacere.

È ovvio che per creare il mosaico di una immagine grande ci metterá del
tempo, ma le richieste possono essere molto rapide, se appunto sono di
"tiles" piccole.


Non so spiegarlo in altro modo. Ti conviene provare.

-- G --

>
> Ovvero se la mappa e' 10.000 x 10.000 px,
>
> lui vorrebbe fare 4 chiamate da
> 5.000 x 5.000 px.
>
> E' sempre roba di grande formato e ' corretto che il server wms faccia
> difficolta'.
>
> I server wms sono sequenziali, mettono le richieste in attesa e le
> eseguono una per una.
>
> per fare una mappa di 5000x5000 visot che viene prodotta in memroia
> occorrono almeno, 25.000.000 Byte di memoria , ma probabilmente molto di
> piu'.
>
> questo significa che se un utente chiede la produzione di 4 immagini da
> 5000x5000 mette in attesa tutti gli altri utneti a cui non importa un
> fico secco se tizio vuole stampare, ma piuttosto vogliono panneggiare ,
> zoomare e si aspetterebbero di avere una risposta entra tre-quattro
> secondi al massimo.
>
> Per questo vengono limitate le dimensioni dei raster.
>
> In realta' il difetto e'del client.
>
> La produzione di un plottaggio e' un compito che spetta al client GIS.
>
> Il client GIS dovrebbe arrangiarsi lui a fare tante richieste di massimo
> 1000x1000 px e poi rimetterle insieme, poiche' sono richieste distinte
> esse verrebbero eseguite inframmezzate da altre richieste di altri
> utenti e quindi non altererebbero sensibilmente il responsive-time del
> server.
>
> Chi lancia una stampa A0 si pone nella condizione di attendere del tempo
> per avere il risultaot e quindi fa poco caso se invece di 1 ora ce ne
> impiega due.
> Ma chi panneggia o zooma non puo' certo mettersi in attesa che il
> cliente che lo precede abbia finito di farsi produrre una mappa gigantesca.
>
> A.

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
518 iscritti al 3.6.2011

Ciao Giovanni,

Il 12 giugno 2011 20:22, Giovanni Manghi <[hidden email]> ha scritto:

>
>> Se capisco quelloche dici,
>> qgis fa al massimo 4 chiamate.
>
> no, non hai capito.
>
> QGIS fa il numero di chiamate necessarie a seconda della dimensione
> massima dell'immagine scelta, che puó essere piccola a piacere.
>
> È ovvio che per creare il mosaico di una immagine grande ci metterá del
> tempo, ma le richieste possono essere molto rapide, se appunto sono di
> "tiles" piccole.
>
>
> Non so spiegarlo in altro modo. Ti conviene provare.

Ho fatto alcune prove con il nuovo sistema ed ho notato questo:
- Si perde la trasparenza (stesso layer, con tile nessuna trasparenza,
senza trasparente);
- I tempi sono un po' più lunghi credo per il tempo necessario
all'unione delle varie tile;

Effettivamente sono riuscito a superare i limiti posti da alcuni server.
Ottimo!

Ciao
L.

--
Luca Casagrande
twitter: lucacasagrande
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
518 iscritti al 3.6.2011

[Giovanni Manghi]

> Ho fatto alcune prove con il nuovo sistema ed ho notato questo:
> - Si perde la trasparenza (stesso layer, con tile nessuna trasparenza,
> senza trasparente);

ho notato pure io, puoi per favore aprire un ticket nel nuovo tracker?

Grazie

-- Giovanni --

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
518 iscritti al 3.6.2011

Il 12 giugno 2011 22:17, Giovanni Manghi <[hidden email]> ha scritto:
>
>> Ho fatto alcune prove con il nuovo sistema ed ho notato questo:
>> - Si perde la trasparenza (stesso layer, con tile nessuna trasparenza,
>> senza trasparente);
>
> ho notato pure io, puoi per favore aprire un ticket nel nuovo tracker?
>

Fatto.

Ciao
L.

--
Luca Casagrande
twitter: lucacasagrande
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
518 iscritti al 3.6.2011

[pcav]

Il 12/06/2011 19:36, [hidden email] ha scritto:

> Grazie a tutti per gli spunti della discussione.

davvero, discussione molto interessante (spero che chi non usa ECW non si sia troppo
annoiato).
queste sono fra le volte che sono contento di aver dato inizio a questa lista
(consentitemelo, via!).
Saluti, e happy free mapping.

--
Paolo Cavallini: http://www.faunalia.it/pc
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
518 iscritti al 3.6.2011