[Gfoss] presentazione e nota su una email ricevuta dal PCN
Cristoforo Abbattista
abbattista a planetek.it
Mer 15 Ott 2008 12:22:38 CEST
-------- Messaggio Originale --------
Oggetto: Re:[Gfoss] presentazione e nota su una email ricevuta dal PCN
Da: Andrea Peri <peri.rtoscana a gmail.com>
A: gfoss a faunalia.it
Data: mercoledì 15 ottobre 2008 9.02.59
> Effettivamente e' [OT], ma non troppo.
>
> Comunque ritengo utile dare un contributo tecnico per uscire dal
> discorso altrimenti troppo propagandistico.
>
Non volevo proprio farlo, volevo solo chiarire che, da tecnico, ECW,
ECWP e IWS possono essere molto sicuri se si vuole.
Per le performance penso proprio che non ci siano dubbi.
Per il suo utilizzo, ogni buon ingegnere dovrà farsi l'analisi del TCO
andando al di là della mera questione economica. Oggi un costo, a mio
avviso, è anche la rinuncia ad avere un formato, un protocollo, un
software libero, per tutte le implicazioni che tale scelta potrà avere.
> Ovviamente questo implica che l' ECW viene usato a monte dell'uscita,
> ovverosia per permettere al sistema di generazione delle mappe di
> poter fruire di tali dati con la velocita' (efficienza) che gli
> permette il formato ecw.
>
Giustissimo
> ovviamente questo funzionerebbe con qualunque sistema di generazione
> mappe che supporti tale formato (MapServer, ArcIMS o quant'altro).
>
La licenza, come più volte ribadito dal buon Lovergine non era
chiarissima su questo punto. Diciamo che non lo consentirebbe. Ma non è
questo il punto.
> Quindi in questo senso il ricorso al protocollo WMS anziche' al
> protocollo ECWP comporta globalmente una perdita di performance.
>
correttissimo
> Pero' rimanendo all'interno della galassia WMS, il ricorso al formato
> piramidale, e' un qualcosa che avviene dietro le quinte per la
> produzione della mappa e non coinvolge l'uscita dove la differenza
> viene fatta tra la scelta WMS+HTTP e ECWP.
>
> Per cui il discorso sulle performance della rete, e il ricorso al ping
> come metodo rapido, ancorche' grossolano e poco preciso, per valutarne
> le prestazioni resta valido.
>
Con la differenza che le mie affermazioni sono fatte con cognizione di
causa e non per presupposti teorici, peraltro da me condivisi.
Indubbiamente il PING certe informazioni le darebbe pure, ma con firebug
salta fuori che un pezzo generico di ortofoto viene prodotto dal
MapServer generico in circa 9-15 secondi e ne viene generato un PNG
(immagino sia a 24 bit), che è chiaramente un ulteriore problema. Il
povero PNG (circa 1000 x 800 px ~ 500 kByte) arriva all'utente in 1-1.5
secondi sulla nostra connessione FastWeb 10mbps. Ovvio che se fosse
generato un JPEG il trasferimento sarebbe più veloce, ma sui tempi di
generazione si rimane bloccati lì.
Quindi, secondo il mio modesto parere, la CPU (e quindi i suoi processi)
prima di tutto. Il collo di bottiglia è nel Mapserver che genera la mappa.
Inoltre, per quello che è la mia esperienza su svariate applicazioni
WebGIS per la PA con TeraByte di dati da archiviare, catalogare,
servire, posso affermare che IWS essendo un prodotto totalemente
orientato a servire mappe raster enormi (singoli file di qualche
terabyte) ad alte perfomance per un elevato numero di utenti in
contemporanea (migliaia) svolge un lavoro eccellente (intendo dire
superiore agli altri) sia utilizzando il protocollo ECWP che gli altri
di cui dispone, tra cui il WMS.
Infatti non basta avere il driver per un formato, bisogna saperlo
gestire nel contesto applicativo specifico e qui il prodotto può fare la
differenza.
> Infatti si parlava dei tempi per veicolare la mappa dal server al
> client e non si consideravano i tempi necessari per la produzione
> della medesima. Ove pesa non solo il formato di memorizzazione, ma
> anche il tipo di macchine e l'architettura coinvolta.
>
Guarda, ritengo che all'utente di un portale non interessi affatto
questa distinzione tra protocolli, formati, architetture. All'utente
interessa: "io chiedo una mappa, tu in quanto tempo me la dai?"
> Per cui se si parla di tempi di trasferimento tra server e client puo'
> essere rilevante il ricorso al protocollo ECWP, anziche' l' http del
> WMS, e non e' rilevante il distinguo tra sistemi di memorizzazione
> piramidale (ecw) anziche' no' non modifica in alcun modo i risultati
> dell'analisi (tempi di trasferimento via rete) perche' trattasi di un
> qualcosa che avviene a monte.
>
> Ovviamente questo non implica che poiche' quello che conta e' il tempo
> globale non sia opportuno il ricorso a tecniche di memorizzazioni
> efficienti, ma potrebbero essere anche memorizzazioni in altri formati
> differenti dall' ecw (jpeg2000 ?) oppure memorizzazione su sistemi
> DBMS.
>
>
>> Questo perchè la sicurezza non è implicita nei sistemi. La sicurezza va
>> implementata.
>>
>
> Questo e' scontato.
>
> Pero' secondo me' quando si parla di sicurezza non si intende tanto la
> sicurezza per l'accesso (accounting e quant'altro) , quanto la
> sicurezza di conservare il dato originale.
>
Concordo pienamente e infatti i riferimenti forniti erano orientati in
questa direzione. Parlo di proteggere il dato dall'accesso ed utilizzo
incondizionato. Sempre nei limiti del possibile informatico.
> In questo senso la diffusione delle librerie di lettura del formato
> ECW ha reso, per assurdo, il formato ecw meno sicuro, perche'
> consente a chiunque di fare un software che scarichi i dati in maniera
> batch a colpi di tiles e richiedendolo fino a un livello di dettaglio
> massimo.
> Inoltre l'impiego del protocollo ecwp rende questa operazione piu'
> rapida rispetto a quello che potrebbe avvenire con protocolli piu'
> "legnosi" quale ad esempio il WMS.
>
> Che poi si possa fare anche con il WMS niente da eccepire.
>
> pero' si tratta sempre di mappe generate con 100dpi e quindi per
> riprendersi il livello di dettaglio dell'originale servirebbero bande
> e tempi ben maggiori rispetto a quelli che permetterebbe il protocollo
> ecwp.
>
Non capisco perchè parli di dpi, ma parlando di byte tra JPG ed ECW la
differenza in media potrebbe essere intorno a 5 volte. Ossia un tempo 5
volte superiore per il trasferimento WMS rispetto ad ECWP più gli
eventuali tempi di processamento per la generazione dei JPEG. Ma ritengo
che quest'ordine di grandezza di tempi possa non essere un problema.
Ciao
Cristoforo
> Ciao,
>
>
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://www.faunalia.com/pipermail/gfoss/attachments/20081015/251b275a/attachment.htm>
Maggiori informazioni sulla lista
Gfoss