[Gfoss] presentazione e nota su una email ricevuta dal PCN

[Cristoforo Abbattista]

>> questa distinzione tra protocolli, formati, architetture. All'utente
>> interessa: "io chiedo una mappa, tu in quanto tempo me la dai?"
>>     
>
> Il punto e' proprio questo.
>
> L'utente non puo' limitarsi a chiedere "tu in quanto tempo mi dai la mappa?"
> Ma bensi' dovrebbe chiedersi in quanto tempo me la metti a disposizione?.
>
> Perche' questo si riferirebbe al tempo con cui il server la mette a
> disposizione nel proprio spazio web.
> Poi sta' all'utente prelevarsela. Se l'utente ha un collegamento lento
> ci impieghera' tanto tempo,
> se il collegamento e' veloce ce ne impieghera' meno.
>   
condivido
> per cui nella domanda "in quanto tempo mi dai la mappa?"
> L'utente ci dovrebbe mettere anche il tempo con cui
> il suo collegamento internet riesce a portargliela a casa.
>
> E questo penso siamo tutti daccordo che non dipenda dalla parte server.
>
> E potremmo avere anche il sistema di produzione mappe piu' efficiente
> dell' universo, un sistema che produca mappe in un miliardesimo di
> secondo.
> Il collo di bottiglia, ovvero il tempo che supera tutti gli altri come
> dimensione e quindi determina la maggior parte del ritardo
> sara' sempre e solo il tempo di trasferimento verso il browser-client.
> E qui pesa il tipo di collegamento che ha l'utente.
>   
Nel caso specifico i numeri reali che ho riportato e che voi potreste 
sperimentare, dimostrano che la mappa viene prodotta in 10 secondi e poi 
io l'ho portata a casa in 1 secondo.
Il collo di bottiglia è un server (servizio) non implementato al meglio, 
il cui lavoro si ripercuote anche sul trasferimento in rete: viene 
fornito un PNG invece che un JPEG per una mappa raster.
> per cui e' inutile avere dei sistemi super-efficienti se i
> collegamenti internet da casa non sono all'altezza.
>   
Abbastanza in disaccordo. Se progetto un servizio è perchè penso che 
mediamente il pubblico possa usufruirne, e lo possa fare anche in 
maniera gradevole. Di questo pubblico io  posso solo ipotizzare il 
dimensionamento tecnologico per ciò che riguarda l'HW, il SW, la rete.
Io utente oggi non posso vedere un film a colori se ho la TV in bianco 
in nero. Forse nemmeno nelle partite di calcio fanno più in modo che una 
squadra abbia la casacca molto chiara e l'altra molto scura. Insomma 
alcune assunzioni le dobbiamo fare.
L'alternativa sarebbe non fornire informazione, e chiaramente zero byte 
vengono trasferiti molto velocemente su tutte le reti.
> Ora nele prec. interventi si era fatto un conto a braccio con 8MB ci
> impiega 0.1 sec.
>
> se il collegamento e' a 800.000 B/s ci impiegherebbe 1 sec.
>
> e questo indipendentemente da quanto velocemente il server ha prodotto la mappa.
>   
infatti il problema nel servizio in questione sta nel server non nella 
banda (10 secondi a 1).
>   
>> Non capisco perchè parli di dpi,
>>     
>
> Il discorso e' lungo.
>
> Diciamo che trattandosi di immagini georeferenziate, ovvero in cui a
> un pixel corrisponde
> una certa lunghezza in metri (o inch appunto). Il parametro DPI e'
> molto rilevante.
> Molto piu' dei pixel.
>
> perche' se ad esempio l'immagine originale esprime 1 metro per ogni
> pixel, finche' non si e'
> recuperato una immagine che esprima 1 metro per pixel, si puo'
> ritenere che l'immagine presa
> sia una approssimazione di quella originale.
>   
Chiaramente io parto dal presupposto che tutti rispettino il teorema di 
Shannon. Dal produttore dell'informazione allo scaricatore.
Tra l'altro i dot di un'informazione digitale sono i pixel. Diverso 
sarebbe nel caso in cui la fonte primaria fosse una fonte analogica, e 
lì, come già detto, presuppongo che Shannon sia stato ossequiato.
> In questo tipo di recupero una trasmissione differenziale (con l'ecwp)
> facilita molto il lavoro
> rispetto a una flat (con il wms).
> perche' si puo' operare per step successivi a differenti livelli di dettaglio.
>
> mentre in quella wms devi fin da subito operare al massimo dettaglio.
>   
Indipendentemente dal processo, alla fine sono sempre circa 5 byte di 
Jpeg per ogni byte di ecw via ecwp; al netto dei protocolli di supporto. 
Infatti a parità di informazione tutto si gioca sulla bontà 
dell'algoritmo di compressione ed risaputo che la wavelet è più 
performante rispetto alla DCT. Di questo ne sono certo.

ciao
    Cristoforo
> Ciao,
> Andrea.
>
>
>   


-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://www.faunalia.com/pipermail/gfoss/attachments/20081015/fbaf4219/attachment-0001.htm>