[Gfoss] ECW e qgis su ubuntu

[unknown]

Buongiorno,
siccome sto trovando forti difficoltà, non Ú che qualcuno che ha già
compilato le librerie di GDAL per il formato ECW mi può suggerire una giuda?
Ne ho trovate tante su internet ma con nessuna di queste sono riuscito a
ottenere un risultato (anzi, in un caso ho anche dovuto risistemare il qgis
perchÚ non partiva più...
Io utilizzo la versione di sviluppo di qgis (1.8.0) su Ubuntu 11.04 a 64 bit
Grazie a chiunque trovi il tempo e il modo di rispondere..

[unknown]

Il giorno Sat, 11 Jun 2011 10:26:54 +0200

Post by unknown
Buongiorno,
siccome sto trovando forti difficoltà, non Ú che qualcuno che ha già
compilato le librerie di GDAL per il formato ECW mi può suggerire una
giuda? Ne ho trovate tante su internet ma con nessuna di queste sono
riuscito a ottenere un risultato (anzi, in un caso ho anche dovuto
risistemare il qgis perchÚ non partiva più...
Io utilizzo la versione di sviluppo di qgis (1.8.0) su Ubuntu 11.04 a
64 bit Grazie a chiunque trovi il tempo e il modo di rispondere..

mi associo anche io alla richiesta...

[unknown]

Il procedimento é semplicissimo,
basta installare un package con synaptic (presente nel repository
"ubuntugis") e dare un comando

http://trac.osgeo.org/ubuntugis/wiki/UserTutorials


il vero problema é avere l'SDK della ERDAS per Linux, il cui download
non é piú disponibile da parecchio tempo.

-- Giovanni --

Post by unknown
Buongiorno,
siccome sto trovando forti difficoltà, non Ú che qualcuno che ha già
compilato le librerie di GDAL per il formato ECW mi può suggerire una
giuda? Ne ho trovate tante su internet ma con nessuna di queste sono
riuscito a ottenere un risultato (anzi, in un caso ho anche dovuto
risistemare il qgis perchÚ non partiva più...
Io utilizzo la versione di sviluppo di qgis (1.8.0) su Ubuntu 11.04 a 64 bit
Grazie a chiunque trovi il tempo e il modo di rispondere..
--
maurizio marchi
Ubuntu 11.04
([phone]
Skype: maurizioxyz
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss a lists.gfoss.it
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

[unknown]

Post by unknown
il vero problema é avere l'SDK della ERDAS per Linux, il cui download
non é piú disponibile da parecchio tempo.

Parliamo forse di un SDK che veniva distribuito con una licenza che
_non_ permetteva la redistribuzione e _non_ permetteva la modifica ?

Parliamo di un formato che per essere usato richiede l'impiego di
agenti software controllati da un'azienda e non da chi li usa ?

--strk;

() Free GIS & Flash consultant/developer
/\ http://strk.keybit.net/services.html

[unknown]

Post by unknown
Parliamo forse di un SDK che veniva distribuito con una licenza che
_non_ permetteva la redistribuzione e _non_ permetteva la modifica ?

Proprio cosi'.

Post by unknown
Parliamo di un formato che per essere usato richiede l'impiego di
agenti software controllati da un'azienda e non da chi li usa ?

Esatto.

[unknown]

Datemi un formato alternativo a ECW, con le stesse qualità:

- file based
- prestazioni elevate per il rendering
- support diffuso anche in sistemi gis commerciali

e farò per sempre a meno di questo formato ;)
(rasterlite sarebbe un bel sostituto...)

giovanni

Il giorno 11 giugno 2011 14:21, Paolo Cavallini <cavallini a faunalia.it> ha

Post by unknown

Post by unknown
Parliamo forse di un SDK che veniva distribuito con una licenza che
_non_ permetteva la redistribuzione e _non_ permetteva la modifica ?

Proprio cosi'.

Post by unknown
Parliamo di un formato che per essere usato richiede l'impiego di
agenti software controllati da un'azienda e non da chi li usa ?

Esatto.
--
Paolo Cavallini: http://www.faunalia.it/pc
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss a lists.gfoss.it
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

-------------- parte successiva --------------
Un allegato HTML ? stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20110611/a3f9b424/attachment.html>

[unknown]

Il giorno Sat, 11 Jun 2011 11:31:35 +0100

Post by unknown
Il procedimento é semplicissimo,
basta installare un package con synaptic (presente nel repository
"ubuntugis") e dare un comando
http://trac.osgeo.org/ubuntugis/wiki/UserTutorials
il vero problema é avere l'SDK della ERDAS per Linux, il cui download
non é piú disponibile da parecchio tempo.
-- Giovanni --

Post by unknown
Buongiorno,
siccome sto trovando forti difficoltà, non Ú che qualcuno che ha già
compilato le librerie di GDAL per il formato ECW mi può suggerire
una giuda? Ne ho trovate tante su internet ma con nessuna di queste
sono riuscito a ottenere un risultato (anzi, in un caso ho anche
dovuto risistemare il qgis perchÚ non partiva più...
Io utilizzo la versione di sviluppo di qgis (1.8.0) su Ubuntu 11.04 a 64 bit
Grazie a chiunque trovi il tempo e il modo di rispondere..
--
maurizio marchi
Ubuntu 11.04
([phone]
Skype: maurizioxyz
_______________________________________________
http://www.gfoss.it/drupal/iscrizione Gfoss a lists.gfoss.it
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

_______________________________________________
http://www.gfoss.it/drupal/iscrizione Gfoss a lists.gfoss.it
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

http://trac.osgeo.org/ubuntugis/wiki/UserTutorials

non ho capito bene cosa devo fare...
cmq, c'Ú qualche rischio di sballare gdal e quindi il funzionamento
corretto di quantum gis

[unknown]

Post by unknown
non ho capito bene cosa devo fare...
cmq, c'Ú qualche rischio di sballare gdal e quindi il funzionamento
corretto di quantum gis

no, non c'é pericolo, piuttosto hai l'SDK? ;)

scompatti l'sdk, entri nella cartella e dai

sudo gdal-ecw-build /usr/local/

C'é poi da fare attenzione a come hai installato QGIS:

se usi il repo ubuntugis e qgis 1.6, questo é compilato su gdal 1.8. Se
allo stesso tempo hai abilitato il repo nightly-build per provare
qgis-trunk questo é compilato su gdal 1.6, la versione presente nei repo
ufficiali Ubuntu. Quando segui la procedura il supporto per gli ecw é
aggiunto all'ultima versione di gdal installata nel sistema, quindi se
vuoi usare qgis-trunk/gdal 1.8 dovrai compilare qgis.

Da tenere conto che NON si puó utilizzare su software server.

-- Giovanni --

[unknown]

Il giorno Sat, 11 Jun 2011 17:25:27 +0100

Post by unknown
no, non c'é pericolo, piuttosto hai l'SDK? ;)

no...dove posso prenderlo?

[unknown]

Post by unknown
no...dove posso prenderlo?

é questo che stiamo cercando di dire... non é piú disponibile, e chi
l'ha non puó ridistribuirlo.

Ciao

-- Giovanni --

[unknown]

Post by unknown

Post by unknown
no...dove posso prenderlo?

é questo che stiamo cercando di dire... non é piú disponibile, e chi
l'ha non puó ridistribuirlo.

Ma qualcuno non puo' farne a meno, a meno che non gli
si somministri qualcosa di alternativo.

C'e' un medico in lista ?
Qualcuno ha del Metadone ?

Se vogliamo uscire dallo stato di dipendenza bisogna che si
impari a dire NO alla droga. NO ai formati proprietari.

Non c'e' da vergognarsi se i colleghi li usano.
E' come per il fumo. Se i tuoi colleghi di passano degli ECW
tu chiedi gentilmente qualcosa di pulito, di non tossico.
Se la tua istituzione ti passa degli ECW chiedi gentilmente
trasparenza, interoperabilita'. Chiedi che si utilizzino formati
le cui specifiche siano disponibili a tutti e che sui quali non
gravino brevetti che ne impediscano l'implementazione.

Se non ce ne sono, chiedi che vengano messi a disposizione dei
fondi per definirli. Ce ne vorranno certamente meno di quanto
si passa allo spacciatore di turno.

--strk;

() Free GIS & Flash consultant/developer
/\ http://strk.keybit.net/services.html

[unknown]

Il giorno Sat, 11 Jun 2011 20:52:41 +0200

Post by unknown
Se vogliamo uscire dallo stato di dipendenza bisogna che si
impari a dire NO alla droga. NO ai formati proprietari.

purtroppo non Ú così semplice, non lo Ú neppure per i file di
testo (odt vs doc/docx)...figuriamoci quando entrano in gioco
applicazioni più complesse

[unknown]

Post by unknown
Il giorno Sat, 11 Jun 2011 20:52:41 +0200

Post by unknown
Se vogliamo uscire dallo stato di dipendenza bisogna che si
impari a dire NO alla droga. NO ai formati proprietari.

purtroppo non Ú così semplice, non lo Ú neppure per i file di
testo (odt vs doc/docx)...figuriamoci quando entrano in gioco
applicazioni più complesse

Non penso affatto che sia semplice uscire da una tossicodipendenza.
Non entrarci e' molto piu' semplice, ovviamente.

--strk;

() Free GIS & Flash consultant/developer
/\ http://strk.keybit.net/services.html

[unknown]

Post by unknown

Post by unknown
purtroppo non Ú così semplice, non lo Ú neppure per i file di
testo (odt vs doc/docx)...figuriamoci quando entrano in gioco
applicazioni più complesse

Non penso affatto che sia semplice uscire da una tossicodipendenza.
Non entrarci e' molto piu' semplice, ovviamente.

La questione e' gia' stata discussa piu' volte.
Semplificando, IMHO i problemi principali nel *non* usare ECW sono:
- spazio occupato su disco
- velocita' di accesso.
Il secondo problema si risolve abbastanza bene tramite piramidi+tiles; il primo
invece no, ma considerando quanto costa un disco (i piu' costosi che ho trovato sono
sui 500 €), dubito proprio che possa essere significativo.
Per quanto mi riguarda, l'unica vera noia e' dover convertire i files (a seconda
dell'uso, in TIFF o JPEG, principalmente). Una volta fatta la conversione, sono a
posto. Visto che quello che faccio prima o poi va quasi sempre in rete, ECW per me
non e' un'opzione, anche se volessi usare formati proprietari. Ricordate: la versione
gratuita di ECW *non* consente l'uso server, quindi non si puo' usare ad es. in un
webgis; la licenza per l'uso server costa molto di piu' di una batteria di dischi e
un processore in piu'.

Se qualcuno ha un caso d'uso concreto, di cui ci possa dare i parametri (dimensione
dei files in ECW e in TIFF, tempi di accesso in entrambe i casi), sara' interessante
analizzarli, per verificare quali siano i problemi reali.

Saluti.

[unknown]

Da discussioni passate mi era sembrato di capire che per adeso non ci sono
soluzioni con le stesse perfomance in lettura di un ECW, neanche con
piramidi, overlay, ecc.
L'unico che sembra avvicinarsi Ú rasterlite, ma ancora troppo "di nicchia".

Ben vengano però altri benchmark... Io ho l'ultimo SDK ECW, e il vecchio
compressore free, però devo attrezzarmi per fare analisi di performance
serie, perché non le ho mai fatte.

Giovanni


Il giorno 12 giugno 2011 09:09, Paolo Cavallini <cavallini a faunalia.it> ha

Post by unknown

Post by unknown

Post by unknown
purtroppo non Ú così semplice, non lo Ú neppure per i file di
testo (odt vs doc/docx)...figuriamoci quando entrano in gioco
applicazioni più complesse

Non penso affatto che sia semplice uscire da una tossicodipendenza.
Non entrarci e' molto piu' semplice, ovviamente.

La questione e' gia' stata discussa piu' volte.
- spazio occupato su disco
- velocita' di accesso.
Il secondo problema si risolve abbastanza bene tramite piramidi+tiles; il primo
invece no, ma considerando quanto costa un disco (i piu' costosi che ho trovato sono
sui 500 €), dubito proprio che possa essere significativo.
Per quanto mi riguarda, l'unica vera noia e' dover convertire i files (a seconda
dell'uso, in TIFF o JPEG, principalmente). Una volta fatta la conversione, sono a
posto. Visto che quello che faccio prima o poi va quasi sempre in rete, ECW per me
non e' un'opzione, anche se volessi usare formati proprietari. Ricordate: la versione
gratuita di ECW *non* consente l'uso server, quindi non si puo' usare ad es. in un
webgis; la licenza per l'uso server costa molto di piu' di una batteria di dischi e
un processore in piu'.
Se qualcuno ha un caso d'uso concreto, di cui ci possa dare i parametri (dimensione
dei files in ECW e in TIFF, tempi di accesso in entrambe i casi), sara' interessante
analizzarli, per verificare quali siano i problemi reali.
Saluti.
--
Paolo Cavallini: http://www.faunalia.it/pc
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss a lists.gfoss.it
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

-------------- parte successiva --------------
Un allegato HTML ? stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20110612/aa089e2a/attachment.html>

[unknown]

Non vogliatemi male (non troppo almeno),

Ribadisco quello che gia' in altre occasioni ho gia' detto.

Senza scendere sull'aspetto tecnico,
basta fare questo ragionamento:

Il TIFF esiste da almeno 20 anni come formato , era gia' presente quando
facevo il secondo anno di universita' . Quindi e' preistorico..

L' ECW e' arrivato 10 anni fa' circa..
Fin all'arrivo dell' ECW tutti i raster che ho mai visto erano in TIFF
(salvo qualche esoterico formato incompatibile con il resto del mondo).

L'unica variante al TIFF (a parte il jpeg ma lo tengo fuori dal discorso
volutamente) era il MrSID.

Se l' ECW ha preso campo e si e' conquistato una sua nicchia di mercato
(perhce' e' di nicchia) il formato principe resta sempre il TIFF.

Vuol dire che aveva dei numeri per superare il TIFF, almeno in certi
impieghi. NON IN TUTTI !

La conversione da ECW a TIFF.
Non poi quella cosa cosi' impossibile.

Almeno per chi usa windows.
Chi usa windows, si scarica Irfanview.

www.irfanview.com

Non e' Foss, ma almeno e' gratuito e tra i suoi moduli ha il modulo per
leggere il ECW.
Attiva la sua procedura di conversione batch (irfanview e' fantastico in
questo) e converte tutti i suoi ecw in TIFF.
poi si prende il file .eww che affianca l' ecw e lo rinomina in .tfw.
E il gioco e' fatto.
Ecco dei bei files TIFF (di qualita' pari a quello che consente l'ecw)
accettabili.

A.

[unknown]

Ciao,
sono sempre stato interessato alla questione, soprattutto riguardo
alle presentazioni in ambito server.
Mi son divertito a fare un piccolo test, niente di professionale..roba
da domenica pomeriggio guardando un vecchio film di Totò alla tv:
partendo da delle ortofotocarte in ECW reperibili in rete, ho fatto un
po' di prove in ambito Desktop usando shp2img per confrontare l'ECW
con il TIFF ottimizzato.
I tempi di rendering erano sempre a favore del TIFF, con differenze di
circa un 30%.
Cercando in rete altre informazioni sul tema, ho trovato questo post:
http://osgeo-org.1803224.n2.nabble.com/WMS-Orthophoto-performance-td5363492.html

Qualcuno ha maggiori informazioni, magari per esperienza diretta o
test più professionali a riguardo?

Grazie a tutti
L.

Post by unknown
Non vogliatemi male (non troppo almeno),
Ribadisco quello che gia' in altre occasioni ho gia' detto.
Senza scendere sull'aspetto tecnico,
Il TIFF esiste da almeno 20 anni come formato , era gia' presente quando
facevo il secondo anno di universita' . Quindi e' preistorico..
L' ECW e' arrivato 10 anni fa' circa..
Fin all'arrivo dell' ECW tutti i raster che ho mai visto erano in TIFF
(salvo qualche esoterico formato incompatibile con il resto del mondo).
L'unica variante al TIFF (a parte il jpeg ma lo tengo fuori dal discorso
volutamente) era il MrSID.
Se l' ECW ha preso campo e si e' conquistato una sua nicchia di mercato
(perhce' e' di nicchia) il formato principe resta sempre il TIFF.
Vuol dire che aveva dei numeri per superare il TIFF, almeno in certi
impieghi. NON IN TUTTI !
La conversione da ECW a TIFF.
Non poi quella cosa cosi' impossibile.
Almeno per chi usa windows.
Chi usa windows, si scarica Irfanview.
www.irfanview.com
Non e' Foss, ma almeno e' gratuito e tra i suoi moduli ha il modulo per
leggere il ECW.
Attiva la sua procedura di conversione batch (irfanview e' fantastico in
questo) e converte tutti i suoi ecw in TIFF.
poi si prende il file .eww che affianca l' ecw e lo rinomina in .tfw.
E il gioco e' fatto.
Ecco dei bei files TIFF (di qualita' pari a quello che consente l'ecw)
accettabili.
A.
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss a lists.gfoss.it
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

[unknown]

Post by unknown
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'.
Saluti.

[unknown]

piccola nota, irfanview funziona benissimo anche su linux installandolo da
wine! quindi si evita almeno di usare windows!

Post by unknown
Non vogliatemi male (non troppo almeno),
Ribadisco quello che gia' in altre occasioni ho gia' detto.
Senza scendere sull'aspetto tecnico,
Il TIFF esiste da almeno 20 anni come formato , era gia' presente quando
facevo il secondo anno di universita' . Quindi e' preistorico..
L' ECW e' arrivato 10 anni fa' circa..
Fin all'arrivo dell' ECW tutti i raster che ho mai visto erano in TIFF
(salvo qualche esoterico formato incompatibile con il resto del mondo).
L'unica variante al TIFF (a parte il jpeg ma lo tengo fuori dal discorso
volutamente) era il MrSID.
Se l' ECW ha preso campo e si e' conquistato una sua nicchia di mercato
(perhce' e' di nicchia) il formato principe resta sempre il TIFF.
Vuol dire che aveva dei numeri per superare il TIFF, almeno in certi
impieghi. NON IN TUTTI !
La conversione da ECW a TIFF.
Non poi quella cosa cosi' impossibile.
Almeno per chi usa windows.
Chi usa windows, si scarica Irfanview.
www.irfanview.com
Non e' Foss, ma almeno e' gratuito e tra i suoi moduli ha il modulo per
leggere il ECW.
Attiva la sua procedura di conversione batch (irfanview e' fantastico in
questo) e converte tutti i suoi ecw in TIFF.
poi si prende il file .eww che affianca l' ecw e lo rinomina in .tfw.
E il gioco e' fatto.
Ecco dei bei files TIFF (di qualita' pari a quello che consente l'ecw)
accettabili.
A.
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss a lists.gfoss.it
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

[unknown]

Post by unknown
Il TIFF esiste da almeno 20 anni come formato , era gia' presente
quando facevo il secondo anno di universita' . Quindi e'
preistorico..

Il codice ASCII ha 43 anni.
La lingua italiana esiste da piu' di 100 anni.

Se si vuole _comunicare_ con altri e' solitamente
molto piu' efficace farlo con dei codici che hanno
avuto il tempo di essere interiorizzati dai soggetti
che si vogliono coinvolgere nella comunicazione, e
'oggettivizzati' all'interno di strumenti sviluppati
per facilitarne ulteriormente l'impiego.

Pensate a quanto sia capillare la radio. Piu' della TV.
Per ricevere delle trasmissioni radio esistono addirittura
dispositivi _senza_ batterie. Non conosco grosse esperienze
di TV libere, mentre ce ne sono moltissime di radio libere.

Semplificare e' importante.
La complessita' rende schiavi di chi sa gestirla.

--strk;

() Free GIS & Flash consultant/developer
/\ http://strk.keybit.net/services.html

[unknown]

Post by unknown

Post by unknown
I tempi di rendering erano sempre a favore del TIFF, con differenze

di

Post by unknown
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.

[unknown]

Post by unknown
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.

Post by unknown
Punto b)
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 --

[unknown]

Post by unknown
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.

[unknown]

Post by unknown
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.

Post by unknown
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ò , 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.

Post by unknown
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.
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 --

[unknown]

Post by unknown
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.

[unknown]

Post by unknown
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 --

Post by unknown
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.

[unknown]

Ciao Giovanni,

Post by unknown

Post by unknown
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.

[unknown]

Post by unknown
- 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 --

[unknown]

Post by unknown

Post by unknown
- 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.

[unknown]

Post by unknown

Post by unknown
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ò , 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.
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.

[unknown]

Post by unknown
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 --

[unknown]

Post by unknown
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.

[unknown]

La prova del punto b)

e' troppo parziale...

e' piu' generale se svolta cosi':

sempre sul WMS:
prendi qualche decina di tiff da 2-300Mbyte ciascuno.

(un raster OFC di una sezione 10K a colori viaggia sui 300-400 Mbytes)

tagliuzzali tutti in tiles e tiff non compressi.

Ed esponibili via WMS.

Poi prova a costruire una mappa su qgis, usando il WMS, che coinvolga a
una scala opportuna 4-6 di questi tiffs.

Poi prova a stampare in A0.

questa e' la prova da fare.

Per farla per bene, dovresti provare a farla invocando la stampa da
almeno 2-3 pc insieme, infatti.
Se per produrre una mappa di 10.000 x 10.000 pixel a milioni di colori
(ovvero 3byte per pixel) e per spedirtela in wms via rete ci impiega del
tempo, in tutto quel tempo il WMS probabilmente non risponde a nessun altro.
Per cui la prova giusta e' ipotizzare di far lavorare il WMS da piu'
postazioni in contemporanea per simulare la situazione reale...


Andrea.

[unknown]

Post by unknown
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.

Ti stai riferendo al caso in cui il server WMS supporta l'output in
formati tiled ?

Andrea.

[unknown]

Post by unknown
Ti stai riferendo al caso in cui il server WMS supporta l'output in
formati tiled ?

no

[unknown]

Post by unknown
Ti stai riferendo al caso in cui il server WMS supporta l'output in
formati tiled ?

no

Allora mi manca decisamente qualcosa.

Come fa qgis a conoscere la dimensione massima in pixel chiamabile sul
server wms ?

senza questa informazione l'unica opzione che riesco a immaginare e' che
gliela dica l'utente , ma non ho trovato alcuna opzione che permetta questo.

.. ?...

Andrea.

[unknown]

Post by unknown
senza questa informazione l'unica opzione che riesco a immaginare e' che
gliela dica l'utente , ma non ho trovato alcuna opzione che permetta questo.

é quello che stavo cercando di spiegare da un pó... (magari é colpa mia,
non parlo quasi piú Italiano).

L'opzione c'é in qgis > 1.6 (vedere allegato)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot-1.jpg
Type: image/jpeg
Size: 67609 bytes
Desc: not available
URL: <Loading Image...>

[unknown]

Post by unknown

Post by unknown
senza questa informazione l'unica opzione che riesco a immaginare e' che
gliela dica l'utente , ma non ho trovato alcuna opzione che permetta questo.

é quello che stavo cercando di spiegare da un pó... (magari é colpa mia,
non parlo quasi piú Italiano).
L'opzione c'é in qgis> 1.6 (vedere allegato)

Non la conoscevo proprio.

E' una opzione decisamente utile.
Domani faccio subito delle prove di stampa ..

Grazie infinite,

Andrea.