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

Local Chapters GFOSS.it
1

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?"

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.

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.

per cui e' inutile avere dei sistemi super-efficienti se i
collegamenti internet da casa non sono all'altezza.

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.

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.

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.

Ciao,
Andrea.

--
~~~~~~~~~~~~~~~~~
§ Andrea §
§ Peri §
~~~~~~~~~~~~~~~~~

2 
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.