presentazione e nota su una email ricevuta dal PCN

[Christian Pellegrin]

Buongiorno,

prima di tutto mi presento: sono uno sviluppatore prevalentemente di e
su software libero. Da un po' mi occupo di GIS soprattutto dal punto
di vista hobbystico (legato all'attività escursionistica ed
alpinistica) ma credo che il campo abbia delle importanti prospettive
da tutti i punti di vista. Spero di poter imparare grazie alla
comunità GFOSS e magari di poter contribuire (come ogni buon cittadino
del mondo del software libero).

La ragione per la quale ho fatto una ricerca su chi si occupa di
problematiche riguardo alla libertà dei geodati è, ahimè, non proprio
bella. Volevo segnalarvi un'email che copio sotto che mi è arrivata
come utente del Portale Cartografico Nazionale. Francamente mi sono
sentito preso in giro quando mi è stato dato (genericamente come
cittadino) del ladro o quantomeno del furbetto. Essendo il Ministero
dell'Ambiente e l'IGM enti pubblici pagati dalle tasse (Grillo direbbe
persino che si tratta di nostri dipendenti) non vedo perché i dati non
dovrebbero essere di tutti noi. Cosa normale in altri paesi come gli
Stati Uniti. Credo che questo aspetto sia ancora più importante oggi,
all'alba dell'introduzione di tutta una serie di servizi "location
based" che sicuramente andranno ad influire sulla nostra vita
quotidiana e per questo potranno aumentare ma anche limitare la nostra
libertà di cittadini.

Saluti,

----8<-----------
Gentili utenti,

riteniamo opportuno l'invio di questa comunicazione perché riceviamo
da qualche tempo, attraverso la e-mail del Portale Cartografico,
diverse considerazioni su due temi in particolare, su cui vogliamo
illustrare le motivazioni che ci hanno portato alle scelte operate.



Il primo dei temi ricorrenti è quello che riguarda il vecchio portale,
che sembra essere stato molto gradito a molti utenti rispetto a quello
attuale.

La vecchia versione del portale si appoggiava sulla cartografia
pubblicata tramite il protocollo ECWP, che sicuramente consentiva una
maggiore fluidità nella navigazione, ma presentava un considerevole
problema di sicurezza dei dati.

L'impiego dei servizi ECWP ha consentito a  diversi soggetti utenti
del portale, per i loro fini utilitaristici, di "depredare" il
Ministero dell'Ambiente dei dati cartografici messi a disposizione,
costringendoci all'impiego di attività e risorse pubbliche per la loro
tracciatura e la conseguente messa in atto di contromisure come
l'inibizione del loro acceso a  questi dati.



A causa di questi inconvenienti, questa Amministrazione ha deciso di
non pubblicare ulteriormente cartografia in formato ECWP, ma di
utilizzare tecnologie meno vulnerabili, pur rendendoci conto che la
maggior  parte  degli utenti hanno sempre utilizzato il Portale
rimanendo all'interno delle regole di buona cittadinanza.

Attualmente le nostre  cartografie sono disponibili per la
consultazione tramite visualizzatore on line e mediante i servizi WMS,
nel rispetto degli standard internazionali. Si sta comunque lavorando
affinché la visualizzazione e interrogazione sia la stessa del vecchio
Portale.





Il secondo tema ricorrente nelle vostre e-mail riguarda la lentezza
riscontrata nella navigazione della cartografia, a volte confrontata
anche con le prestazioni  della precedente versione del Portale.



Attualmente abbiamo evidenze che ci permettono di considerare le
prestazioni del Portale più che accettabili, ma ci rendiamo conto che
su questo tema una maggior disponibilità di prestazioni viene
sicuramente gradita.

Possiamo assicurarvi che lo staff che gestisce il Portale è impiegato
quotidianamente per migliorare le applicazioni ed i sistemi
informatici per offrire un servizio continuamente in crescita dal
punto di vista prestazionale.



Dobbiamo però ricordarvi che in molti casi la causa della lentezza
operativa potrebbe non essere imputabile a noi.

Attualmente il Portale Cartografico Nazionale ha a disposizione una
banda di 100 Mb/sec per le connessioni internet e, dalle nostre
misure, la sua occupazione in condizioni di massimo carico non supera
mai il 30%  e questo ci fa pensare che i problemi di cui stiamo
parlando non siano dovuti al nostro sistema informatico.

I problemi di performance, quindi, potrebbero spesso esser dovuti alla
rete personale e/o aziendale di chi accede al Portale, alla presenza
su di essa di Proxy o Firewall che ne limitano il traffico o
semplicemente alle configurazioni scelte per gli apparati di rete
presenti.



Nell'ottica del miglioramento continuo del servizio offerto, riteniamo
comunque di intraprendere un percorso costruttivo con voi utenti,
volto a migliorare l'accesso efficiente di ciascuno al Portale.



Abbiamo pensato di sottoporre, a chi lamenta problemi di prestazioni,
una serie di misure elementari da eseguire sulla propria  workstation,
al fine di fornirci dei dati oggettivi su cui lavorare per eliminare
qualunque problema esistente.

Vi elenchiamo in  fondo a questa e-mail queste operazioni elementari,
pregandovi di inviarci il file che riassume i risultati ottenuti.



Siamo sicuri di aver sollecitato in voi la comprensione delle
motivazioni che ci spingono a gestire come facciamo il Portale
Cartografico Nazionale, assicurandovi da parte nostra un impegno
sempre in crescita per venire incontro alle esigenze di chi lo
utilizza.





----------



Passi da eseguire per effettuare un  test di connettività :

1. Apertura di un prompt dei comandi.

2. Esecuzione del comando: ping www.pcn.minambiente.it –t

3. Dopo 5 secondi schiacciare i tasti ctrl+C per interrompere
l'esecuzione del comando ping.

4. Salvataggio dei risultati con copia/incolla in un file di testo
oppure in una screenshot per l'invio al PCN.

5. Esecuzione del comando: tracert www.pcn.minambiente.it

6. Salvataggio con copia/incolla dei risultati in un file di testo
oppure in una screenshot per l'invio al PCN.

7. Invio, tramite mail, dei risultati al PCN.


Note:
Il comando ping invia una serie di pacchetti TCP verso un indirizzo di
rete ed aspetta una risposta misurando i tempi di trasmissione; questo
test è indicativo della velocità della connessione nei nostri
confronti.
Il comando tracert traccia il percorso che ogni pacchetto compie per
raggiungere i nostri server, evidenziando ogni passaggio nella rete;
questo test evidenzia i passaggi attraverso Firewall o altri apparati
di rete che potrebbero essere responsabili del rallentamento della
comunicazione.

Distinti saluti

Lo staff

Portale Cartografico Nazionale

Direzione Generale per la Difesa del Suolo

Ministero dell'Ambiente della Tutela del Territorio e del Mare

ROMA
----8<-----------


--
Christian Pellegrin, see http://www.evolware.org/chri/
"Real Programmers don't play tennis, or any other sport which requires
you to change clothes. Mountain climbing is OK, and Real Programmers
wear their climbing boots to work in case a mountain should suddenly
spring up in the middle of the computer room."
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.

[Francesco P. Lovergine-3]

On Thu, Oct 09, 2008 at 02:31:37PM +0200, chri wrote:
> 2. Esecuzione del comando: ping www.pcn.minambiente.it –t
>

PING www.pcn.minambiente.it (62.152.115.215) 56(84) bytes of data.
64 bytes from 62.152.115.215: icmp_seq=1 ttl=119 time=11.3 ms
64 bytes from 62.152.115.215: icmp_seq=1 ttl=119 time=11.4 ms (DUP!)
64 bytes from 62.152.115.215: icmp_seq=1 ttl=119 time=11.6 ms (DUP!)
[...]

Pensare poi di valutare le prestazioni di un web service a forza
di ping ritengo qualifichi completamente chi gestisce il suddetto
servizio. E non aggiungo altro.

--
Francesco P. Lovergine
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.

[Andrea Peri]

>A causa di questi inconvenienti, questa Amministrazione ha deciso di
>non pubblicare ulteriormente cartografia in formato ECWP, ma di
>utilizzare tecnologie meno vulnerabili

Beh,

Lasciando stare il resto della lettera su cui non posso esprimermi
visto che non sono un utente di tale portale.

Intanto dicono che non useranno piu' il protocollo ECWP.

Fino ad oggi su questa ML si era discusso del formato ECW.
Ma si era sempre tenuto fuori dalla discussione il protocollo ECWP.
Ma anche esso era un protocollo proprietario.

Ora viene abbandonato.
Per me questa e' una buona notizia.

Per il resto non saprei.

--
~~~~~~~~~~~~~~~~~
§       Andrea              §
§         Peri                 §
~~~~~~~~~~~~~~~~~
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.

[Andrea Peri]

>PING www.pcn.minambiente.it (62.152.115.215) 56(84) bytes of data.
>64 bytes from 62.152.115.215: icmp_seq=1 ttl=119 time=11.3 ms
>64 bytes from 62.152.115.215: icmp_seq=1 ttl=119 time=11.4 ms (DUP!)
>64 bytes from 62.152.115.215: icmp_seq=1 ttl=119 time=11.6 ms (DUP!)
>[...]
>
>Pensare poi di valutare le prestazioni di un web service a forza
>di ping ritengo qualifichi completamente chi gestisce il suddetto
>servizio. E non aggiungo altro.

La performance di un servizio GIS online e' composta di vari elementi.
certamente uno dei piu' rilevanti e' il tempo di produzione della mappa.

pero' in certe realta' non va ignorato i tempi di trasferimento della
mappa dal server di produzione verso il client in ascolto.

La ragione per cui chiedono l'informazione del ping e' per stimare (a
spanna) tali tempi.

Infatti se la banda con cui uno accede al portale e' bassa, il tempo
per ricevere una mappa da 100Kbyte sara' superiore al tempo che viene
impiegato da chi vi accede tramite  una ADSL a banda elevata.

certamente il metodo del ping e' di per se' poco efficiente.
perche' il percorso del ping e' senz'altro differente rispetto a
quello di una risposta HTTP.
Pero' una indicazione di massima la da'.

Io caso mai farei notare una altra questione.

nella lettera del PCN viene detto che la banda disponibile e' di 100 MB/s

ma non e' chiaro se tale valore e' il livello di picco o la banda garantita.
La differenza non e' banale.
100 MB/s garantiti in upload (per loro e' upload) costano tantissimo.

100MB/s con soli 8 MB/s garantiti costano molto meno.

Io ad esempio ho un contratto ADSL con 8 MB/s di banda con Telecom per
navigare su Internet,
Ma non sono garantiti, nel senso che praticamente posso scordarmi di
navigare a 8 MB/s ,
al massimo se mi va bene questo lo potro' fare a notte fonda.
Di giorno e' grassa se vado a 512Kb.
ovviamente a me bastano e avanzano, per cui non ho ragione di lamentarmi.
Pero' in altri casi questo potrebbe creare degli equivoci.





--
~~~~~~~~~~~~~~~~~
§       Andrea              §
§         Peri                 §
~~~~~~~~~~~~~~~~~
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.

[Ivano Picco-2]

Occhio a MB/s e Mb/s, perchè la differenza è di 8 volte: 1MB/s = 8Mbit/s

Lo so che son pistino, ma m'han fatto ingegnere, che ci posso fare?

2008/10/10 Andrea Peri <peri.rtoscana@...>

>PING www.pcn.minambiente.it (62.152.115.215) 56(84) bytes of data.
>64 bytes from 62.152.115.215: icmp_seq=1 ttl=119 time=11.3 ms
>64 bytes from 62.152.115.215: icmp_seq=1 ttl=119 time=11.4 ms (DUP!)
>64 bytes from 62.152.115.215: icmp_seq=1 ttl=119 time=11.6 ms (DUP!)
>[...]
>
>Pensare poi di valutare le prestazioni di un web service a forza
>di ping ritengo qualifichi completamente chi gestisce il suddetto
>servizio. E non aggiungo altro.

La performance di un servizio GIS online e' composta di vari elementi.
certamente uno dei piu' rilevanti e' il tempo di produzione della mappa.

pero' in certe realta' non va ignorato i tempi di trasferimento della
mappa dal server di produzione verso il client in ascolto.

La ragione per cui chiedono l'informazione del ping e' per stimare (a
spanna) tali tempi.

Infatti se la banda con cui uno accede al portale e' bassa, il tempo
per ricevere una mappa da 100Kbyte sara' superiore al tempo che viene
impiegato da chi vi accede tramite  una ADSL a banda elevata.

certamente il metodo del ping e' di per se' poco efficiente.
perche' il percorso del ping e' senz'altro differente rispetto a
quello di una risposta HTTP.
Pero' una indicazione di massima la da'.

Io caso mai farei notare una altra questione.

nella lettera del PCN viene detto che la banda disponibile e' di 100 MB/s

ma non e' chiaro se tale valore e' il livello di picco o la banda garantita.
La differenza non e' banale.
100 MB/s garantiti in upload (per loro e' upload) costano tantissimo.

100MB/s con soli 8 MB/s garantiti costano molto meno.

Io ad esempio ho un contratto ADSL con 8 MB/s di banda con Telecom per
navigare su Internet,
Ma non sono garantiti, nel senso che praticamente posso scordarmi di
navigare a 8 MB/s ,
al massimo se mi va bene questo lo potro' fare a notte fonda.
Di giorno e' grassa se vado a 512Kb.
ovviamente a me bastano e avanzano, per cui non ho ragione di lamentarmi.
Pero' in altri casi questo potrebbe creare degli equivoci.

--
~~~~~~~~~~~~~~~~~
§       Andrea              §
§         Peri                 §
~~~~~~~~~~~~~~~~~
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.

[Francesco P. Lovergine-3]

On Fri, Oct 10, 2008 at 11:02:08AM +0200, Andrea Peri wrote:

> >PING www.pcn.minambiente.it (62.152.115.215) 56(84) bytes of data.
> >64 bytes from 62.152.115.215: icmp_seq=1 ttl=119 time=11.3 ms
> >64 bytes from 62.152.115.215: icmp_seq=1 ttl=119 time=11.4 ms (DUP!)
> >64 bytes from 62.152.115.215: icmp_seq=1 ttl=119 time=11.6 ms (DUP!)
> >[...]
> >
> >Pensare poi di valutare le prestazioni di un web service a forza
> >di ping ritengo qualifichi completamente chi gestisce il suddetto
> >servizio. E non aggiungo altro.
>
> La performance di un servizio GIS online e' composta di vari elementi.
> certamente uno dei piu' rilevanti e' il tempo di produzione della mappa.
>
> pero' in certe realta' non va ignorato i tempi di trasferimento della
> mappa dal server di produzione verso il client in ascolto.
>
> La ragione per cui chiedono l'informazione del ping e' per stimare (a
> spanna) tali tempi.
>
> Infatti se la banda con cui uno accede al portale e' bassa, il tempo
> per ricevere una mappa da 100Kbyte sara' superiore al tempo che viene
> impiegato da chi vi accede tramite  una ADSL a banda elevata.
>
> certamente il metodo del ping e' di per se' poco efficiente.
> perche' il percorso del ping e' senz'altro differente rispetto a
> quello di una risposta HTTP.
> Pero' una indicazione di massima la da'.
>

Qui andiamo decisamente OT: Diciamo pure che mi aspetto che icmp e tcp abbiano
queuing differente, compreso dropping di icmp rispetto a tcp all'occorrenza quando
si fa shaping della banda - e tcp fra l'altro ha congestion control, mentre icmp no.
Il risultato netto e' che usare icmp per valutazioni spannometriche e'
fuorviante nella maggior parte dei casi. Avessero detto: andate all'url X e scaricate
il file Y via http, sarebbe stato piu' corretto per una valutazione del tipo
che serve a loro.

Comunque transit, A lume di naso se una feature offre ECW e una navigazione e
zomming rapidi su grosse moli di dati. Pensare che  tiling e caching di sistemi
alternativi sia ugualmente efficace mi pare ottimistico. Ci credo che so'
lenti :-) Se poi aggiungiamo che mapserver secondo molti offre un 30% di
prestazioni in piu' rispetto a ArcIMS .

> Io caso mai farei notare una altra questione.
>
> nella lettera del PCN viene detto che la banda disponibile e' di 100 MB/s
>
> ma non e' chiaro se tale valore e' il livello di picco o la banda garantita.
> La differenza non e' banale.
> 100 MB/s garantiti in upload (per loro e' upload) costano tantissimo.
>
> 100MB/s con soli 8 MB/s garantiti costano molto meno.
>

Sono 100Mb/sec aggregati, come e' normale che sia. E notare il 'b' e non 'B' :)
Quindi l'equivalente di una normale fastethernet. Considerato che non e' assolutamente
un valore da rete geografica (2-4-8-16Mb, 34Mb, 155Mb, 2.5Gb e multipli sono valori credibili)
direi che si riferiscono puramente alla velocita' della porta vlan assegnata al server,
non alla banda di connessione. SE il loro backbone ha disponibilita' ben superiore a quei
valori, FORSE si saturano quei 100Mb :-) Dipende pure dal traffico complessivo.

Come confronto:

http://www.garr.it/reteGARR/velocita.php?idmenu=rete

ma non so in RUPA come stanno messi.

--
Francesco P. Lovergine
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.

[Francesco P. Lovergine-3]

On Fri, Oct 10, 2008 at 10:47:07AM +0200, Andrea Peri wrote:
> Fino ad oggi su questa ML si era discusso del formato ECW.
> Ma si era sempre tenuto fuori dalla discussione il protocollo ECWP.
> Ma anche esso era un protocollo proprietario.
>
> Ora viene abbandonato.
> Per me questa e' una buona notizia.

Mezza buona notizia, considerato che l'implementazione con ArcIMS impedisce
l'uso di un client che non sia marcato ESRI. Che hanno fatto? Sostituito
un coso proprietario, con un altro coso proprietario. Ganzi! Almeno prima si
poteva succhiare una fettina ECW via GDAL, adesso manco quello.
Rimando al thread di fine agosto in merito.
A proposito come e' finita la lettera?

http://www.nabble.com/Portale-Cartografico-Nazionale-e-ArcIMS-to12354725.html#a12386406

--
Francesco P. Lovergine
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.

[Francesco P. Lovergine-3]

On Fri, Oct 10, 2008 at 11:46:01AM +0200, Francesco P. Lovergine wrote:
> Comunque transit, A lume di naso se una feature offre ECW e una navigazione e
  Se una feature offre ECW E' una navigazione ....
  Sorry :)

--
Francesco P. Lovergine
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.

[Andrea Peri]

Giusta osservazione.

Infatti non ho scritto MB/s a caso.

intendo proprio MegaBit e non Megabyte.

salvo in un punto ove erroneamente ho scritto Kb.
>> al massimo se mi va bene questo lo potro' fare a notte fonda.
>> Di giorno e' grassa se vado a 512Kb.

Comunque, tornando alle considerazioni:

100Kbyte di immagine = 100 * 1024 * 8bit = 819.200 bit

dopodiche':
819.200 / ( 8.000.000 MB/s ) = 0,1024 secondi per riceverla.

Questo se si navigasse a 8.000.000 B/s (cosa che da casa non avviene mai).

Ovviamente non conteggio in questo conto a spanna il fatto che a livello
http, ethernet, e tcp.
Il frame viene arricchito da degli header che aumentano lo spazio .
Onde per cui per veicolare via internet una mappa da 100Kbyte,
in realta' si spedisce di piu' .
E poi andrebbe considerato che i pacchetti TCP sono piccoli e quindi
l'header TCP pesa su ogni pacchettino.
Infine Andrebbe considerato il routing, che potrebbe ulteriormente
aumentare i tempi.

Tutta robetta, che concorre ad aumentare i tempi.....

Scusate la mia ulteriore precisazione , ma purtroppo anche io sono ingegnere,
e "elettronico" per giunta (brutta razza).

Saluti,

>Occhio a MB/s e Mb/s, perchè la differenza è di 8 volte: 1MB/s = 8Mbit/s
>
>Lo so che son pistino, ma m'han fatto ingegnere, che ci posso fare?


--
~~~~~~~~~~~~~~~~~
§       Andrea              §
§         Peri                 §
~~~~~~~~~~~~~~~~~
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.

[Sandro Santilli]

On Thu, Oct 09, 2008 at 02:31:37PM +0200, chri wrote:

> L'impiego dei servizi ECWP ha consentito a  diversi soggetti utenti
> del portale, per i loro fini utilitaristici, di "depredare" il
> Ministero dell'Ambiente dei dati cartografici messi a disposizione,

 depredare
 
 1 Spogliare con violenza qlcu. o un luogo di un bene SIN saccheggiare; freq. al passivo: la biblioteca fu depredata di tutti i volumi
 
 2 fig. Nel l. fam., con valore iperb., privare qlcu. di qlco. che gli spetta: l'arbitro ci ha depredato della vittoria
 
 sec. XIV

Di cosa e' stato privato il Ministero dell'Ambiente ?
E con quale inaudita violenza ?!

--strk;
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.

[Christian Pellegrin]

2008/10/10 strk <strk@...>:

>
> Di cosa e' stato privato il Ministero dell'Ambiente ?
> E con quale inaudita violenza ?!
>


Credo che questo tono sia il lato peggiore del tutto.

Del lato tecnico non ho provato molto quanto è cambiato. Essendo
connesso al mondo tramite l'ISDN l'unico modo per fare qualcosa di
serio (== che va oltre il mostrare alla nonna che bello che si vede la
sua casa dall'alto) è avere i dati locali. Anche l'impossibilità di
avere una cache locale è una "barriera internettonica" all'uso di
geodati che dovrebbero essere pubblicamente disponibili.

Saluti,


--
Christian Pellegrin, see http://www.evolware.org/chri/
"Real Programmers don't play tennis, or any other sport which requires
you to change clothes. Mountain climbing is OK, and Real Programmers
wear their climbing boots to work in case a mountain should suddenly
spring up in the middle of the computer room."
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.

[Cristoforo Abbattista]

Cari tutti,

essendo parte in causa dell'eMail pubblicata dallo staff del Ministero dell'Ambiente non posso non intervenire.

Intervengo da tecnico di Planetek Italia, ma se pensate che voglia solo fare pubblicità basta cestinare ora l'eMail.

Sulla SICUREZZA:
E' chiaro che la mia è una posizione di parte, ma posso affermare tranquillamente che ECW ed ECWP, sono sicuramente non liberi, ma altrettanto sicuramente non sono sinonimo di insicurezza del dato detenuto.
 
Questo perchè la sicurezza non è implicita nei sistemi. La sicurezza va implementata.

Riporto di seguito dei link verso un sistema di sicurezza per IWS ed ECWP sviluppato da Planetek.

In italiano http://www.planetek.it/prodotto.asp?id=90
In inglese http://www.planetek.it/eng/cmsarticoli.asp?id=44

Inoltre da pagina 114 del manuale di IWS ( http://www.earthetc.com/IWSDoc/ImageWebServer_UserGuide.pdf ) a pag. 142 si parla poi di altri modi orientati al business di implementare la sicurezza sul dato e sul servizio.

Il sistema attuale, non è poi più sicuro di quanto lo fosse con IWS; sia che il PCN fosse realmente basato su WMS (servito da MapServer) sia che il PCN fosse, com'è attualmente, basato su ArcIMS e ArcXML. Fare o trovare programmini che scarichino in locale il dato non è proprio complicato.

Sulle PERFORMANCE:
Di seguito dei link a documenti che analizzano la differenza di prestazioni quando in un sistema WebGIS viene usato o meno Image Web Server. Non voglio farvi notare quanto è forte IWS, ma voglio darvi un documento che indica una delle possibili strade da percorrere per analizzare le prestazioni di un sistema WebGIS, evitando colpi di PING.

http://www.planetek.it/cmsarticoli.asp?id=112
http://www.planetek.it/downloadfile.asp?id=44

Un esempio di un'applicazione WebGIS che serve cartografia raster con IWS (via WMS) è questo (e NON ha 100 mbps di banda):
http://cg.viaggiareinpuglia.it/portale/index.asp  (portale cartografico del turismo della Regione Puglia).

Scusate se ho rubato spazio e tempo alla lista, ma penso e spero che sia stato utile per tutti al di là del fatto che si parli di SW e protocolli non liberi.

Ciao a tutti.
    Cristoforo



-------- Messaggio Originale  --------
Oggetto: [Gfoss] presentazione e nota su una email ricevuta dal PCN
Da: chri chripell@...
A: gfoss@...
Data: giovedì 9 ottobre 2008 14.31.37

Buongiorno,

prima di tutto mi presento: sono uno sviluppatore prevalentemente di e
su software libero. Da un po' mi occupo di GIS soprattutto dal punto
di vista hobbystico (legato all'attività escursionistica ed
alpinistica) ma credo che il campo abbia delle importanti prospettive
da tutti i punti di vista. Spero di poter imparare grazie alla
comunità GFOSS e magari di poter contribuire (come ogni buon cittadino
del mondo del software libero).

La ragione per la quale ho fatto una ricerca su chi si occupa di
problematiche riguardo alla libertà dei geodati è, ahimè, non proprio
bella. Volevo segnalarvi un'email che copio sotto che mi è arrivata
come utente del Portale Cartografico Nazionale. Francamente mi sono
sentito preso in giro quando mi è stato dato (genericamente come
cittadino) del ladro o quantomeno del furbetto. Essendo il Ministero
dell'Ambiente e l'IGM enti pubblici pagati dalle tasse (Grillo direbbe
persino che si tratta di nostri dipendenti) non vedo perché i dati non
dovrebbero essere di tutti noi. Cosa normale in altri paesi come gli
Stati Uniti. Credo che questo aspetto sia ancora più importante oggi,
all'alba dell'introduzione di tutta una serie di servizi "location
based" che sicuramente andranno ad influire sulla nostra vita
quotidiana e per questo potranno aumentare ma anche limitare la nostra
libertà di cittadini.

Saluti,

----8<-----------
Gentili utenti,

riteniamo opportuno l'invio di questa comunicazione perché riceviamo
da qualche tempo, attraverso la e-mail del Portale Cartografico,
diverse considerazioni su due temi in particolare, su cui vogliamo
illustrare le motivazioni che ci hanno portato alle scelte operate.



Il primo dei temi ricorrenti è quello che riguarda il vecchio portale,
che sembra essere stato molto gradito a molti utenti rispetto a quello
attuale.

La vecchia versione del portale si appoggiava sulla cartografia
pubblicata tramite il protocollo ECWP, che sicuramente consentiva una
maggiore fluidità nella navigazione, ma presentava un considerevole
problema di sicurezza dei dati.

L'impiego dei servizi ECWP ha consentito a  diversi soggetti utenti
del portale, per i loro fini utilitaristici, di "depredare" il
Ministero dell'Ambiente dei dati cartografici messi a disposizione,
costringendoci all'impiego di attività e risorse pubbliche per la loro
tracciatura e la conseguente messa in atto di contromisure come
l'inibizione del loro acceso a  questi dati.



A causa di questi inconvenienti, questa Amministrazione ha deciso di
non pubblicare ulteriormente cartografia in formato ECWP, ma di
utilizzare tecnologie meno vulnerabili, pur rendendoci conto che la
maggior  parte  degli utenti hanno sempre utilizzato il Portale
rimanendo all'interno delle regole di buona cittadinanza.

Attualmente le nostre  cartografie sono disponibili per la
consultazione tramite visualizzatore on line e mediante i servizi WMS,
nel rispetto degli standard internazionali. Si sta comunque lavorando
affinché la visualizzazione e interrogazione sia la stessa del vecchio
Portale.





Il secondo tema ricorrente nelle vostre e-mail riguarda la lentezza
riscontrata nella navigazione della cartografia, a volte confrontata
anche con le prestazioni  della precedente versione del Portale.



Attualmente abbiamo evidenze che ci permettono di considerare le
prestazioni del Portale più che accettabili, ma ci rendiamo conto che
su questo tema una maggior disponibilità di prestazioni viene
sicuramente gradita.

Possiamo assicurarvi che lo staff che gestisce il Portale è impiegato
quotidianamente per migliorare le applicazioni ed i sistemi
informatici per offrire un servizio continuamente in crescita dal
punto di vista prestazionale.



Dobbiamo però ricordarvi che in molti casi la causa della lentezza
operativa potrebbe non essere imputabile a noi.

Attualmente il Portale Cartografico Nazionale ha a disposizione una
banda di 100 Mb/sec per le connessioni internet e, dalle nostre
misure, la sua occupazione in condizioni di massimo carico non supera
mai il 30%  e questo ci fa pensare che i problemi di cui stiamo
parlando non siano dovuti al nostro sistema informatico.

I problemi di performance, quindi, potrebbero spesso esser dovuti alla
rete personale e/o aziendale di chi accede al Portale, alla presenza
su di essa di Proxy o Firewall che ne limitano il traffico o
semplicemente alle configurazioni scelte per gli apparati di rete
presenti.



Nell'ottica del miglioramento continuo del servizio offerto, riteniamo
comunque di intraprendere un percorso costruttivo con voi utenti,
volto a migliorare l'accesso efficiente di ciascuno al Portale.



Abbiamo pensato di sottoporre, a chi lamenta problemi di prestazioni,
una serie di misure elementari da eseguire sulla propria  workstation,
al fine di fornirci dei dati oggettivi su cui lavorare per eliminare
qualunque problema esistente.

Vi elenchiamo in  fondo a questa e-mail queste operazioni elementari,
pregandovi di inviarci il file che riassume i risultati ottenuti.



Siamo sicuri di aver sollecitato in voi la comprensione delle
motivazioni che ci spingono a gestire come facciamo il Portale
Cartografico Nazionale, assicurandovi da parte nostra un impegno
sempre in crescita per venire incontro alle esigenze di chi lo
utilizza.





----------



Passi da eseguire per effettuare un  test di connettività :

1. Apertura di un prompt dei comandi.

2. Esecuzione del comando: ping www.pcn.minambiente.it –t

3. Dopo 5 secondi schiacciare i tasti ctrl+C per interrompere
l'esecuzione del comando ping.

4. Salvataggio dei risultati con copia/incolla in un file di testo
oppure in una screenshot per l'invio al PCN.

5. Esecuzione del comando: tracert www.pcn.minambiente.it

6. Salvataggio con copia/incolla dei risultati in un file di testo
oppure in una screenshot per l'invio al PCN.

7. Invio, tramite mail, dei risultati al PCN.


Note:
Il comando ping invia una serie di pacchetti TCP verso un indirizzo di
rete ed aspetta una risposta misurando i tempi di trasmissione; questo
test è indicativo della velocità della connessione nei nostri
confronti.
Il comando tracert traccia il percorso che ogni pacchetto compie per
raggiungere i nostri server, evidenziando ogni passaggio nella rete;
questo test evidenzia i passaggi attraverso Firewall o altri apparati
di rete che potrebbero essere responsabili del rallentamento della
comunicazione.

Distinti saluti

Lo staff

Portale Cartografico Nazionale

Direzione Generale per la Difesa del Suolo

Ministero dell'Ambiente della Tutela del Territorio e del Mare

ROMA
----8<-----------


  

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.

[Andrea Peri]

Effettivamente e' [OT], ma non troppo.

Comunque ritengo utile dare un contributo tecnico per uscire dal
discorso altrimenti troppo propagandistico.

Innanzi tutto :

>Un esempio di un'applicazione WebGIS che serve cartografia raster con
>IWS (via WMS) è questo (e NON ha 100 mbps di banda):

Ritengo utile fornire una considerazione di tipo tecnico al fine di
arricchire di contenuti la discussione.

Nessuno vieta che non si possa inviare una mappa via WMS anche in un
sistema con dati raster contenuti in formati ecw.
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.

ovviamente questo funzionerebbe con qualunque sistema di generazione
mappe che supporti tale formato (MapServer, ArcIMS o quant'altro).

Pero' la mappa arrivera' al browser sul client nei formati canonici
previsti (jpeg, gif,png)

Quando si parla invece di dato veicolato via Internet con il
protocollo ECWP si intende, invece, che il dato viene
veicolato con un protocollo proprietario e quindi occorre disporre di
un plugin specifico per poterlo comprendere altrimenti sarebbero
intesi sul client come un insieme di byte indistinguibili.

Il protocollo ECWP e' senz'altro piu' efficiente del protocollo HTTP
con cui vengono veicolate le mappe di tipo JPEG via WMS.
Non fosse altro che per il fatto che trattandosi di un formato
piramidale (l'ecw), a ogni aumento di dettaglio viene richiesto solo
l'informazione raster mancante rispetto alla precedente ricezione.

Cosa che invece non avviene per le mappe WMS che sono sempre
richiamate per intero.

Quindi in questo senso il ricorso al protocollo WMS anziche' al
protocollo ECWP comporta globalmente una perdita di performance.

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.

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

Ciao,


--
~~~~~~~~~~~~~~~~~
§       Andrea              §
§         Peri                 §
~~~~~~~~~~~~~~~~~
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.

[Cristoforo Abbattista]

-------- Messaggio Originale  --------
Oggetto: Re:[Gfoss] presentazione e nota su una email ricevuta dal PCN
Da: Andrea Peri peri.rtoscana@...
A: gfoss@...
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,


  

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.

[Andrea Peri]

>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                 §
~~~~~~~~~~~~~~~~~
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.

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


  

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.

[Andrea Peri]

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

Il teorema di shannon ??
Intendi la conversione da analogico a digitale ?

E' la base per tutti i discorsi.

ma in questo caso non centra niente.
perche' qui non si parla di conversione da imagine analogica a digitale.
Qui siamo gia' nel mondo digitale a priori.

E non ci poniamo i problemi di una corretta conversione da analogico a digitale.

Qui il problema e' come trasmettere una immagine digitale su un canale
digitale e riottenerla sempre digitale.

Non si passa mai da digitale ad analogico e viceversa, quindi Shannon
resta tranquillo.

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

Mi interesserebbe sapere come hai fatto a stabilire che l'immagine
viene prodotta in 10 secondi, visto che
l'unica misurazione di cui puoi disporre e' il tempo con cui ti arriva a casa.

Sei forse partito dal presupposto che a te arriva a casa senz'altro in
1 secondo ?

E quindi il ritardo e' imputabile per forza ai servers ?

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

Il paragone non regge.

Per la televisione serviva un apparato trasmittente abbastanza potente
e capace per la trasmissione bianco/nero o a colori che sia.
La Televisione inviava e chiunque fosse con la televisione accesa vedeva.
Per la lettura di pagine via web, il paradigma si basa non sull'invio
, ma sulla richiesta.
Ovvero e' l'utente da casa che invia una request e scarica la mappa.

Per la televisione la banda e' uguale per tutti gli utenti. Puo'
cambiare la sensibilita' la le immagini si muovono sempre alla solita
velocita' per tutti, se gli impianti di ricezione sono migliori le
immagini sono piu' nitide, ma la velocita' di movimento delle immagini
e' la stessa per tutti.

Nel caso della ricezione via web.
La nitidezza (intesa come qualita' del dato) e' un parametro che e'
uguale per tutti.
Quello che cambia e' la velocita con cui le scarichi e quindi in
definitiva il movimento (inteso come numero di immagini scaricabili al
secondo).

Quindi e' proprio l'opposto della televisione.

Ciao,

--
~~~~~~~~~~~~~~~~~
§       Andrea              §
§         Peri                 §
~~~~~~~~~~~~~~~~~
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.

[Cristoforo Abbattista]

Non si passa mai da digitale ad analogico e viceversa, quindi Shannon
resta tranquillo.
  

Non era chiaro dal discorso dei dpi e infatti ho ipotizzato ti riferissi all'analogico. La questione quindi mi resta oscura. Per me i pixel e la risoluzione relativa sono le informazioni necessarie.

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.
    

Mi interesserebbe sapere come hai fatto a stabilire che l'immagine
viene prodotta in 10 secondi, visto che
l'unica misurazione di cui puoi disporre e' il tempo con cui ti arriva a casa.

Sei forse partito dal presupposto che a te arriva a casa senz'altro in
1 secondo ?

E quindi il ritardo e' imputabile per forza ai servers ?
  

Conosco i miei polli, e in questo caso il pollo è ArcIMS. Nessuna ipotesi quindi. L'interazione con ArcIMS si basa sull'utilizzo di ArcXML che funziona così:

<client>Caro Server di mappe mi fai la mappa così?</client>
    x secondi dopo, utilizzati per produrre la mappa, il server risponde
<server di mappa>la puoi trovare a questo indirzzo http</server di mappa>

<client>caro server web mi dai questo file?</client>
<server web>tieni</server web>
    y secondi dopo la vedo sullo schermo

mediamente x=10 e y=1 (e suppongo pure con pochissimi utenti connessi; forse solo io)

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.
    

Il paragone non regge.
  

Per la televisione serviva un apparato trasmittente abbastanza potente
e capace per la trasmissione bianco/nero o a colori che sia.
La Televisione inviava e chiunque fosse con la televisione accesa vedeva.
Per la lettura di pagine via web, il paradigma si basa non sull'invio
, ma sulla richiesta.
Ovvero e' l'utente da casa che invia una request e scarica la mappa.

Per la televisione la banda e' uguale per tutti gli utenti. Puo'
cambiare la sensibilita' la le immagini si muovono sempre alla solita
velocita' per tutti, se gli impianti di ricezione sono migliori le
immagini sono piu' nitide, ma la velocita' di movimento delle immagini
e' la stessa per tutti.

Nel caso della ricezione via web.
La nitidezza (intesa come qualita' del dato) e' un parametro che e'
uguale per tutti.
Quello che cambia e' la velocita con cui le scarichi e quindi in
definitiva il movimento (inteso come numero di immagini scaricabili al
secondo).

Quindi e' proprio l'opposto della televisione.
  

In realtà il paragone non doveva essere preso alla lettera, volevo solo porre l'attenzione sul fatto che l'ingegnere fa quel che po', ipotizzando al meglio le situazioni che non può governare. Nel 19xx hanno preso il rischio, e accettato il costo, di inviare un po' di energia anche sul pezzo di banda destinato al colore, anche quando di TV a colori ce ne erano ben poche in giro. Un po' come il ministero che vuole fare un server potentissimo che fa delle amppone anche se non tutti ne godranno appieno.
Non puoi affermare quindi che è inutle fare server prestanti perchè tanto io vado a 56 kbps. Che poi non è nemmeno vero a prescindere.
Se hai 56 kbps o ti accontenti di meno informazione (TV in BN e piccole mappe in poco tempo) o di aspettare più tempo (TV a colori e grandi mappe in molto tempo)

ciao
    Cristoforo

Ciao,

  

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.

[Paolo Cavallini]

> Effettivamente e' [OT], ma non troppo.

Per cortesia, mantenete le conversazioni OT piu' compatte e brevi
possibili: abbiamo >340 iscritti, probabilmente alcuni di loro potrebbero
essere infastiditi da un eccessivo peso degli OT.
Scusatemi per il mio ruolo di cerbero, e grazie.
pc
--
Paolo Cavallini
http://faunalia.it/pc


_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.

[Andrea Peri]

>Per cortesia, mantenete le conversazioni OT piu' compatte e brevi
>possibili: abbiamo >340 iscritti, probabilmente alcuni di loro potrebbero
>essere infastiditi da un eccessivo peso degli OT.
>Scusatemi per il mio ruolo di cerbero, e grazie.
>pc

Direi che abbiamo concluso il brain-storming [OT] ....

Solo una domanda per Cristoforo:

Quando citi che un server su cui provi impiega 11 secondi a mandarti
la mappa a quale server ti riferisci ?

10 secondi per la produzione di una mappa mi pare un tempo elevatissimo .

E quindi vorrei fare qualche prova anche io, per curiosita'.

Ciao,

--
~~~~~~~~~~~~~~~~~
§       Andrea              §
§         Peri                 §
~~~~~~~~~~~~~~~~~
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.