Archivio per la categoria ‘Tutorial’
25 aprile, 2010
Tempo fa scrissi un articolo su ArcGIS Server 9.3 soffermandomi sui servizi REST e le API Javascript ed accennando al fatto che ESRI mette a disposizione delle estensioni per le API di Google Maps e per quelle di Bing Maps.
Ultimamente ho lavorato un po’ con le prime e ne ho avuto complessivamente una buona impressione. Tuttavia, durante lo sviluppo, ho riscontrato un problema nella misurazione delle distanze e delle aree che merita di essere messo in evidenza, soprattutto perché gli esempi della documentazione ESRI non lo fanno a dovere ed anzi, secondo me, risultano leggermente fuorvianti.
Terminata la premessa, prima di andare avanti con l’articolo, voglio ringraziare Domenico Ciavarella, che mi ha dato un supporto fondamentale per arrivare ad una soluzione che altrimenti starei ancora cercando.
La proiezione di Google Maps
Effetto di distorsione delle aree
Google Maps, Bing Maps ed altri provider (come OpenStreetMap, Yahoo e, di recente, la stessa ESRI) utilizzano una proiezione nota come Spherical Mercator, derivata dalla proiezione di Mercatore. Il codice EPSG ufficiale è 3785, anche se prima della sua definizione molti software hanno utilizzato l’ufficioso 900913. L’identificativo per i software ESRI, tra cui ovviamente ArcGIS Server, è invece 102113.
Questa proiezione considera la Terra come una sfera e consente di includerne completamente la superficie all’interno di un quadrato.
Quando però si rappresenta una superficie curva su di un piano, come un foglio di carta o il monitor di un computer, si introducono delle deformazioni. In questo caso, man mano che ci si allontana dall’equatore le aree cartografate subiscono un pesante stiramento sia in senso verticale che orizzontale e diventano, quindi, via via più esagerate verso i poli (la Groenlandia, per esempio, sembra più grande dell’Africa). Questa proiezione evidentemente non è fatta per minimizzare la deformazione delle aree (la proiezione di Mercatore è conforme infatti), ma risulta vantaggiosa per l’uso attraverso il web perché consente di applicare un modello efficiente di tassellamento e caching.
Il problema…
Ammettiamo di voler creare un’applicazione di webmapping con le sopracitate estensioni delle API Javascript di ArcGIS Server per Google Maps.
La prima cosa da fare è creare un mapservice in grado di esporre i nostri dati spaziali con la medesima proiezione delle basi cartografiche di Google. Come spiegato nel post dedicato ad ArcGIS Server (linkato all’inizio di questo articolo) un mapservice “aggancia” e pubblica un progetto redatto in ArcMap (il classico .mxd), quindi basta assegnare al dataframe del progetto il sistema di riferimento appropriato (che si trova nella lista dei sistemi proiettati, alla voce WGS 84 Web Mercator, con identificativo 102113), salvare il tutto e pubblicarlo con ArcGIS Server. Niente di difficile insomma.
Focalizziamoci ora sullo sviluppo del client: tra i tanti strumenti che oggi ci si aspetta di trovare in una applicazione WebGIS ci sono i “righelli” che consentono di disegnare spezzate e poligoni e di misurarne poi lunghezza ed area. ESRI lo sa, ed ha giustamente incluso un esempio per mostrare come creare questi tool nella documentazione delle sue API.
Abbiamo detto però che l’uso della proiezione Spherical Mercator provoca una deformazione crescente man mano che ci si spinge verso i poli e, tracciando una spezzata per misurare un oggetto al suolo di dimensioni note, come uno stadio di calcio, ci si accorge dell’inghippo: è più lungo di quanto dovrebbe essere (circa 146 metri invece di 105-110).
L’esempio fornito da ESRI non considera la deformazione e può indurre gli sviluppatori all’errore. E’ vero che una persona con le adeguate conoscenze di geomatica può arrivare ad intuire il rischio insito nell’uso della proiezione di Google, ma è anche vero che il webmapping è terra di confine tra “gissologi” e sviluppatori informatici “puri”, senza particolari cognizioni tipiche del mondo gis. Non è per nulla detto, quindi, che chi sviluppa abbia i mezzi per immaginare il problema prima di averci sbattuto il muso e personalmente credo che aver pubblicato un esempio del genere nella documentazione ufficiale, senza neanche accennare alla questione della deformazione, sia stata una leggerezza.
…e la soluzione
Non molto tempo fa sul blog di ArcGIS Server è comparso un interessante post che mette in evidenza il problema della misurazione delle distanze e spiega come comportarsi per risolverlo.
Il servizio che in ArcGIS Server è incaricato di calcolare lunghezze ed aree, il Geometry Service, è in grado di svolgere diverse altre operazioni, tra cui la proiezione al volo delle geometrie.
Il “trucco” consiste nel riproiettare la geometria tracciata dall’utente nel sistema di riferimento più adatto alla zona mappata prima di effettuarne la misurazione e stampare a schermo il risultato.
Purtroppo lo snippet di codice fornito da ESRI è pronto all’uso solo per le API Javascript, mentre per le estensioni di Google Maps bisogna fare da soli e il discorso è un po’ meno semplice.
Al posto di questa funzione:
var sr = new esri.SpatialReference({wkid:32610});
geometryService.project([graphic], sr, function(projectedGraphic) {
geometryService.areasAndLengths(projectedGraphic, function(result) {
var perimeter = result.lengths[0];
var area = result.areas[0];
});
});
abbiamo bisogno di questa:
var geometryService = new esri.arcgis.gmaps.Geometry("http://sampleserver1.arcgisonline.com/ArcGIS/rest/services/Geometry/GeometryServer");
function calculateLengths() {
//Parametri per la riproiezione
var params = new esri.arcgis.gmaps.ProjectParameters();
params.geometries = [polyline];
params.inSpatialReference = 4326;
params.outSpatialReference = 3004; //Gauss-Boaga fuso Est
//Riproiezione e funzione di callback
geometryService.project(params, getLengths);
}
function getLengths(projectResults){
var url = "http://sampleserver1.arcgisonline.com/ArcGIS/rest/services/Geometry/GeometryServer/lengths";
var parameters = {
polylines: projectResults.geometries,
sr: 3004
};
esri.arcgis.gmaps.JSONRequest(url, test, parameters);
}
function test(result) {
alert(result.lengths[0]+" m");
}
Ho realizzato un veloce esempio che mostra i risultati ottenuti dal codice proposto da ESRI nella propria documentazione a confronto con quelli ottenuti dalla riproiezione con il Geometry Service e dalle semplici API di Google Maps, che hanno dei metodi propri per la misura di linee e poligoni.
Posted in Cartografia, Sviluppo, Tutorial, Web 2.0, Web-Mapping, gis | 4 Comments »
1 marzo, 2010
Era da un po’ che avevo in mente di dedicare un articolo a jQuery, finalmente – complici l’influenza che mi ha tenuto a riposo forzato e l’ispirazione tratta da Linfiniti – sono riuscito nell’intento.
Per chi non lo sapesse, jQuery è un framework Javascript open source molto potente, caratterizzato da una sintassi snella e di facile comprensione.
Il framework è rilasciato con doppia licenza: MIT e GPL.
I motivi per usare jQuery nei propri progetti non mancano di certo: comunità attiva, disponibilità di molti temi e ottimi plugin, compatibilità e leggerezza sono i primi che mi vengono in mente.
In questo articolo vedremo come costruire una mappa online sfruttando jQuery UI e OpenLayers.
Il risultato della “fusione” è un client dotato di funzionalità di base come zoom, pan, misurazione delle distanze e vari layer di sfondo intercambiabili.
Si tratta, in pratica, di un template da cui partire per sviluppare applicazioni di web-mapping vere e proprie.
Per creare il client dell’esempio abbiamo bisogno di:
Ho già raccolto il tutto in questo archivio .zip. Qui dentro, oltre alle librerie, si trova la totalità dei file che compongono il client. Vi basta quindi cliccare sul link per avere il template sul vostro computer, pronto all’uso e/o ad essere trasformato come volete.
Vi invito però a dare lo stesso un’occhiata alla pagina di download di jQuery UI: noterete che è possibile modificare radicalmente il pacchetto prima di scaricarlo. Potete includere le sole componenti utili ai vostri scopi e scegliere tra vari temi già pronti o uno composto da voi con ThemeRoller.
Io ho fatto solo qualche semplice modifica al tema UI-Darkness (in questo periodo non mi piacciono i bordi arrotondati…) ma, come dicevo, si può fare molto di più. Provare per credere.
Ora un po’ di anatomia.
Scompattato l’esempio, è bene posare lo sguardo su alcune delle directory e dei file compresi al suo interno.
jsLib
E’ la directory contenente tutte le librerie elencate in precedenza, necessarie al funzionamento del template.
index.html
Nella sezione header sono referenziate le librerie utilizzate, i fogli di stile e i file javascript.
Nel body è possibile notare che l’attributo class di molti degli elementi della pagina (div, button, span, ecc.) è parecchio popolato. Questo è il metodo con cui jQuery UI e jQueryUI.Layout si “ancorano” alla pagina web.
Per comprendere meglio vi rimando alla pagina degli esempi di jQuery UI.Layout e a questo articolo che spiega in maniera egregia la composizione della toolbar e dei suoi pulsanti.
jsFunc/mappa.js
Contiene la mappa realizzata con OpenLayers.
Nella funzione di inizializzazione (initMap) richiamata al caricamento della pagina, ci sono, tra le altre cose, i controlli collegati ai bottoni della toolbar.
jsFunc/layout.js
In questo script, con poco più di 40 righe di codice, jQuery UI e i suoi plugin definiscono Il layout dell’applicazione, il tema, il comportamento e l’aspetto di bottoni e tooltip.
Css/style.css
A parte qualche piccola “frivolezza” come queste (a mio giudizio) bellissime icone, in questo foglio di stile sono descritte le regole fondamentali per la corretta presentazione del layout e della toolbar creati tramite jQuery UI.
Ecco, questo è grossomodo ciò che bisogna sapere per iniziare a studiare i mille modi di mescolare le potenzialità di jQuery a quelle di OpenLayers.
Fondamentale, come sempre, è il ricorso alla documentazione ufficiale dei vari progetti e al supporto offerto dalla comunità.
Per chiudere segnalo anche due guide in italiano, estremamente ben fatte ed utilissime per avvicinarsi a jQuery e jQuery UI. Entrambe sono firmate HTML.it:
Guida a jQuery
Guida a jQuery UI
Posted in OS, Sviluppo, Tutorial, Web 2.0, Web-Mapping, gis, osgeo | 10 Comments »
9 gennaio, 2010
Introduzione
A Febbraio del 2006 – tantissimo tempo fa … – ho scritto un piccolo post sull’installazione di MapServer in ambiente Windows su un sistema in cui fosse già installato un webserver (Apache in particolare).
E’ stato un post che ha ricevuto molte letture, ma che ha anche subito qualche “legnata tecnologica”. Lo avevo scritto infatti non dentro il motore di questo blog (WordPress), ma dentro Writely.
Cosa è Writely? E’ nientepopodimeno che l’applicazione online su cui è basato l’editor di testo di Google Docs, comprata per l’appunto da Google proprio in quell’anno.
Ho scritto l’articolo, ho inserito anche delle immagini d’aiuto alla comprensione del testo, ed ho pubblicato tutto su questo blog con un click; il testo è stato contestualmente archiviato sui server di TANTO, mentre le immagini sono rimaste sui server di Writely. Questi non sono stati spenti subito e, per diverso tempo, questo vecchio glorioso articolo non ha subito alcuna conseguenza dal passaggio di Writely a Google. Spenti i server, sono sparite le immagini ed in qualche modo anche la leggibilità del post in oggetto. Ho provato a ripescarle dall’Internet Archive Wayback Machine, ma senza fortuna.
In ogni caso dovevo rimediare da tempo. Avevo rimosso dalla memoria il problema (sorry 
), e un commento recente mi ha messo nuovamente davanti alla cruda realtà (grazie riccardo). L’articolo inoltre è datato anche nei contenuti, e valeva la pena dargli una rinfrescata.
Posted in Tutorial, Web-Mapping | 4 Comments »
10 agosto, 2009
Era un pezzo che desideravo sperimentare Yahoo Pipes, dopo esserne venuto a conoscenza grazie ad Andrea (ricorderete il suo precedente geniale post). In effetti ho giocato d’anticipo proprio su di lui, per cimentarmi a produrre un GeoRSS in puro stile web 2.0.
Non ho certo intenzione di mettermi qui a tessere le lodi di Pipes, sebbene a mio avviso non se ne parli mai abbastanza. Voglio solo ribadire che si tratta di uno strumento web 2.0 dalle potenzialità pressoché infinite, che aumentano esponenzialmente in funzione della crescente messe di risorse e fonti di dati disponibili sul web. A patto che, inutile dirlo, lo siano secondo standard aperti, come già Andrea ha molto ben sottolineato proprio nel suo citato articolo.
Passiamo ai fatti.
Un item GeoRSS, nella codifica W3C ha la seguente struttura:
<?xml version=\"1.0\"?>
<?xml-stylesheet href=\"/eqcenter/catalogs/rssxsl.php?feed=eqs7day-M5.xml\" type=\"text/xsl\"
media=\"screen\"?>
<rss version=\"2.0\"
xmlns:geo=\"http://www.w3.org/2003/01/geo/wgs84_pos#\"
xmlns:dc=\"http://purl.org/dc/elements/1.1/\">
<channel>
<title>USGS M5+ Earthquakes</title>
<description>Real-time, worldwide earthquake list for the past 7 days</description>
<link>http://earthquake.usgs.gov/eqcenter/</link>
<dc:publisher>U.S. Geological Survey</dc:publisher>
<pubDate>Thu, 27 Dec 2007 23:56:15 PST</pubDate>
<item>
<pubDate>Fri, 28 Dec 2007 05:24:17 GMT</pubDate>
<title>M 5.3, northern Sumatra, Indonesia</title>
<description>December 28, 2007 05:24:17 GMT</description>
<link>http://earthquake.usgs.gov/eqcenter/recenteqsww/Quakes/us2007llai.php</link>
<geo:lat>5.5319</geo:lat>
<geo:long>95.8972</geo:long>
</item>
</channel>
</rss>
L’obiettivo è costruire un GeoRSS a partire da una fonte di dati che viene aggiornata in tempo reale, nella fattispecie – e tanto per essere originali – l’elenco dei terremoti rilevati dal Centro Nazionale Terremoti dell’INGV, sul cui sito vedrete una pagina html con tutti gli ultimi eventi rilevati.
Per il nostro lavoro utilizzeremo sempre le stesse informazioni, ma in formato standard CSV – disponibili qui – dunque perfettamente importabili pressochè ovunque. Vediamone i contenuti:
- Lat – la latitudine dell’evento in gradi decimali;
- Lon – la longitudine dell’evento in gradi decimali;
- Depth – la profondità dell’ipocentro in km;
- UTC_Date – il momento temporale nel quale l’evento è stato registrato;
- Magnitude – la magnitudine Richter dell’evento;
- Locality – il distretto sismico nel quale è avvenuto il terremoto;
- Code – un codice univoco relativo all’evento;
- Query_Time – il tempo di query del file CSV, corrispondente a quello di caricamento della pagina del sito INGV.
In Pipes, il primo passo consiste nell’andare a recuperare (fetch) la fonte dei dati (il file CSV) per poterne poi utilizzare il contenuto. Verrà utilizzato il modulo “Fetch CSV” nel quale andremo ad inserire l’URL del CSV, usando la prima riga come intestazione delle colonne.
Per poter generare il GeoRSS, Pipes deve “vedere” nei dati recuperati elementi che siano chiaramente riferibili a una coppia di coordinate, pertanto rinomineremo i campi “Lat” e “Lon” del CSV nei prosaici “Latitude” e “Longitude” mediante il modulo “Rename”.
Lo standard GeoRSS prevede alcuni item che consentono di arricchire di informazioni descrittive ogni elemento geotaggato, poi visibili nel “balloon” ad esso associato in fase di visualizzazione su mappa.
Naturalmente si tratta di informazioni residenti nel CSV, che noi andremo opportunamente a rinominare in modo da consentire a Pipes di includerle nel singolo elemento del GeoRSS. Si tratta essenzialmente di:
- <title> – il titolo dell’elemento, in questo caso il distretto sismico nel quale è avvenuto l’evento;
- <link> – l’URL alla risorsa associata all’elemento, ovvero la pagina dedicata al singolo evento sismico, realizzata dall’INGV;
- <description> – la descrizione dell’elemento, con la magnitudine, la profondità dell’ipocentro e la data del terremoto.
Passeremo queste informazioni al Pipe semplicemente usando sempre il modulo “Rename” avendo stavolta l’accortezza di scegliere l’opzione “Copy As”.
Qui sopra per <title>, con la necessità di sostituire l’antiestetico underscore presente nel campo “Locality” del CSV con uno spazio vuoto (blank) grazie al modulo “Regex”.
La <description> dell’elemento geotaggato come già detto è costituita da magnitudine, profondità dell’ipocentro e data dell’evento sismico, informazioni presenti in tre differenti campi del CSV, che andremo a comporre in un’unica stringa grazie al modulo “String Builder”. Questo verrà utilizzato però nell’ambito di un modulo “Loop”, poichè è un’operazione che va ripetuta per ogni elemento presente nel CSV.
Notate come il risultato dello String Builder vada ad essere assegnato all’item <description>.
L’INGV, per ogni evento sismico registrato, genera una pagina html che riporta informazioni estremamente dettagliate riguardanti il terremoto, molto preziose per chi si occupa di sismologia, di protezione civile o comunque davvero interessanti anche a scopo didattico. Qui quella relativa al famigerato evento del 6 aprile scorso che ha devastato l’Aquilano.
Osservando l’URL si nota che la stringa risulta la seguente:
http://cnt.rm.ingv.it/data_id/[codice evento]/event.php
dunque ciò che cambia è il codice evento, registrato nel campo “Code” del CSV. Ancora una volta, useremo la combinazione dei moduli “Loop” e “String Builder” per costruire il link alla pagina di ogni evento, assegnando il risultato all’item “eventoURL” che verrà poi rinominato nell’item <link>.
Dulcis in fundo… il modulo che genera il vero e proprio GeoRSS… voilà, si tratta di “Location Extractor”.
Voi direte: “embè, e i parametri dove sono?!?”. E’ quel che mi son chiesto anch’io quando l’ho visto. Ma poi leggendo la descrizione del modulo (cosa che vi consiglio vivamente di fare), si capisce come funziona:
Questo modulo esamina il feed in input, alla ricerca di informazioni che indichino una località geografica. Se trova dati geografici, il modulo crea una y:location che costituisce l’elemento di output. Questo contiene svariati sotto-elementi, in funzione del feed di input.
Dunque fa tutto lui. In pasto possiamo dargli sorgenti GML, W3C Basic Geo, tags KML e ovviamente GeoRSS, in output fornirà appunto l’elemento y:location, che potrà essere visualizzato direttamente su una mappa interattiva Yahoo Map. Qui sotto il risultato…
Ma il vero valore aggiunto del pipe è quello di poter essere impiegato in svariati modi, dal “banale” embedding della mappa in blog e siti web, per finire ad altri davvero potentissimi, riutilizzabili in una miriade di modalità. Solo per citarne alcuni JSON, PHP, KML e ovviamente GeoRSS.
E proprio il GeoRSS può essere usato ad esempio con OpenLayers, scrivendo un pò di codice html è possibile in pochi minuti importare il feed generato dal pipe come layer grazie alla call OpenLayers.Layer.GeoRSS ottenendo una mappa semplice ma efficace, come si vede in questo esempio… Altre modalità di fruizione del GeoRSS – generate sempre in modo automatico – le riporto qui appresso giusto per coloro che non hanno voglia di andare a consultare la pagina del pipe:
Insomma, a noi Yahoo Pipes ci fa letteralmente sognare… Perchè sapere di avere uno strumento col quale poter attingere, trasformare, plasmare e “ricablare il web” (il loro slogan) e i dati sparsi per il mondo usando la logica ad oggetti, dedicando i propri neuroni solo ed esclusivamente alle idee e al modo di tradurle in fatti… beh, è davvero troppo, troppo entusiasmante.
E allora “Yes, we Pipe!”… ma prima ancora “Linked Data… now!!!”.
Posted in Didattica, Entropia, GeoDati, Tutorial, Web 2.0 | 2 Comments »
4 maggio, 2009
Prima di entrare nel vivo di questo brevissimo tutorial, caliamoci nello scenario adatto:
supponiamo che vi siano arrivati dei geodati o delle informazioni geografiche su cui lavorare e che dobbiate, una volta completata la loro elaborazione, mostrare il risultato del vostro brillante operato a qualcuno che non può sedersi di fronte al monitor del computer con voi ed è colto da visioni apocalittiche al solo sentir nominare uno shapefile o pensa che PostGIS sia un piatto tipico.
Che fare? Mettere in piedi un’applicazione di webmapping “vera” (per esempio con MapFish) richiede quel minimo di tempo, di cui non è sempre detto che si disponga, e ci costringe a scrivere un po’ di codice… cosa che oggi non abbiamo assolutamente voglia di fare 
Per fortuna, per soddisfare in maniera rapida e indolore la sete di “sapere geografico” del nostro interlocutore, possiamo approfittare dei servigi di Google.
Fatto il doveroso preambolo, passiamo alla pratica.
Creeremo un’applicazione che, pur non essendo di webmapping in senso stretto, svolgerà egregiamente il suo compito, vale a dire condividere online l’informazione geografica in maniera estremamente speditiva e piuttosto efficace.
Di cosa c’è bisogno?
- dei vostri geodati in formato KML o KMZ;
- di un account Google[1] che, se usate Gmail, avete già;
- Google Earth.
Per trasformare i dati in KML ci sono un’infinità di metodi e di programmi più o meno adatti alle varie esigenze, quindi non entreremo nel merito di questa operazione nel tutorial.
Personalmente, se sto lavorando con ArcGIS, per esportare le feature in formato KML direttamente da ArcMap utilizzo questo script liberamente scaricabile dal sito di ESRI.
In alternativa possiamo ottenere tutti i KML che vogliamo sfruttando la libreria GDAL/ORG (magari attraverso FWTools).
Una volta che i file KML sono pronti all’uso potremmo già pubblicarli su Google Maps grazie al nostro account (utilizzando il link “My maps” o, in italiano, “Le mie mappe” nella home page di Google Maps), ma noi vogliamo di più!
Spesso, infatti, allo scopo di rendere più leggibile l’informazione che vogliamo comunicare con una mappa, è comodo organizzare i contenuti in categorie da mostrare secondo una struttura ad albero composta da cartelle e sottocartelle (del tutto simile a quella ottenibile con il widget layer tree di MapFish).
Per creare questa struttura lanciamo, quindi, Google Earth e aggiungiamo le varie cartelle con un semplice click destro sulla cartella predefinita “Luoghi temporanei”. Si aprirà un menu contestuale dal quale selezioneremo la voce “Aggiungi” e poi “Cartella”:
Ripetiamo questa operazione tante volte quanti sono i nodi (o rami, se preferite) dell’albero che stiamo impostando e, se necessario, annidiamo sottocartelle a piacimento:
Ora che la struttura ad albero è pronta aggiungiamo i file KML dal menu “File” → “Apri” di Google Earth e poi spostiamoli diligentemente uno per uno all’interno della cartella desiderata. Infine, salviamo tutto in un unico file KML (o KMZ) cliccando col tasto destro del mouse sulla cartella “Luoghi temporanei” (che dovrebbe risultare la radice dell’albero).
Siamo finalmente pronti per pubblicare il risultato online tramite Google Maps ed è qui che entra in gioco il servizio Google Sites collegato col nostro account.
Grazie ad esso, infatti, disponiamo di uno spazio web sul quale possiamo caricare file di svariati tipi tra cui, ovviamente, anche KML e KMZ.
Accediamo quindi alla pagina principale del nostro account Google e, una volta effettuata l’autenticazione, clicchiamo sul link “Google Sites”. Se è la prima volta che utilizziamo il servizio, creiamo un nuovo sito cliccando sul bottone apposito.
Scegliamo la modalità preferita per caricare il nostro KML (è possibile allegarlo ad una pagina qualsiasi, magari alla homepage, che troviamo bella e pronta, o creare un “File cabinet” allo scopo).
Da adesso in poi la risorsa caricata sarà disponibile all’URL http://sites.google.com/site/nomesito/nomefile.kml
Per vedere il risultato finale incolliamo questo URL nel campo di ricerca di Google Maps, clicchiamo sul bottone “Cerca sulle mappe”… et voilà[2]
Non resta che copiare l’URL della nostra mappa cliccando sull’apposita voce “link” che appare in alto a destra in Google Maps ed inviarlo a chi ci pare!
…
[1]Disponendo di uno spazio web alternativo su cui caricare i file possiamo farne a meno
[2]I simboli utilizzati sono quelli disponibili di default in Google Earth… Vi consiglio anche di visitare i luoghi dell’esempio se capitate da quelle parti
Posted in Google Earth, Tutorial, Web 2.0, Web-Mapping | 13 Comments »
