Dopo uno scambio di mail con il comitato web del Software Freedom
Day siamo riusciti a far mettere la mappa di OpenStreetMap con
OpenLayers, piuttosto che la GoogleMap.
http://softwarefreedomday.org/
http://cgi.softwarefreedomday.org/2010/map.shtml
P.S. Questa volta mi ero preso dello "zelota" invece che del
"telebano", ma ne è valsa la pena comunque 
--
Niccolo Rigacci
Firenze - Italy
On Fri, 23 Jul 2010 18:25:31 +0200, Niccolo Rigacci wrote
Dopo uno scambio di mail con il comitato web del Software Freedom
Day siamo riusciti a far mettere la mappa di OpenStreetMap con
OpenLayers, piuttosto che la GoogleMap.http://softwarefreedomday.org/
http://cgi.softwarefreedomday.org/2010/map.shtmlP.S. Questa volta mi ero preso dello "zelota" invece che del
"telebano", ma ne è valsa la pena comunque
obbravo, bella boccia
ciao Sandro
p.s.: ma si può pretendere di essere un'associazione
seria avendo un presidente "talebano attivista" ed un
vicepresidente "zelota" ???
cercasi urgentemente un "negro ebreo comunista e frocio"
per opportuno passaggio di consegne.
Il 23 luglio 2010 18.25, Niccolo Rigacci <niccolo@rigacci.org> ha scritto:
Dopo uno scambio di mail con il comitato web del Software Freedom
Day siamo riusciti a far mettere la mappa di OpenStreetMap con
OpenLayers, piuttosto che la GoogleMap.
Grande!!!
Complimenti.
luca
--
Sabato 23 ottobre 2010
Nella tua città! http://www.linuxday.it
Il 23/07/2010 22:04, luca menini ha scritto:
Il 23 luglio 2010 18.25, Niccolo Rigacci<niccolo@rigacci.org> ha scritto:
Dopo uno scambio di mail con il comitato web del Software Freedom
Day siamo riusciti a far mettere la mappa di OpenStreetMap con
OpenLayers, piuttosto che la GoogleMap.Grande!!!
Complimenti.luca
Mi unisco ai complimenti!
Marica
Grande Niccolò,
sei riuscito addirittura a battere un colosso come Google 
2010/7/23 Marica Landini <bulma@ferrara.linux.it>
Il 23/07/2010 22:04, luca menini ha scritto:
Il 23 luglio 2010 18.25, Niccolo Rigacci<niccolo@rigacci.org> ha scritto:
Dopo uno scambio di mail con il comitato web del Software Freedom
Day siamo riusciti a far mettere la mappa di OpenStreetMap con
OpenLayers, piuttosto che la GoogleMap.Grande!!!
Complimenti.luca
Mi unisco ai complimenti!
Marica
–
Giuseppe Sucameli
Il 23 luglio 2010 18.25, Niccolo Rigacci <niccolo@rigacci.org> ha scritto:
Dopo uno scambio di mail con il comitato web del Software Freedom
Day siamo riusciti a far mettere la mappa di OpenStreetMap con
OpenLayers, piuttosto che la GoogleMap.http://softwarefreedomday.org/
http://cgi.softwarefreedomday.org/2010/map.shtml
grande rigacci
P.S. Questa volta mi ero preso dello "zelota" invece che del
"telebano", ma ne è valsa la pena comunque
beh mi sembra meglio zelota che talebano
--
Niccolo Rigacci
Firenze - Italy
ciao
Luca
oggi tocca abbassare la cresta (e chiedere umilmente scusa):
anche nel mondo FLOSS ogni tanto si scopre qualche "cappella"
ho appena scoperto che libjpeg [la libreria open source
che gestisce *tutte* le immagini JPEG] è lenta da morire.
Ancor peggio: libjpeg quasi sicuramente è il codec JPEG
più inefficiente e lento oggi disponibile sul mercato:
qualsiasi equivalente proprietario gli bagna il naso,
quanto meno su piattaforme x86 / amd64
fin dal tempo dei primi Pentium Intel ha introdotto in
hardware il set di istruzioni MMX/SSE con lo scopo di
supportare i codecs multimediali.
Con i Core 2, i7, i5 etc è stato introdotto SSE2 che
è ancora più potente.
Ma libjpeg ignora del tutto queste istruzioni, mentre
invece i codes proprietari le sfruttano al meglio.
fortunatamente esiste il progetto libjpeg-turbo.
in pratica è un clone esattamanente identico a libjpeg (stesse
identiche API/ABI), che però gestisce (da assembler) le estensioni
MMX/SSE2 - in questo modo praticamente di dimezzano i tempi di coding
e decoding. risultati misurati personalmente sul campo (su i5):
coding: 2.5secs -> 1.1secs
decoding: 1.7secs -> 0.9secs
licenza: wxWidgets [LGPL, ma consente static linkage]
http://libjpeg-turbo.virtualgl.org/
http://sourceforge.net/projects/libjpeg-turbo/
probabilmente una "sega mentale" per qualsiasi uso ordinario.
ma in alcuni ambiti applicativi (penso in particolare ai
server WMS) potrebbe anche segnare una differenza significativa.
ovviamente il beneficio si estende anche ai Tiff/Jpeg
ad ogni modo libjpeg-turbo mi pare assolutamente stabile
ed affidabile.
- fare la build è un piacere (anche su WinOZ MSYS+MinGW)
- occorre preinstallare l'assembler NASM
- dopo di che basta copiare la "nuova" libjpeg al posto
di quella "di sistema" ... voila, il gioco è fatto
ciao Sandro
P.S. (per Frankie)
fare un pensierino per debianizzare libjpeg-turbo: perchè no ???
Saluti a tutta la lista.
Se ben vi ricordate qualche giorno fa si era svolta
in lista una discussione stimolante (ed abbastanza
partecipata) a proposito delle tecnologie per le immagini
raster. Il pretesto iniziale era nato dal fatto che non è
più disponibile il supporto "free as in free beer" per gli ECW.
In quella sede avevo avanzato il suggerimento di fare un
bel benchmark comparativo, quanto meno per avere un minimo
di solida oggettività .
Ok, il benchmark ora è disponibile, e lo trovate qua:
http://www.gaia-gis.it/raster_benchmark
---------
vi faccio direttamente il riassunto di quello che risulta
dal benchmark (a beneficio dei più pigri):
a) JPEG è "infinitamente" più veloce di JPEG2000
b) anche il meno noto JPEG-LS è molto più veloce di JPEG2000
c) per farla breve, JPEG2000 si piazza sicuramente all'ultimo
posto in classifica in qualsiasi contesto, e con distacco
veramente abissale.
le compressioni basate su WAVELET paiono essere decisamente
un'idea poco felice: questo algoritmo sofisticato e complesso
(forse, troppo sofisticato e complesso) rimane decisamente
"un'osso duro" anche per l'HW più recente e pimpante.
tuttavia emerge anche come JPEG2000 / WAVELET recuperi poi
alla grande in quanto offre una buona capacità multi-risoluzione,
e quindi può fare tranquillamente a meno delle "piramidi".
conclusione: il segreto sta tutto nell'implementare le
piramidi in modo semplice ed efficiente.
ma questo possiamo tranquillamente ottenerlo anche senza
ricorrere alla complessità delle wavelet: basta ed avanza
il buon vecchio JPEG, se saggiamente utilizzato in tutte
le sue capacità , assai spesso sotto-utilizzate.
Vedi p.es. TIFF/JPEG che ignora del tutto la possibilità di
supportare "a costo zero" i livelli piramidali 1:2, 1:4 ed 1:8
Purtroppo ad oggi nessuna implementazione open source offre
tutto questo: se non RasterLite, ed anche RasterLite solo
in parte.
Quindi: tenetevi pronti per RasterLite v.2.0
ciao, Sandro
Ciao Sandro,
ti ringrazio tantissimo per il confronto fatto
ho trovato le informazioni da te descritte di effettiva utilità.
Trovo inoltre molto piacevole il "tono" che usi nello spiegare qualsiasi cosa.
Grazie!
Massimo.
Il giorno 27/lug/2010, alle ore 19.18, a.furieri@lqt.it ha scritto:
Saluti a tutta la lista.
Se ben vi ricordate qualche giorno fa si era svolta
in lista una discussione stimolante (ed abbastanza
partecipata) a proposito delle tecnologie per le immagini
raster. Il pretesto iniziale era nato dal fatto che non è
più disponibile il supporto "free as in free beer" per gli ECW.In quella sede avevo avanzato il suggerimento di fare un
bel benchmark comparativo, quanto meno per avere un minimo
di solida oggettività.Ok, il benchmark ora è disponibile, e lo trovate qua:
http://www.gaia-gis.it/raster_benchmark---------
vi faccio direttamente il riassunto di quello che risulta
dal benchmark (a beneficio dei più pigri):a) JPEG è "infinitamente" più veloce di JPEG2000
b) anche il meno noto JPEG-LS è molto più veloce di JPEG2000
c) per farla breve, JPEG2000 si piazza sicuramente all'ultimo
posto in classifica in qualsiasi contesto, e con distacco
veramente abissale.le compressioni basate su WAVELET paiono essere decisamente
un'idea poco felice: questo algoritmo sofisticato e complesso
(forse, troppo sofisticato e complesso) rimane decisamente
"un'osso duro" anche per l'HW più recente e pimpante.tuttavia emerge anche come JPEG2000 / WAVELET recuperi poi
alla grande in quanto offre una buona capacità multi-risoluzione,
e quindi può fare tranquillamente a meno delle "piramidi".conclusione: il segreto sta tutto nell'implementare le
piramidi in modo semplice ed efficiente.
ma questo possiamo tranquillamente ottenerlo anche senza
ricorrere alla complessità delle wavelet: basta ed avanza
il buon vecchio JPEG, se saggiamente utilizzato in tutte
le sue capacità, assai spesso sotto-utilizzate.
Vedi p.es. TIFF/JPEG che ignora del tutto la possibilità di
supportare "a costo zero" i livelli piramidali 1:2, 1:4 ed 1:8Purtroppo ad oggi nessuna implementazione open source offre
tutto questo: se non RasterLite, ed anche RasterLite solo
in parte.Quindi: tenetevi pronti per RasterLite v.2.0
ciao, Sandro
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@faunalia.it
http://lists.faunalia.it/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.
460 iscritti al 15.7.2010
ti ringrazio tantissimo per il confronto fatto
ho trovato le informazioni da te descritte di effettiva utilità.
Trovo inoltre molto piacevole il "tono" che usi nello spiegare qualsiasi cosa.
quoto tutto, grande Sandro!
P
--
Paolo Corti
GIS Architect and Developer
web: http://www.paolocorti.net
twitter: @paolo_corti
Ciao Sandro,
comparativa molto interessante anche se un po biased imho
- Quando parli di performance sarebbe interessante sapere se/come hai
misurato i tempi e che librerie/sdk hai usato.
- Quando parli di jpeg2000, bisogna tenere conto del fatto che _ogni_
libreria open conosciuta fa veramente pena, mentre se usi kakadu o ecw
sdk le performance possono essere diventare interessanti.
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo
-------------------------------------------------------
2010/7/27 <a.furieri@lqt.it>:
Saluti a tutta la lista.
Se ben vi ricordate qualche giorno fa si era svolta
in lista una discussione stimolante (ed abbastanza
partecipata) a proposito delle tecnologie per le immagini
raster. Il pretesto iniziale era nato dal fatto che non è
più disponibile il supporto "free as in free beer" per gli ECW.In quella sede avevo avanzato il suggerimento di fare un
bel benchmark comparativo, quanto meno per avere un minimo
di solida oggettività.Ok, il benchmark ora è disponibile, e lo trovate qua:
http://www.gaia-gis.it/raster_benchmark---------
vi faccio direttamente il riassunto di quello che risulta
dal benchmark (a beneficio dei più pigri):a) JPEG è "infinitamente" più veloce di JPEG2000
b) anche il meno noto JPEG-LS è molto più veloce di JPEG2000
c) per farla breve, JPEG2000 si piazza sicuramente all'ultimo
posto in classifica in qualsiasi contesto, e con distacco
veramente abissale.le compressioni basate su WAVELET paiono essere decisamente
un'idea poco felice: questo algoritmo sofisticato e complesso
(forse, troppo sofisticato e complesso) rimane decisamente
"un'osso duro" anche per l'HW più recente e pimpante.tuttavia emerge anche come JPEG2000 / WAVELET recuperi poi
alla grande in quanto offre una buona capacità multi-risoluzione,
e quindi può fare tranquillamente a meno delle "piramidi".conclusione: il segreto sta tutto nell'implementare le
piramidi in modo semplice ed efficiente.
ma questo possiamo tranquillamente ottenerlo anche senza
ricorrere alla complessità delle wavelet: basta ed avanza
il buon vecchio JPEG, se saggiamente utilizzato in tutte
le sue capacità, assai spesso sotto-utilizzate.
Vedi p.es. TIFF/JPEG che ignora del tutto la possibilità di
supportare "a costo zero" i livelli piramidali 1:2, 1:4 ed 1:8Purtroppo ad oggi nessuna implementazione open source offre
tutto questo: se non RasterLite, ed anche RasterLite solo
in parte.Quindi: tenetevi pronti per RasterLite v.2.0
ciao, Sandro
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@faunalia.it
http://lists.faunalia.it/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.
460 iscritti al 15.7.2010
Mi sono accorto (in modo del tutto casuale) di
una cosa abbastanza strana:
- su http://trac.osgeo.org/proj/
la versione corrente è la 4.7.0
- la tar ha il suffisso 4.7.0, così come la
dir che viene estratta
- l'header-file proj_api.h riporta:
#define PJ_VERSION 470
quindi sembrerebbe decisamente che si tratti
della v.4.7.0
tuttavia chiamando la funzione pj_get_release()
appare il messaggio: "Rel. 4.7.1, 23 September 2009"
immagino che si tratti semplicemente di una svista
innocua: mica per caso a qualcuno di voi risulta
qualcosa di più preciso che invece a me sfugge ?
ciao Sandro
On Tue, 27 Jul 2010 23:30:46 +0200, Simone Giannecchini wrote
Ciao Sandro,
comparativa molto interessante anche se un po biased imho
ma noi siamo biased per natura, vocazione e missione:
mica siamo l'ONU, che sta neutralmente nel mezzo.
direi che noi siamo dichiaratamente schierati, e dovrebbe
anche essere abbastanza chiaro da quale parte stiamo
- Quando parli di performance sarebbe interessante sapere se/come hai
misurato i tempi e che librerie/sdk hai usato.
è tutto pubblicato sul sito:
http://www.gaia-gis.it/raster_benchmark/test_jpeg8a.html
giusto in pillole:
libjpeg, libpng, libtiff, gcc
per Jpeg2000: OpenJPEG
insomma, solo ed esclusivamente roba o.s. 100% DOC
ho accuratamente intercettato i tempi (dal clock di
sistema) immediatamente prima che iniziasse la compressione
ed immediatamente appena la compressione terminava.
tutto memory-cached, i tempi di I/O etc etc sono
accuratamente esclusi.
insomma: ho misurato i tempi nudi e crudi imputabili
esclusivamente alla libreria che effettuava il coding/encoding.
- Quando parli di jpeg2000, bisogna tenere conto del fatto che _ogni_
libreria open conosciuta fa veramente pena, mentre se usi kakadu o
ecw sdk le performance possono essere diventare interessanti.
Non ne dubito affatto: mi fido ad occhi chiusi.
Rimangono però un paio di fatti *critici*:
a) sicuramente wavelet è un bel po' più pesante di jpeg:
per quante magie ed ottimizzazioni tu possa usare,
resta comunque "un bel pachiderma"
b) ho valutato ben 3 (*tre*) librerie o.s. che supportano
wavelet [a quanto mi risulta, non ne esistono altre].
tutte e tre mi danno più o meno (a spanne) gli stessi
tempi ... lenti, lentissimi.
c) giusto per pignoleria: in effetti ne ho usate due sole
(Epsilon ed OpenJpeg). La terza (JasPer) non l'ho neppure
provata: mi è bastato vedere qualche riferimento sul web:
sicuramente siamo sempre più o meno sugli stessi tempi.
Dato che si tratta di tre implementazioni assolutamente
autonome ed indipendenti (una è russa, una è canadese,
l'ultima è mezza belga e mezza perugina), non c'è nulla
che mi induca a ritenere che ci sia sotto qualche errore
sistematico (o qualche svarione di implementazione) che
possa falsare i risultati.
evidentemente, i tempi sono proprio quelli.
a meno che ... i prodotti proprietari usino qualche
"diavoleria" non documentata in letteratura, possibilmente
coperta da segreto industriale e debitamante brevettata.
Possibilissimo: vedo che attorno al Jpeg2000 c'è una
vera e propria "fioritura" di brevetti.
Ma questo taglia decisamente la testa al toro, no ?
Se le cose stanno proprio così, allora a maggior
ragione è saggio evitare di sprecare tempo e risorse
dietro ad una tecnologia (Jpeg2000) che resterà sempre
e comunque chiusa e proprietaria, almeno per i
prossimi decenni.
Tanto più se gli stessi esatti risulati (e forse anche
migliori) li possiamo ottenere comunque utilizzando
tecnologie libere e non brevettate.
almeno, a me pare così.
ciao Sandro
Ciao a tutti,
riesumo questa vecchia discussione (che lascio per intero qua sotto
per riferimento) perché mi è capitato di dare un'occhiata al nuovo
formato proposto da Google : WEBP [1] ed ero curioso di sapere se può
essere preso in considerazione come candidato per la cartografia
raster e se qualcuno ha già fatto qualche esperimento a riguardo.
Ciao,
Stefano
[1] http://code.google.com/speed/webp/
Il 27 luglio 2010 19:18, <a.furieri@lqt.it> ha scritto:
Saluti a tutta la lista.
Se ben vi ricordate qualche giorno fa si era svolta
in lista una discussione stimolante (ed abbastanza
partecipata) a proposito delle tecnologie per le immagini
raster. Il pretesto iniziale era nato dal fatto che non è
più disponibile il supporto "free as in free beer" per gli ECW.In quella sede avevo avanzato il suggerimento di fare un
bel benchmark comparativo, quanto meno per avere un minimo
di solida oggettività.Ok, il benchmark ora è disponibile, e lo trovate qua:
http://www.gaia-gis.it/raster_benchmark---------
vi faccio direttamente il riassunto di quello che risulta
dal benchmark (a beneficio dei più pigri):a) JPEG è "infinitamente" più veloce di JPEG2000
b) anche il meno noto JPEG-LS è molto più veloce di JPEG2000
c) per farla breve, JPEG2000 si piazza sicuramente all'ultimo
posto in classifica in qualsiasi contesto, e con distacco
veramente abissale.le compressioni basate su WAVELET paiono essere decisamente
un'idea poco felice: questo algoritmo sofisticato e complesso
(forse, troppo sofisticato e complesso) rimane decisamente
"un'osso duro" anche per l'HW più recente e pimpante.tuttavia emerge anche come JPEG2000 / WAVELET recuperi poi
alla grande in quanto offre una buona capacità multi-risoluzione,
e quindi può fare tranquillamente a meno delle "piramidi".conclusione: il segreto sta tutto nell'implementare le
piramidi in modo semplice ed efficiente.
ma questo possiamo tranquillamente ottenerlo anche senza
ricorrere alla complessità delle wavelet: basta ed avanza
il buon vecchio JPEG, se saggiamente utilizzato in tutte
le sue capacità, assai spesso sotto-utilizzate.
Vedi p.es. TIFF/JPEG che ignora del tutto la possibilità di
supportare "a costo zero" i livelli piramidali 1:2, 1:4 ed 1:8Purtroppo ad oggi nessuna implementazione open source offre
tutto questo: se non RasterLite, ed anche RasterLite solo
in parte.Quindi: tenetevi pronti per RasterLite v.2.0
ciao, Sandro
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@faunalia.it
http://lists.faunalia.it/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.
460 iscritti al 15.7.2010
On Mon, 28 Feb 2011 12:32:19 +0100, Stefano Salvador wrote
Ciao a tutti,
riesumo questa vecchia discussione (che lascio per intero qua sotto
per riferimento) perché mi è capitato di dare un'occhiata al nuovo
formato proposto da Google : WEBP [1] ed ero curioso di sapere se
può essere preso in considerazione come candidato per la
cartografia raster e se qualcuno ha già fatto qualche esperimento a
riguardo.
Stefano,
per me WEBP è una novità assoluta: da una prima
veloce lettura sembra decisamente *molto*
interessante.
in pratica, da quanto ho capito fino ad ora,
utilizza un algoritmo di compressione lossy
(reversibile, senza perdita) che dovrebbe
assicurare un risparmio di spazio di circa
il 40% rispetto ad un JPEG "alta qualità ".
Se è vero, è decisamente una bomba
Deriva direttamente da un codec video,
quindi immagino che sia anche molto veloce,
almeno in fase di estrazione.
Non mi è invece del tutto chiaro quale licenza
utilizzi: parrebbe una specie di BSD-like, ma
qua e la si accenna anche a brevetti Google.
insomma, forse questo aspetto è da verificare
più approfonditamente.
appena trovo il tempo sicuramente farò tutti
i test del caso: magari tra un po', perchè
ora sono preso dietro ad altre pippe
ciao Sandro
riesumo questa vecchia discussione (che lascio per intero qua sotto
per riferimento) perché mi è capitato di dare un'occhiata al nuovo
formato proposto da Google : WEBP [1] ed ero curioso di sapere se
può essere preso in considerazione come candidato per la
cartografia raster e se qualcuno ha già fatto qualche esperimento a
riguardo.Stefano,
per me WEBP è una novità assoluta: da una prima
veloce lettura sembra decisamente *molto*
interessante.in pratica, da quanto ho capito fino ad ora,
utilizza un algoritmo di compressione lossy
(reversibile, senza perdita)
correggo il tuo quick-lapsus: lossy == con perdita, irreversibile.
che dovrebbe
assicurare un risparmio di spazio di circa
il 40% rispetto ad un JPEG "alta qualità".
Se è vero, è decisamente una bombaDeriva direttamente da un codec video,
quindi immagino che sia anche molto veloce,
almeno in fase di estrazione.Non mi è invece del tutto chiaro quale licenza
utilizzi: parrebbe una specie di BSD-like, ma
qua e la si accenna anche a brevetti Google.
insomma, forse questo aspetto è da verificare
più approfonditamente.appena trovo il tempo sicuramente farò tutti
i test del caso: magari tra un po', perchè
ora sono preso dietro ad altre pippeciao Sandro
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@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.
502 iscritti all'11.2.2011
On Mon, 28 Feb 2011 13:03:50 +0100, andrea antonello wrote
> in pratica, da quanto ho capito fino ad ora,
> utilizza un algoritmo di compressione lossy
> (reversibile, senza perdita)correggo il tuo quick-lapsus: lossy == con perdita, irreversibile.
OOPS, sorry 
maledetta fretta: ok è effettivamente lossy;
quindi resta tutta da verificare la qualitÃ
reale rispetto al buon vecchio JPEG
Andrea, grazie per avere segnalato il mio
precedente "farfallone"
ciao
Sandro