L'articolo Novità in Mapserver 6.0.0-beta1 è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Ciò che mi ha colpito profondamente è invece la grande visionarietà degli interventi. Ognuno di loro era lì per raccontare il proprio sogno, nella convinzione che l’idea della quale avrebbe parlato, avrebbe portato una rivoluzione. Detta così sembra una boutade. E invece no. Si tratta di gente che sa quel che dice.

Di recente A. Turner e B. Forrest hanno scritto Where 2.0: The State of the Geospatial Web, un report che tenta di tirare le somme di quelle giornate. Impresa davvero titanica, e loro ne sono consapevoli. E per questo hanno voluto concentrare la loro attenzione su alcuni concetti chiave venuti fuori dai lavori della conferenza. Il documento è costituito da due parti, nella prima c’è la ciccia, mentre la seconda è una sorta di Pagine Gialle, con un profilo delle aziende e dei soggetti operanti nel settore. I due autori hanno messo a disposizione solo un estratto, le prime 15 pagine, sufficienti comunque a farsi un’idea di quali siano i trend che di qui a qualche anno diverranno il fulcro di tutta la partita che si giocherà attorno al GeoWeb. Io personalmente ho letto solo l’estratto, perchè francamente non mi andava proprio di spendere $400 per acquistare le restanti 40 pagine del report. Comunque, mi piacerebbe discutere di questi trend proprio qui, sia “saccheggiando” che commentando il documento, nella convinzione che siano di interesse per chi cerca di vivere delle cose che ci piacciono TANTO.

Innanzitutto, è importante soffermarsi su un nuovo paradigma sul quale poggiano queste riflessioni, ovvero proprio “Where 2.0“. Alla O’Reilly si riferiscono con questo termine all’emergente Geospatial Web, con un palese riferimento al Web 2.0: internet come piattaforma anche per le applicazioni geografiche. Nel Web 2.0 i dati sono diventati servizi, non più il software. Servizi che letteralmente diventano migliori quanto piu’ vengono utilizzati.

Il futuro sistema operativo, basato su internet, dovrà essere dotato di sottosistemi capaci di attingere a numerose e svariate fonti di dati, e di mescolarle. Questi dati saranno con il tempo quelli piu’ aggiornati, sia da soggetti commerciali che dalle community di volontari e appassionati. Tra questi sottosistemi, il GeoWeb è forse quello maggiormente sviluppato, perché è “multiplayer” e “multilayer”; un melange ricco di dati, servizi e opportunità. Uno dei concetti chiave che è possibile imparare dal GeoWeb, è come i suoi sottosistemi di dati si propongano come mercati aperti quando esiste un substrato, solido e standardizzato, sul quale altri dati possano essere sovrapposti.

Ad esempio il fenomeno dei mashup si è diffuso da quando è stato “hackerato” il sistema di implementazione dei dati di Google Maps. Big G, lungimirante, ha poi immediatamente rilasciato le proprie API aperte (a proposito, qualcuno di voi ha ricevuto la stizzita email del PCN sul “saccheggio” delle ortofoto?). Da quel momento le innumerevoli applicazioni basate su quelle API proliferano in maniera vertiginosa giorno dopo giorno.

E allora? E allora il GeoWeb non può fare a meno di soggetti – privati, pubblici e “open” – capaci di fornire software, dati e IT – ma soprattutto idee e progetti – che per la natura intrinseca del GeoWeb, hanno grandi potenzialità di integrazione tra essi. La sfida per tutti noi che siamo in ballo è dunque quella di trovare la propria dimensione, la propria vocazione nella grande entropia del GeoWeb: sarà la capacità di leggere i trend verso i quali questo complesso universo si muove, che ci permetterà di lavorare al meglio, senza mai sentirsi indietro anni luce rispetto agli altri. La Geografia sarà sempre libera.

Qui di seguito vengono brevemente riportati proprio i trend più interessanti per il GeoWeb – presenti nel report – intesi soprattutto come opportunità per chi opera a vario titolo nel settore. Appare immediata l’enorme dinamicità di alcuni progetti già maturi, come pure le grandi potenzialità di altri ancora in embrione. Colpisce davvero molto proprio questa grande entropia che caratterizza il GeoWeb e tutto ciò che gli ruota intorno.

Merging data colllection with data maintenance.

Nokia ha acquisito la Navteq e TomTom la Tele Atlas; ciò fa capire come i geodati di base – in questo caso i grafi stradali – siano una risorsa fondamentale per applicazioni di geolocation e PND. I costi di manutenzione e aggiornamento di tali dati sono però elevatissimi. E allora sono state messe a punto tecnologie di aggiornamento di tipo attivo e passivo, entrambe coinvolgono gli stessi utilizzatori dei sistemi. TomTom, con MapShare consente agli utenti di segnalare errori nella viabilità, mentre Dash Navigation monitora continuamente i viaggi degli utenti – alla faccia della privacy! – in tal modo statisticamente puo’ individuare i cambiamenti nella viabilità e gli errori nei dati.

Open Data

Il valore propositivo dei dati aperti è il medesimo del software open source: individui e società commerciali contribuiscono al mantenimento del grosso dei dati, cosicché tutti possano beneficiarne. I dati vengono forniti in formati aperti e licenze non proprietarie. Uno dei migliori esempi di progetto che si basa sulla disponibilità di dati aperti e pubblici è GeoNames, che ha costruito un database con i nomi delle località provenienti da fonti di dati pubbliche. Purtroppo l’appetito vien mangiando, e GeoNames sta progressivamente riducendo l’accesso gratuito ai propri servizi, richiestissimi, comunque ampiamente sufficienti alle esigenze dei più.

User generated geospatial information.

Analogamente all’aggiornamento e manutenzione dei dati esistenti di cui s’è parlato prima, gli utilizzatori del GeoWeb possono diventare creatori di nuovi geodati sia in modo passivo che attivo. Al primo caso possiamo ascrivere il servizio di geotagging di foto e video di Flickr. Gli utenti, geoposizionando le proprie foto,  e vi associano anche dei tag che quasi sempre sono almeno il nome del luogo. In questo modo si viene a creare un grande database di nomi di luoghi (toponimi?) che puo’ avere un dettaglio anche maggiore dei prodotti “ufficiali”. Un esempio invece di creazione di geodati totalmente nuovi in maniera aperta e comunitaria è il maiuscolo OpenStreetMap. Una sintesi fantastica delle due cose è questa: un’interfaccia di webmapping con alcune foto di Flickr scattate a Pechino, e OpenStreetMap come base cartografica. L’esempio ci fa capire come sia facile mescolare fonti e tecnologie, ma soprattutto quanto siano efficaci progetti aperti di questo tipo (qui per saperne di più). Un progetto molto simile, che integra basi di conoscenze differenti (logs GPS, foto geotaggate) – certamente conosciuto dagli escursionisti non “tecnolesi” – è EveryTrail, grazie al quale è possibile scaricare percorsi trekking con tanto di foto. Ovviamente si tratta di un progetto alimentato in maniera volontaria, su formati di dati aperti (stavolta GPX).

Open*.org

Ma OpenStreetMap è anche di più. Il progetto si è ormai espanso, oltre che come quantità e qualità dei dati anche come tipologia, ed ora oltre a quelli stradali si possono trovare anche dati sull’uso del suolo e addirittura imagery raster, grazie al progetto parallelo OpenAerialMap. Progetti di questo tipo, alimentati in maniera volontaria, basati su OS e con dati non coperti da copyright, hanno fatto comprendere ad alcuni soggetti privati del settore che possono essere una risorsa, anzichè concorrenti. La Automotive Navigation Data, società olandese di PND, ha infatti donato gratuitamente a OSM la propria copertura di dati per l’Olanda e la Cina, la contropartita è ovviamente quella di utilizzare i dai OSM da parte di AND. Innegabili sono infatti le potenzialità di dati liberi generati da comunità di utenti, contro quelli proprietari generati da società private. Un esempio ne è la copertura stradale di Khartoum del progetto OSM (qui) contro quella di Google Maps, con dati NAVTEQ (qui).

L’importanza di essere aperto

Ed è cambiato anche il paradigma legato ai dati con formati aperti e liberi di essere usati. Sebbene qui in Italia sia ancora controversa e difficile la situazione su libero utilizzo e libera distribuzione dei dati detenuti da soggetti pubblici (enti locali, università, ecc), a livello globale l’emergere e affermarsi di standard come KML e GeoRSS obbliga di fatto tutti i soggetti coinvolti a vario titolo nel GeoWeb a concentrarsi ancora una volta sulla ricchezza dei dati e l’architettura dei servizi, piuttosto che sulle scelte tecnologiche e di sviluppo delle applicazioni per poterli usare. Il risultato che ne deriva è una base di conoscenze costruita in maniera condivisa e spontanea, costituita da informazioni non strettamente spaziali, ma che possiedono un valore geografico. Ecco che le foto di Flickr ormai da tempo possono essere geotaggate, come pure i video di Youtube, ed ovviamente essere esportati in KML per venire utilizzati in qualunque applicazione. Un paio di settori in forte espansione sono infatti quello relativo alla conversione di dati da formati proprietari ad aperti – che per le grandi organizzazioni non è uno scherzo affrontare – e il geotagging di documenti e contenuti di qualunque genere, per renderli pronti ad essere utilizzabili nel grande mondo del GeoWeb, in continua, incessante ed inesorabile espansione.

Concludo queste considerazioni sul GeoWeb – fortemente ispirate dal report O’Reilly – ringraziando Andrea, sempre prodigo di consigli e suggerimenti, che mi ha segnalato una delle sue prodigiose scoperte: la presentazione Beyond Google Maps che Mapufacture/Geocommons hanno tenuto al Future of Web Applications FOWA 2008 a Londra. Riesce a sintetizzare con poche parole e molte immagini i concetti dei quali abbiamo discusso qui, dipingendo un futuro davvero entusiasmante per il GeoWeb. Futuro che – in realtà – è già presente…

Godetevela qua sotto, e naturalmente date un’occhiata al report di O’Reilly.

L'articolo Where 2.0: è davvero cosi’ distante da qui? è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

GeoServer supporta i protocolli WFS-T e WMS dell’OGC e produce JPEG, PNG, SVG, KML/KMZ, GML, PDF, Shapefiles e altro ancora. Queste tutte le eccezionali caratteristiche.

Da oggi esiste una mailing italiana dedicata a questo applicativo, moderata da Andrea Aime (uno degli sviluppatori principali del pacchetto). Questo l’indirizzo della lista:

http://groups.google.com/group/geoserver-ita

L'articolo Nasce la mailing list italiana di GeoServer è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Ognuna di queste esperienze (Openstreetmap, Everytrail, Greenmap solo per citarne alcune) meriterebbe un post di approfondimento, qui però voglio parlare di un progetto/software commerciale, ma che esprime la potenza dell’informazione geografica condivisa in maniera collettiva e dinamica.

Si tratta di TITAN, una “VPN geospaziale” sviluppata da Leica/ERDAS, che permette appunto di condividere dati geografici e costruire un ambiente di lavoro, sempre condiviso, con altri utenti. Il tutto in pochi minuti, installando il client scaricabile dal sito di ERDAS.

Il client è rilasciato sotto licenza freeware, ma trattandosi di un servizio commerciale il suo utilizzo base è limitato a un massimo di 10 file o 10GB totali di dati condivisi, mentre non c’è limite alla visualizzazione di dati in locale. Per poter utilizzare i servizi è necessario registrarsi alla community di TITAN e loggarsi mediante il client al GeoHub pubblico.

Gli strumenti che vengono messi a disposizione sono due. Il primo è un instant messenger (qui a fianco) con il quale è possibile entrare in contatto con altri utenti, visualizzarne dati e servizi condivisi, ed eventualmente sceglierli, scambiarli, oltre naturalmente a gestire i propri. Il secondo è un viewer 3D (qui sotto) in stile Google Earth con il quale è ovviamente possibile caricare/gestire/consultare i dati propri e quelli degli utenti connessi al GeoHub. La vista principale è quella di visualizzazione dei dati, mentre nella vista di “lavoro” è anche possibile aggiungere layer propri o di altri utenti, cercare luoghi, interrogare la mappa e disegnare semplici elementi vettoriali, a mò di annotazioni, che sarà poi possibile esportare in KML.

I propri dati/servizi… possono essere condivisi in tutti i formati più diffusi, sia raster che vettoriali, definendo per ciascun layer i permessi di accesso da parte degli altri utenti in maniera molto dettagliata. In questo modo possiamo cotruire un gruppo di lavoro ristretto con altri utenti che utilizzano il GeoHub pubblico.

…e quelli degli altri. Allo stesso modo sarà possibile usare i dati/servizi altrui, naturalmente in funzione dei permessi impostati dai proprietari.

Lo scambio di servizi avviene attraverso un GeoHub, ovvero un server che nella versione freeware è quello pubblico di ERDAS, mentre se si ha necessità di metterne su uno ad hoc, bisogna acquistare una licenza. Detto questo per dovere di cronaca, vale la pena dare un’occhiata alle possibilità che TITAN offre, al di là del suo essere una soluzione commerciale.

Il serving dei dati avviene secondo standard OGC, infatti ogni layer condiviso, da noi o da altri, è possibile utilizzarlo in due modi, il primo direttamente nel viewer di TITAN, in Google Earth o Virtual Earth. Il secondo mediante servizio WMS che TITAN crea facilmente per ogni layer, sarà sufficiente cliccare col tasto dx sul tematismo e scegliere “WMS link”, poi incollare il contenuto in un qualunque GIS desktop come servizio WMS. Il server è sempre il GeoHub, sarà il client sulla nostra macchina a “passargli” i dati da noi condivisi.

Sebbene TITAN non sia OS, e rilasciato solo per Windows, le sue funzionalità free (ricordo max 10 layer e/o max 10GB totali di dati condivisi) sono davvero interessanti e innovative. Gli utenti facenti parte della comunità geospaziale possono facilmente scambiare idee in real-time col messenger così come scambiarsi dati, contribuire collettivamente a costruire scenari dinamici renderizzati in 3D…

La capacità con TITAN di poter mettere in condivisione, anche via WMS e WCS, in pochi minuti i propri dati è sicuramente interessante per chi non ha voglia, tempo o possibilità di mettere su un proprio server WMS. Cosa che ai puristi del webgis farà certamente storcere il naso, ma che costituisce una valida alternativa per l’utente medio interessato essenzialmente alla condivisione e all’accesso di dati spaziali.

Insomma, con TITAN è divertente smanettare, fare esperimenti, condividere in pochi minuti dati con altri utenti e scambiare opinioni su scenari condivisi, con l’ausilio di una sorta di vera e propria “chat geospaziale 3D”.

Naturalmente, la via maestra nella condivisione delle informazioni geografiche rimarrà sempre quella dell’utilizzo di pacchetti e soluzioni software open source, ormai tutto sommato alla portata di chi ha voglia e passione di cimentarsi…

L'articolo Condividere… geograficamente parlando è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

• Lesson 0: Orientation
• Lesson 1: Introduction to Open Web Mapping
• Lesson 2: Web Map Servers (WMS)
• Lesson 3: Web Feature Servers (WFS)
• Lesson 4: Extensible Markup Language (XML)
• Lesson 5: Advanced Web Map Servers
• Lesson 6: Geographic Markup Language (GML)
• Lesson 7: WFS Revisited
• Lesson 8: Building a Web Mapping Application
• Lesson 9: Building a Thin Custom Web Mapping Client

Il corso è interamente scaricabile ed io lo sto archiviando con ScrapBook.

L'articolo Un corso sulla cartografia online con strumenti Open è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Architettura dei Geoportali
Un Geoportale è un sito web dedicato alla consultazione di cataloghi online di risorse geospaziali (dati e servizi).
Il primo passo nella costruzione di un geoportale è la definizione dei requisiti dell’architettura che sarà adottata nella sua realizzazione. La funzione dell’architettura è definire scopi, obiettivi e caratteristiche di un portale ed identificarne le componenti funzionali. Uno degli standard architetturali interoperabili di riferimento è rappresentato dalla Geospatial Portal Reference Architecture (GPRA), un nucleo di accordi sull’interoperabilità proposte dall’OpenGIS Consortium che fornisce le istruzioni destinate a colmare le distanze tra differenti organizzazioni ed a semplificare lo scambio di informazioni spaziali. La GPRA fornisce le basi per la realizzazione di portali aperti e “tecnologicamente neutri” ed è stata sviluppata in modo da essere compatibile con altri modelli di riferimento ad alta complessità architetturale. Uno schema della GPRA è illustrato in Figura 1.

Figura 1 – Schema concettuale della GPRA applicato ad un esempio di geoportale. Cittadini ed istituzioni accedono ai dati attraverso gli strumenti messi a disposizione dal sistema e pubblicati in un portale web. L’accesso è garantito da una serie di servizi, messi a disposizione dal portale dai fornitori di dati, che consentono la ricerca, la rappresentazione, l’elaborazione ed il download delle informazioni di interesse per l’utente. Il portale non contiene necessariamente informazioni ma agisce da mediatore tra utenti e fornitori.

Questa architettura di riferimento si basa su 4 classi di servizi che esplicano le funzioni essenziali di un portale geospaziale. Le 4 classi di servizi sono:

• Servizi del portale – forniscono un punto di accesso unico all’informazione geospaziale in un portale; includono la gestione e la amministrazione del portale;
• Catalogo – usato per individuare servizi ed informazioni geospaziali e restituire i risultati di ricerche agli utenti;
• Servizi di rappresentazione – usati per elaborare le informazioni geospaziali e preparale per la presentazione all’utente;
• Servizi di dati – forniscono contenuti geospaziali e elaborazione dei dati.

I Servizi del Portale sono gli unici a dover risiedere sulla piattaforma HW/SW su cui risiede il portale. Tutti gli altri servizi possono essere distribuiti su internet e possono essere eseguiti e registrati dinamicamente. Si noti che il portale non è il luogo di archiviazione dei dati geospaziali elaborati dai servizi distribuiti.
La GPRA è un esempio di architettura software orientata ai servizi. Le caratteristiche di questo tipo di architetture sono descritte di seguito.

Le architetture orientate ai servizi (Service Oriented Architecture – SOA)
Un architettura orientata ai servizi consente di rendere disponibili in rete differenti risorse IT (software e dati) richiamabili come servizi a richiesta.
Con la locuzione inglese di Service Oriented Architecture si indica un’architettura software che soddisfa le richieste degli utenti usando servizi e consentendo l’utilizzo delle singole applicazioni come componenti di un processo. Le architetture di tipo SOA semplificano la modifica delle modalità di interazione tra i servizi o della combinazione nella quale i servizi vengono utilizzati nel processo. Esse inoltre agevolano l’aggiunta di nuovi servizi o la modifica di processi in risposta a specifiche esigenze.
E’ importante ricordare come in tale tipo di architettura i processi non sono più vincolati ad una specifica piattaforma o ad un’applicazione ma possono essere intesi come componenti di un processo più ampio, e quindi riutilizzati o modificati.
Nel caso particolare di un geoportale, il tipo di servizio distribuito dalla SOA è rappresentato da servizi web che forniscono interfacce standard per l’erogazione di funzionalità software.
Le applicazioni basate su SOA forniscono le stesse funzionalità che è possibile trovare in architetture monolitiche con l’aggiunta dei seguenti vantaggi:

• semplicità nell’aggiornamento della logica di processo;
• semplicità di modifica senza necessità di riconfigurare l’architettura complessiva.

La logica SOA si adatta alla realizzazione di portali concepiti come punti unici di distribuzione di dati e servizi web forniti da differenti organizzazioni. In questa visione i portali possono non immagazzinare alcun contenuto. Dati e servizi rimangono sotto la responsabilità ed il controllo delle organizzazioni competenti che ne garantiscono affidabilità e manutenzione. Il portale diventa quindi una sorta di distributore di contenuti e servizi che possono essere tra loro estremamente diversificati.
Come già accennato particolare rilievo assume l’architettura di riferimento proposta dall’OGC. Si tratta di un’architettura orientata ai servizi che ha il suo nucleo nei percorsi di pubblicazione e ricerca e che supporta la raccolta dinamica di documenti distribuiti da differenti servizi e fornitori.

La negoziazione dei servizi: il paradigma Publish – Find – Bind
Il metodo centrale di comunicazione interno di un portale basato su architetture orientate ai servizi segue il paradigma della negoziazione dei servizi. La negoziazione dei servizi è un concetto fondamentale che regola la ricerca delle istanze di servizio disponibili e si compone di tre elementi fondamentali:

• Esportazione – l’offerta di un servizio;
• Importazione – la ricerca di un servizio tra quelli offerti;
• Interazione – il collegamento di un client o di un utenza ad un servizio.

Questi tre elementi costituiscono il noto paradigma “Publish – Find – Bind” (Pubblica – Cerca – Lega), che è alla base dei percorsi nella negoziazione dei servizi (Figura 2).
Per realizzare una negoziazione di servizi è essenziale che nell’architettura di riferimento del portale siano definiti tre ruoli fondamentali: il registro dei servizi, il fornitore dei servizi e l’utente.
Il Registro dei servizi (o Broker) registra l’offerta dei servizi offerti dai fornitori e restituisce le offerte dietro richiesta dell’utente. Il Fornitore di servizi (Provider) registra i servizi offerti presso un registro e fornisce servizi ai client o agli utenti. L’Utente (Requestor) ottiene i servizi offerti da un registro e si lega ai servizi erogati dai fornitori.

Figura 2 – La struttura della negoziazione dei servizi. Per esportare un servizio il fornitore ne invia al registro una descrizione, inclusa quella dell’interfaccia a cui l’istanza del servizio è disponibile. Per importare un servizio si inoltra al registro una richiesta con le caratteristiche del servizio cercato. Il registro esegue la ricerca e risponde con un rapporto che include tutte le informazioni necessarie a legarsi all’istanza di servizio cercata. E’ inoltre possibile definire alcune preferenze di ricerca che influenzano l’ordine in cui i servizi trovati vengono restituiti nel rapporto.

Auto descrizione dei Servizi
Per consentire una efficiente operatività delle architetture orientate ai servizi, questi ultimi devono essere in grado di auto-descriversi. In altre parole, ciascun servizio deve fornire una descrizione delle sue capacità e della sua posizione nella rete. Questa auto-descrizione è registrata nel catalogo del portale e consente al servizio di essere invocato dinamicamente senza necessità di modificare il software del portale. La descrizione di norma è scritta in eXtensible Markup Language (XML).

L'articolo Architettura dei geoportali: GPRA e SOA è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Uno dei modi di lanciare TNTmap è quello di collegarvi con la pagina principale di TNTmap, e cliccare sul link “Run TNTmap Builder” (in alto a destra). Dopo pochi secondi si aprirà l’applicazione, che è divisa in 4 parti principali (vedi figura sotto):

1. quella in cui è possibile scegliere il server WMS
2. quella con una carta “indice” di tutto il mondo
3. quella con tutti i layer disponibili sul server che abbiamo scelto
4. quella con soltanto i layer che abbiamo scelto di visualizzare

Di default TNTmap si connette al server pubblico di Microimages; tra gli esempi disponibili troviamo un’atlante delle oasi d’Egitto.

Per fare un test è più didattico partire da un esempio italiano. Tra gli enti nazionali che pubblicano i propri layer cartografici tramite WMS, c’è la regione Calabria. Il link del loro server WMS è:

http://217.58.108.246/scripts/wms_ccr_calabria.asp

Se incolliamo questo indirizzo nella text area di TNTmap dedicata all’inserimento della sorgente WMS, e clicchiamo sul tasto play (presente immediatamente a destra), verrà inviata una richiestà di “capabilities” al server calabro. In parole semplici, verrà richiesto al server quali siano i layer spaziali messi a disposizione. Se la richiesta andrà a buon fine, vi troverete in basso a sinistra l’elenco di questi layer. A questo punto basta cliccare sull’intestazione dei layer “Server WMS Centro …”, per fare sì che tutti gli strati informativi messi a disposizione diventino i componenti del layout cartografico che stiamo per costruire. L’ultimo passaggio è quello di cliccare sul tasto “New View” presente in basso a destra nell’interfaccia di TNTmap.

Otterrete come risultato una mappa interattiva della regione Calabria, alla quale potrete successivamente aggiungere altri layer da altre sorgenti WMS.

Una funzione di TNTmap che vi segnalo è quella che vi consente di utilizzare Google Earth come client. I passi da seguire sono i seguenti:

• lanciate TNTmap
• caricate sull’interfaccia principale di TNTmap i layer che volete vedere su Google Earth
• cliccare sull’icona in basso a destra con il logo di Google Earth
• salvate il file .kml che viene generato
• fate doppio click sul file salvato per lanciare google earth
• aspettate di essere portati sull’area che avete scelto di visualizzare

Se volete testare il risultato sulla vostra macchina, scaricate il seguente file per Google Earth.

L'articolo TNTmap Builder: un buon client OGC è apparso originariamente su TANTO. Rispettane le condizioni di licenza.