Posso dire di essere un sostenitore dell’open source e senza dubbio preferisco avere a che fare con software, tecnologie e formati aperti. Al movimento del software libero sono molto legato, per alcuni versi ne faccio parte e, quando posso, cerco di dare i miei microscopici contributi qui e la.
Il mio mondo (digitale) ideale è un mondo in cui tutto il software è libero e, soprattutto, in cui le persone si scambiano dati e servizi in formati standard e liberi.
Il mondo reale, però, è fatto anche di altro e quando c’è da portare a casa la proverbiale pagnotta è bene tenerlo a mente. Inoltre penso che sia un preciso dovere, per un buon analista, essere sempre aggiornato sulle soluzioni esistenti indipendentemente dalla licenza che le accompagna.
In questo articolo racconterò quindi le impressioni che ho avuto durante le mie prime due settimane di lavoro con ArcGIS Server 9.3. Inizio subito col dire che partivo prevenuto nei confronti di questa piattaforma, date le allucinanti esperienze con ArcIMS, ma devo ammettere di essere rimasto piacevolmente sorpreso!
Che cos’è?
Bene, mi tocca entrare nel vivo e dare una definzione di massima che aiuti a capire meglio di cosa stiamo parlando.
Senza scendere troppo nel dettaglio tecnico, possiamo dire che ArcGIS Server è un ambiente che permette di pubblicare geowebservices sulla base dei quali si potranno poi sviluppare applicazioni di web-mapping.
Su questo fronte lo spettro di possibilità offerte da ArcGIS Server 9.3 agli sviluppatori GIS è davvero ampio. Si va dagli ADF (Advanced Development Framework) per gli ambienti .NET e Java, alle API Javascript, Flex e – di recente – Silverlight.
C’è anche un wizard che permette di pubblicare un’applicazione web senza grosse pretese di originalità e nel giro di qualche click, pur non avendo alcuna conoscenza di programmazione.
Come funziona?
Innanzitutto si deve installare!
Non ho avuto modo di provare l’installazione in ambiente GNU/Linux, ma in ambiente Windows la procedura non si discosta da quella classica che caratterizza la maggior parte dei programmi. Di certo avete presente il tipico: “Avanti → Avanti → Ok”…
Ultimata l’installazione vera e propria, vengono richieste delle informazioni utili alla configurazione dell’ambiente e, infine, si procede con l’autenticazione della licenza.
Al riavvio potremo finalmente effettuare il login in ArcGIS Server Manager, un applicativo di amministrazione da browser, oppure, se preferiamo, connetterci all’istanza di ArcGIS Server usando ArcCatalog.
A questo punto siamo pronti per tirarci su le maniche e creare servizi di vario tipo (mapservice, dataservice, gisservice, geoprocessing e geocoding service).
Consideriamo per esempio il mapservice, un tipo di servizio che serve ad esporre una mappa composta da uno o più layer, sui quali si possono eseguire delle operazioni (task) come find, query e identify.
Pubblicare un mapservice è decisamente semplice. Basta avere un progetto redatto in ArcMap (un normale file .mxd) ed effettuare delle semplici scelte per la configurazione del servizio.
Oltre al servizio proprietario ESRI, sono a disposizione vari standard: KML, WMS, WFS-T e WCS.
Sviluppo client con REST e Javascript
ArcGIS Server 9.3 offre, out-of-the box, la possibilità di esporre i servizi secondo il paradigma REST.
Questa, insieme alle API Javascript basate sull’ottimo toolkit open source Dojo, è probabilmente la novità di maggior rilievo di ArcGIS Server 9.3.
Imparare a sfruttare questi mezzi equivale ad aprirsi la possibilità di sviluppare delle applicazioni web 2.0 che, col solo codice lato-client, offrono la maggior parte delle caratteristiche che normalmente ci si aspetta di trovare in una applicazione di web-mapping.
Qui ci sono alcuni esempi che sicuramente vale la pena di esplorare per rendersi conto delle potenzialità delle API.
E’ interessante, inoltre, che l’ultima versione di OpenLayers, la 2.8, permetta di utilizzare anche i layer REST di ArcGIS Server 9.3.
Se volete saperne di più sull’argomento vi consiglio caldamente questo video!
Pro e contro
Siamo alla fine del post ed è ora di fare un bilancio.
Prima le cattive notizie: il supporto, non me ne vogliano in ESRI Italia, è assolutamente inadeguato!
Se si naviga tra EDN e Resource Gateway o si bazzica la comunità internazionale sul forum, in fin dei conti non è proprio malaccio (anzi, sul forum ci sono utenti molto preparati e dispobili grazie ai quali ho risolto alcuni piccoli intoppi).
Però chi ha acquistato un prodotto in Italia, pagandolo profumatamente, tollera con un po’ di mal di pancia che il supporto locale non sappia nemmeno dare un aiuto di tipo “getting started” se ci si vuole discostare dall’uso del wizard o dello sviluppo con l’ADF Java o .NET.
Personalmente, ho telefonato 3 volte al supporto ponendo delle domande tecniche precise e non ho mai ricevuto una risposta utile dall’interlocutore (quasi sempre: “apra un ticket”). Oggi, con poche settimane di esperienza di sviluppo con queste API alle spalle, mi rendo conto che le mie domande erano davvero molto semplici, il che mi porta a pensare che quello dello sviluppo con le API Javascript, in ESRI Italia, sia un tema molto trascurato.
Comunque devo essere onesto e dire che in altre occasioni ho trovato utilissimo (spesso risolutivo) il supporto di ESRI Italia. Questo mi fa ben sperare per il futuro nel caso in cui a Roma decidano di dedicare un po’ di attenzione anche quei balordi (come il sottoscritto) che si sono fissati col Javascript!
Passiamo ai pro che, invece, sono tanti:
- scalabilità dell’architettura
- semplicità nella configurazione e nello sviluppo degli applicativi
- versatilità delle API e possibilità di creare Mash-Up praticamente con tutto
- buon supporto agli standard del settore
Basta con le chiacchiere!
Cliccando qui, potete vedere un piccolo esempio live da me realizzato.
Divertitevi (si fa per dire…) a fare lo stesso… e condividete il risultato!
Tag: Dojo ESRI Javascript Web 2.0 webmapping
I contenuti potrebbero non essere più adeguati ai tempi!
By Andrea on ago 3, 2009
Ciao volevo fare un commento riguardo alle osservazioni sul supporto Esri Italia, se si fa una critica non se la può rimangiare due righe dopo!!
Ho avuto modo di lavorare con tecnologia Esri per anni e non ho mai avuto un contributo significativo per risolvere un qualsiasi problema dall’Help desk, mi sono sempre dovuto arrangiare sui forum Esri.com, che devo dire mi hanno sempre aiutato moltissimo.
Saluti
Andrea
By Pietro Blu Giandonato on ago 3, 2009
Grazie Alessio per le tue impressioni… TANTO è anche un luogo nel quale “recensire” prodotti e soluzioni, che siano OS o meno.
Per quanto riguarda l’help desk di ESRI Italia, anch’io in veste di utilizzatore di prodotti della famiglia ArcGIS mi sono sempre arrangiato molto egregiamente con il support di ESRI.com, una comunità nella quale il grosso dell’aiuto lo si ottiene (e lo si dà) proprio da (ad) altri utenti.
In questo (certo, solo in questo) si può dire che ESRI sia “OS”, il che dimostra che più di un help desk conta di gran lunga una knowledge base costruita sull’esperienza. Per chi mastica solo italiano, non resta che “aprire ticket”…
By Alessio on ago 3, 2009
Non è questione di “rimangiarsi” le critiche. Sulla mancanza di supporto per le API js e REST non ci piove.
Per altre questioni ho *davvero* trovato utili i suggerimenti di ESRI Italia (di Pavel in particolare), specialmente quando ho avuto a che fare con problemi apparentemente inspiegabili di autenticazioni delle licenze dai client al server o intoppi simili.
Volevo chiudere con una nota “di speranza”, augurandomi che mettano qualcuno a studiarsi ste benedette api.
Non ho peli sulla lingua, puoi starne certo, cerco solo di essere onesto fino in fondo. E buttare merda indistintamente non è una cosa che mi piace fare
Ciao
By GioBo on ago 8, 2009
Post molto interessante in blog TANTO interessante. Blog in cui la gente scrive di esperienze dirette su cose che lo interessano TANTO sono sempre più rari nell’attuale panorama di taglia e incolla che hanno l’unico scopo di racimolare pochi centesimi con AdSense.
Nonostante siano anni che lavoro con i prodotti GIS ed in particolare con i prodotti ESRI, ho trovato spunti interessanti – l’approccio REST con ArcGISServer – e questo non può che farmi TANTO piacere.
TANTI Saluti
By Alessio on ago 8, 2009
Grazie del tuo commento GioBo.
Apprezziamo TANTO quando i lettori lasciano un segno del proprio passaggio
Io credo che questa volta ESRI ci abbia visto giusto ed abbia iniziato a recuperare il gap rispetto alla concorrenza (OS in primis ovviamente) per quanto riguarda il web.
Come ho scritto nel post, speriamo solo che anche ESRI Italia capisca che questa modalità di sviluppo è da supportare.
Altrimenti, tanto per dirne una, se mi devo affidare alla “sola” comunità perché dovrei sborsare i soldi per un prodotto così costoso? UMN-Mapserver è altrettanto valido, come anche Geoserver…
By Andrea Borruso on ago 11, 2009
Ciao Ale,
volevo commentare “ufficialmente” da un po’. Finalmente trovo il tempo.
Complimenti per il post. E’ ben scritto e fa toccare con mano “cose” nuove.
Dovresti mettere in evidenza il lavoro che hai fatto nello sviluppo del tuo esempio, e la cura che hai messo nei commenti. Renderei più palese che è un tutorial e non soltanto una demo.
E’ un post che fa toccare con mano la “vecchiaia” di alcune applicazioni web attuali sviluppate in ambiente ESRI. Non amo i siti messi su “soltanto” con un wizard, ma hanno spesso alle spalle un sistema robusto; su questo un utente con una conoscenza di dominio media, può mettere in piedi grandi cose anche senza “aiuti”. Insomma mi aspetterei dei buoni siti di web-mapping per il futuro.
In ultimo, visto l’interesse suscitato, segnalo una presentazione ESRI che mette a confronto i servizi REST con quelli SOAP:
http://tr.im/wc47
Grazie,
a
By Alessio on ago 11, 2009
Hai ragione, i commenti sono “verbosi” abbastanza da rendere la demo un piccolo tutorial.
Probabilmente non ho pensato di esplicitarlo perché l’idea iniziale era quella di una semplice chiacchierata, basata sulla mia prima esperienza con questi nuovi “ArcCosi”…
Magari riprenderò il discorso in un nuovo post, strutturandolo dall’inizio come tutorial e scrivendo qualche parola in più su dojo e sui dijits.
ah… grazie del link
By Pipino on ott 18, 2009
Non sono d’accordo in generale sul supporto. Quando acquisti ESRI, acquisti un prodotto che ha dietro una comunità molto competente. Con una tecnologia così vasta non puoi pretendere di trovare una risposta immediata su qualsiasi cosa. Anche il più guru dei guru può non aver dovuto affrontare un problema. Anch’io che lavoro su tanti ambienti di sviluppo da tanti anni, alcune cose non le ho mai affrontate. Chiaro che poi nello specifico bisognerebbe vedere le domande che hai posto…
By Alessio on ott 18, 2009
Ciao Pipino e grazie del tuo commento.
Come sempre, fa piacere!
quella che ho raccontato nell’articolo riguardo ESRI Italia è solo la mia esperienza ed ovviamente non si tratta della verità vera.
Però, per quello che mi è stato dato di vedere nelle diverse occasioni di confronto con ESRI Italia, c’è ancora una scarsa attenzione verso questo specifico modo di utilizzare ArcGIS Server.
Ci si concentra sullo sviluppo .NET in maniera pressoché totale.
Indubbiamente, voluto o no, mi sembra un buco nel supporto che ESRI Italia è in grado di offrire ai propri clienti. Io che .NET non lo conosco e non ho intenzione di usarlo, ho pagato il prodotto quanto gli altri clienti e penso di meritare la stessa attenzione.
Mi rendo conto comunque che la maggior parte della clientela ora va in quella direzione e richiede quel tipo di assistenza. Nel mondo dei clienti ESRI italiani che sviluppano applicazioni di webmapping, si è ancora molto abituati a pensare alla “ArcIMS”. Non ce la mentalità di vedere un applicativo come un qualcosa di modulare, componibile, che può venire fuori dall’integrazione di diverse parti indipendenti tra loro o anche come l’integrazione di diverse tecnologie (come può essere per un approccio basato su UMN-Mapserver e OL).
In effetti all’inizio ho fatto fatica a far accettare ai miei clienti soluzioni diverse (basate appunto sulle api js) che vengono accettate di buon grado solo dopo aver preso visione delle demo. Parlare di geowebservices, REST, client e API manda ai matti la maggior parte degli interlocutori abituati a dare colpi di click su un wizard e poi a personalizzare qualche file. E’ per l’appunto, un approccio diverso e al momento ESRI Italia, non gli da supporto, visibilità e dignità in maniera adeguata (sempre secondo me… intesi).
By Pipino on ott 19, 2009
Tieni conto che gli ArcObjects (la libreria GIS più vasta che esista) è scritta in c++ ed è esposta in COM. In .NET poi viene usata l’interop per utilizzare gli AO mentre in java occorre usare un brigde. La documentazione (ma qui è quella americana) enfatizza molto di più lo sviluppo in .NET rispetto a quello java; anche se teoricamente, nonostante il bridge, le prestazioni sono pressochè identiche e comunque anche lo sviluppo in c++ è spinto molto su ambiente windows piuttosto che linux-solaris e questo si rispecchia sui threads aperti sui forums.
Per quel che riguarda js dipende molto da che applicazione devi sviluppare. Se l’applicazione è molto sbilanciata su lato server (esempio: versioning, archiving, editing avanzato, topology, stampe di alta qualità o comunque dove lo stato dell’applicazioni è ‘corposo’) l’uso di applicazioni js non è adatto. Inoltre occorre considerare che bisogna analizzare bene cosa inviare al client minimizzando il flusso di dati (ad esempio costruire un graphic con molti vertici) per evitare i limiti del browser (anche se per questo ci viene in aiuto la pagina proxy). Per quanto riguarda l’integrazione, farei comunque molta attenzione: seppur vero che i prodotti esri hanno un costo, se si valuta un progetto nel suo complesso, personalmente non ho quasi mai trovato una soluzione a minor costo (esempio: il cliente ha progetti in mxd e vuole pubblicarli così come sono; sfido chiunque a ricreali in qualche modo per ripubblicarli in altri ambienti in tempo nullo). Attenzione: non dico che questo sia giusto, ma come tecnico io analizzo la ‘soluzione’ nel suo complesso a costo minore. Se poi ci sono logiche ‘politiche’ io lascio perdere…
By Alessio on ott 19, 2009
Certamente si deve essere obiettivi e non fare i “fan” di questa o quell’altra soluzione. Ed hai pienamente ragione a dire che quando l’applicazione richiede molta elaborazione lato server javascript ha dei limiti.
Quello che però ho evidenziato nella mia critica ad ESRI Italia nella parte conclusiva del post, almeno credo, è il fatto di non essersi ancora attrezzati a supportare al meglio anche i clienti che scelgono le soluzioni basate sulle API js.
Poi se non è vero e sono stato sfortunato io (3 volte di fila) mi fa solo piacere, dico sul serio, senza alcuna ironia
By Alessandro on nov 11, 2009
Ciao ragazzi..
scusate se mi intrometto, ma volevo approfittare delle vostre competenze per chiedervi un aiuto.
Dove posso trovare informazioni e/o giudizi che mi permettano di confrontare (dal punto vista tecnico, economico, della facilità d’uso, delle caratteristiche, e così via) alcuni tra i più diffusi e “famosi” software GIS??
Sono un novizio in quseto campo e spero che troviate 2 minuti per rispondermi..
Grazie e ciao a tutti!!
Ale
By Alessio on nov 11, 2009
mmm… mi sa che non esiste un “dove” specifico, almeno finché la domanda è così generica…
Con software GIS “famosi” cosa intendi?
GIS Desktop? GIS Server? Librerie client? DBMS Spaziali?
Il post che hai commentato parla di ArcGIS Server e api js, quindi sarei portato a pensare che stiamo parlando di webmapping… altrimenti saremmo un po’ OT
By Alessandro on nov 11, 2009
forse dopo aver letto la parola ArcGis pensavo di aver troavto quello che cercavo, ma giustamente devo spigarmi meglio..
dunque.. faccio riferimento ai software prodotti da Esri, a GeoMedia (prodotto da Integraph), a MapPoint (di Microsoft), a MapInfo Professional (di MapInfo), e così via.
Spero di essere stato più preciso e, soprattutto, più o meno attinente agli argomenti del blog.. altrimenti me ne scuso..
ciao..
By Alessio on nov 11, 2009
Parliamo di GIS desktop quindi.
Pur essendo sicuramente un argomento di cui questo blog si occupa, non è ciò di cui parla il post che stiamo commentando
In ogni caso, tra i software da te citati io posso dire di conoscere a buon livello solo quello ESRI. Con MapInfo ho avuto a che fare sporadicamente e con gli altri mai.
Non so indicarti un “luogo” dove trovare un confronto tra questi prodotti ma google dovrebbe tornare utile (scusa la banalità di questa risposta).
Un ulteriore conglio che ti do è quello di considerare anche i GIS open source. Alcuni nomi: GRASS, QuantumGIS, gvSIG.
By Andrea Borruso on nov 11, 2009
Ciao Alessandro,
una bella comparazione tra GIS Desktop OpenSource la trovi qui:
http://www.spatialserver.net/osgis/
Non risponde per intero alla tua domanda, ma ti da una fotografia abbastanza nitida delle caratteristiche di base del software.
Cerca di partire dagli obiettivi, e non dal software. Se ci dai qualche dettaglio potremmo darti qualche suggerimento più preciso.
Aggiungo un confronto tra due software proprietari, che ti potrà tornare utile:
http://bit.ly/8hlMN
Buona lettura,
a
By Alessandro on nov 12, 2009
allora.. piano piano mi state indirizzando verso il centro della questione..
io sto preparando una tesi in cui tratto di sistemi informativi aziendali in generale, x poi passare ai GIS e al geomarketing… pensavo fosse interessante dedicare un paragrafo (meno teorico e più tecnico) a quelli che sono i software GIS più utilizzati in tale campo..
spero di essermi spiegato meglio..
By Pipino on nov 13, 2009
Vorrei aggiungere una nota. Si parla sempre di software gis comparando opensource e commerciale e via dicendo… ma molte volte ci si scorda che la componente principale quando si parla di sistemi gis sono le persone …
By Alessio on nov 13, 2009
Hai ragione, i software sono solo strumenti di lavoro, attrezzi.
Puoi conoscere un software a memoria ma non essere in grado di strutturare le informazioni che devi maneggiare, di progettare, ecc…
In questo caso il risultato sarà sempre e comunque scadente.
Come ha già detto Andrea, è bene partire dagli obiettivi e non dai software.
D’altro canto conoscere le soluzioni disponibili (os e proprietarie) ti permette di lo scegliere consapevolvente lo strumento più adatto una volta che la fase “carta, penna e cervello” è finita o a buon punto.
By Pietro Blu Giandonato on nov 13, 2009
Alessandro, se posso tentare di riassumere.
Come hanno già detto i miei stimati colleghi di blog, non esiste un software migliore di un altro, ma una loro applicazione più efficace di un’altra.
Se il tuo lavoro è incentrato sui SI aziendali, con un approfondimento sui SI geografici per il geomarketing, ti conviene parlare di casi di studio, piuttosto che di questo o quell’altro pacchetto GIS.
Tieni conto che le applicazioni di GM si basano sulle classiche funzionalità che qualunque GIS possiede, ovvero costruzione di mappe tematiche, topologic, network e proximity analysis, quindi tutto sommato una suite vale l’altra.
Il valore aggiunto di una buona applicazione GM si basa – come per tutte le applicazioni GIS – sulla costruzione di processi di analisi dei dati efficaci e funzionali agli obiettivi. Che devono essere quindi chiari e ben modellizzati.
A questo punto, se posso darti un consiglio, nella tua tesi puoi fare una breve descrizione generale di cosa è un GIS, tecnica quanto basta, non necessariamente parlando di specifiche suite, ma citando appunto le funzionalità tipiche dei GIS applicati al GM. E magari ci metti alcuni casi studio.
Dai un’occhiata a questi tizi, troverai appunto come hanno affrontato alcuni problemi tipici del geomarketing, tra l’altro molto interessanti. Potresti magari contattarli per chiedere loro qualche dettaglio tecnico in più su alcune applicazioni che hanno realizzato.
Ad un intraprendente laureando non si può negare una mano… eppoi chissà, magari troveranno che il tuo lavoro gli potrebbe pure interessare
In bocca al lupo, e torna qui quando vuoi.
By Alessandro on nov 16, 2009
Bene.. inizio ad orientarmi meglio..
non ho fatto fatica a trovare una parte più “teorica” sui software GIS utilizzati nelle analisi di Geomarketing e in quelle realizzate sui database aziendali.
Tuttavia, nella pratica, sono solo i c.d. “desktop GIS” che mi devono interessare (come detto sopra) oppure ci sono anche altre tipologie di GIS coerenti al mio lavoro??
ancora grazie..
By Pietro Blu Giandonato on nov 16, 2009
Le applicazioni GIS possono essere realizzate non solo mediante i client desktop (QGIS, ArcGIS, uDIG, GvSIG per intenderci), ma anche con soluzioni basate sul web, i cosiddetti “webgis” o meglio applicativi webmapping.
Ovviamente anche qui la scelta ricade sull’obiettivo che il professionista ha: i client desktop possiedono funzionalità più potenti e complesse, i webgis hanno come finalità essenzialmente quella di rendere facilmente disponibili e consultabili i dati geografici ad una vasta platea di persone, proprio mediante il web.
Spesso in progetti o lavori di una certa complessità, i GIS desktop e quelli web-based si devono necessariamente integrare.
Insomma, ancora un consiglio: nella tua tesi parla di entrambe le tecnologie.
By Alessio on nov 16, 2009
Pietro ha assolutamente ragione.
Considera entrambe le tecnologie perché spesso (se non sempre) sono strettamente connesse nel percorso che porta dal progetto alla sua realizzazione.
Una nota: man mano che le capacità dei webgis aumentano si tende sempre di più a fargli fare delle operazioni che fino a poco tempo fa erano esclusiva caratteristica dei gis desktop.
Si tende, in pratica, a centralizzare l’elaborazione delle informazioni su un server e utilizzare il browser come “thin client”.
Questo può essere un bene o un male, a seconda dei punti di vista e dei casi…
Un esempio è fornito dal “Vector editor”:
http://blog.spaziogis.it/2009/09/21/editing-vettoriale-con-openlayers/
qui la funzionalità portata dal desktop al web (pur con tutta una serie di differenze e limitazioni) è l’editing vettoriale.
Comunque, allo stato attuale, è difficile rinunciare ad uno strumento desktop se le operazioni da svolgere non sono banali.
By alberto on mag 4, 2010
Ciao,
sto iniziando ora con lo sviluppo su sistemi GIS (tendenzialmente applicazioni web che fruiscono di mappe etc) e ho scelto ESRI come piattaforma di riferimento perchè ho visto che supporta .NET, vorrei qualche dritta su come iniziare, comepre parare l’ambiente,
cosa installare e come reperire il software : va bene esri desktop o è necessario il server? si trovano in versioni gratuite tipo “evaluation”? dove reperisco dati e mappe?
Insomma qualsiasi informazione che m iindirizzi sulla giusta strada…
grazie
By Alessio on mag 4, 2010
Ciao Alberto,
la piattaforma .NET non la conosco, ma se hai letto l’articolo hai visto che si parla di sviluppo client con delle API javascript indipendenti dalla piattaforma.
In questo caso arcgis server viene usato per esporre dei webservice e credo che cambi poco tra l’ambiente Java e quello .NET da questo punto di vista. Le differenze vengono fuori quando si fa uso degli ADF.
Se vuoi lavorare con le tecnologie ESRI per il webmapping hai bisogno sia di ArcGIS Desktop (per l’authoring delle mappe) che di ArcGIS Server. In ogni caso, valuta bene le tue necessità… perché si tratta di software costosi. Ti consiglio anche di tenere in debita considerazione le soluzioni opensource.
Insomma qualsiasi informazione che m iindirizzi sulla giusta strada…
Nell’articolo ci sono dei link che dovrebbero aiutarti
By Andrea on mag 4, 2010
Esatto, se vuoi sviluppare in net puoi anche utilizzare MapGuide OS che ha un viewer con tutte le funzioni in sviluppate in .NET, mentre per la produzione delle mappe puoi usare Map Guide maestro free ed open.
Saluti
Andrea