Questo articolo nasce dall’idea di aprire una finestra su quella branca della geomatica che si occupa della condivisione e diffusione in rete dell’informazione geografica, comunemente indicata col termine webmapping e spesso protagonista su questo blog.
Prima di entrare nel vivo del discorso, però, vorrei precisare che quello proposto è il mio personale punto di vista, costruito nel tempo in base alla mia esperienza professionale in questo campo. Esistono altri strumenti e approcci diversi rispetto a quello che vedremo nel corso dell’articolo, quindi, come sempre, ogni commento sarà ben accetto e spunto di ulteriore riflessione.
Sicuramente si parla di una delle specializzazioni dei Sistemi Informativi Geografici che negli ultimi anni si sono trasformate più velocemente, complice l’evoluzione del World Wide Web e delle tecnologie legate ad esso. Si tratta, inoltre, di una materia fortemente interdisciplinare in quanto, a prescindere dall’ambito nel quale l’applicazione di webmapping verrà impiegata (turismo, analisi ambientale, monitoraggi di vario genere, ecc.), a monte ci sono le competenze di almeno quattro figure professionali differenti che comprendono l’esperto di GIS, il Database administrator, lo sviluppatore e il sistemista.
Ho pensato di scrivere un articolo come questo perché spesso mi capita di avere a che fare con persone interessate ad avvicinarsi a questo mondo o semplicemente curiose di sapere “cosa c’è sotto” ma messe in seria difficoltà dalla quantità, eterogeneità e frammentazione delle informazioni disponibili in rete.
Tutto ciò, insieme all’esistenza di una moltitudine di soluzioni software, di tanti standard reali e de facto, di moltissime filosofie e approcci diversi, crea un labirinto intricato in cui è facile smarrirsi specialmente se si è agli inizi.
La cartografia su internet diventa popolare
Un grande contributo all’esplosione della cartografia su internet è arrivato da alcune applicazioni web basate su mappe, come Google Maps, Google Earth, Yahoo! Maps, Virtual Earth (ora noto come Bing Maps), comparse relativamente pochi anni fa e divenute di massa nel giro di pochissimo tempo.
Lungi dall’essere delle applicazioni GIS in senso stretto, hanno comunque il merito di saper mostrare la forza del punto di vista spaziale: ogni oggetto, se collocato nello spazio geografico, viene arricchito con nuove informazioni intrinseche nella sua localizzazione e nella relazione con gli altri oggetti che si trovano nelle sue vicinanze.
La potenza espressiva della cartografia su internet, per la prima volta sotto gli occhi di tutti e non dei soli addetti ai lavori, ha dato un importante input per il cambio di passo che ha condotto alle moderne applicazioni di webmapping.
Certamente questa direzione si è potuta intraprendere anche grazie all’aumento delle capacità di elaborazione dei browser e alla crescita degli strumenti e delle tecnologie per lo sviluppo delle applicazioni web, alcuni dei quali ideati e rilasciati dagli stessi soggetti titolari delle famose mappe online (si pensi, ad esempio, alle API di Google Maps).
Le vecchie cartografie web, oltre ad essere accessibili a pochi, richiedevano spesso tempi di caricamento lunghi o l’installazione di plug-in sulla macchina dell’utente. Le recenti applicazioni di webmapping, invece, beneficiano di uno spiccato livello di interattività e reattività, caratteristiche tipiche delle applicazioni Web 2.0 che sfruttano tecnologie come AJAX e si integrano alla perfezione nell’ecosistema del web moderno, composto da social network, feed RSS e servizi di varia natura.
Standard è bello… e pratico
Una ulteriore spinta alla diffusione di questa nuova generazione di applicazioni di webmapping è venuta dall’affermarsi di standard aperti, documentati e condivisi messi a punto dall’Open Geospatial Consortium (OGC).
Le maggiori case produttrici di software GIS, nonché le comunità open source con i loro innumerevoli progetti, hanno implementato nei loro prodotti il supporto ai principali standard OGC (WMS, WFS, WCS, ecc.) favorendo l’interoperabilità. Chi progetta e sviluppa applicazioni di webmapping oggi ha la possibilità di mescolare risorse disponibili in rete e risorse locali, di utilizzare tecnologie e piattaforme differenti in grado, però, di scambiare informazioni grazie al rispetto degli standard e di ottenere così degli efficacissimi mash-up tramite i quali diffondere l’informazione spaziale.
Lato server
A prescindere dai dati, preferibilmente mantenuti in un RDBMS spaziale (come PostGIS o Oracle Spatial), salvo situazioni particolari un’applicazione di webmapping ha generalmente bisogno di due componenti che operano sul server: il web server e il map server.
Il web server, come Apache, solo per citare il più diffuso e più famoso, è l’ambiente che renderà possibile la pubblicazione del lavoro e accoglierà le richieste provenienti dall’applicazione client (quella con cui l’utente interagisce) per passarle al map server. Quest’ultimo, per dirla in maniera molto sintetica, interpreta tali richieste e produce di conseguenza degli output (le mappe) che vengono spedite al client di nuovo attraverso il web server. Ovviamente questo è uno schema generale ed anche se formalmente corretto (ricalca il funzionamento di UMN-MapServer, che è uno dei map server più validi e versatili), occorre tenere presente che ogni software appartenente a questa categoria ha le proprie modalità specifiche di azione. Geoserver ed ArcGIS Server sono altri due ottimi esempi, il primo è gratuito ed open source, come lo è anche UMN-MapServer, mentre l’altro è un prodotto proprietario distribuito da ESRI.
Prima di chiudere la breve panoramica sugli strumenti lato server, è bene ricordare che nel caso delle applicazioni di webmapping più avanzate è necessario avere a disposizione anche un linguaggio di programmazione (Java, PHP, Python, ecc.) per organizzare la logica di business, cioè l’insieme degli algoritmi che gestiscono lo scambio di informazioni tra il client e la banca dati. UMN-Mapserver, ad esempio, è completo di API (Application Programming Interface) per i principali linguaggi di programmazione, mentre ArcGIS Server propone due ADF (Advanced Development Framework) per Java e .Net.
Lato client
Il client, come anticipato nel precedente paragrafo, è quella parte dell’applicazione con cui l’utente finale interagisce. Questo “strato” ha, perciò, un ruolo fondamentale nel decretare il successo o insuccesso dell’intera applicazione. Senza un client efficace che metta in risalto gli strumenti più importanti offerti all’utente e lo prenda quanto più possibile per mano nel compiere le operazioni che lo porteranno ad ottenere la risposta desiderata (un’estrazione di dati tramite interrogazione, l’analisi di una determinata variabile ambientale, ecc.), si rischia seriamente di vanificare gli sforzi profusi nella progettazione e implementazione del database e degli algoritmi lato server.
E’ ovvio che, pur progettando un client ideale, non è sempre possibile raggiungere la massima facilità di utilizzo, poiché tutto è influenzato dal numero delle funzionalità offerte, dalla loro complessità, dal tipo di utenti a cui ci si rivolge e da diversi altri fattori. Tuttavia un’interfaccia utente intuitiva è il risultato a cui si dovrebbe tendere quando si inizia a progettarla.
Come si realizza il client? Le soluzioni sono tantissime, dai template html di UMN-Mapserver, ai framework in PHP come p.Mapper (sempre per UMN-Mapserver) che mettono a disposizione un client con dei moduli dinamici lato server (PHP MapScript), a librerie Javascript come OpenLayers, di cui si è spesso parlato qui su TANTO.
Personalmente preferisco l’ultima soluzione in quanto costruire il proprio client da zero usando una libreria Javascript (OpenLayers non è l’unica), sebbene possa essere inizialmente più laborioso rispetto alla configurazione di un framework come p.Mapper, presenta degli indubbi vantaggi.
Sorvolando sulla valenza didattica del costruire una ad una le funzioni attivate dai vari tasti di una toolbar, ci si rende conto della bontà della scelta quando quello che offre un framework out of the box non basta più e si deve procedere ad un lavoro di personalizzazione/integrazione. Spesso modificare il comportamento di un software complesso, legato ad una specifica piattaforma (UMN-MapServer e PHP MapScript, nel caso di p.Mapper), che comprende numerosi script interconnessi tra loro richiede uno sforzo ben superiore a quello necessario per scrivere da zero una nuova funzione che faccia uso di una classe della libreria OpenLayers (oppure delle API di Google Maps o ArcGIS Server).
Un altro vantaggio – sempre nel caso in cui si scelga di lavorare con Javascript – è che si semplifica di molto l’integrazione nell’interfaccia di librerie per la costruzione di Rich Internet Application (RIA), come jQuery, Dojo, Mootools, YUI o ExtJS, ottime per la creazione di tutti quei piccoli espedienti che rendono il client efficace (nell’accezione usata in precedenza). C’è davvero l’imbarazzo della scelta.
Considerazioni conclusive
Come dicevo in apertura, ci si può discostare anche di molto da quasi tutti gli strumenti elencati e da questo approccio senza per questo sbagliare. Tuttavia nelle prime fasi è utile individuare e chiarire dei concetti specifici, imparare a padroneggiare gli strumenti per muoversi con disinvoltura e poi, in seguito, avventurarsi e testare soluzioni alternative e sempre più originali. In ogni caso alcuni punti, come la creazione di un client intuitivo o il rispetto degli standard, hanno una valenza generale e andrebbero sempre tenuti in debita considerazione a prescindere dalle scelte che si opereranno. Non mi resta che augurare buon divertimento a tutti.
Sono un biologo marino specializzato in geomatica con master in Sistemi Informativi Territoriali e Telerilevamento presso il Centro di Geotecnologie dell'Università di Siena.
Lavoro con queste tecnologie dal 2006 ed il mio principale campo d'azione è la progettazione e sviluppo di applicazioni di webmapping (WebGIS).
Nutro particolare interesse nei confronti del software libero (geografico e non) e dei suoi impieghi nel monitoraggio biologico ed ambientale.
Sono stato consulente di diverse aziende, dell'Università Politecnica delle Marche e del Parco Nazionale della Majella; attualmente lavoro nel reparto Statistica e GIS dell'IZSA&M. Mi sono unito con grande piacere alla redazione di TANTO nell'Aprile del 2009 :)
I contenuti potrebbero non essere più adeguati ai tempi!
By markux on feb 14, 2011
ottima overview!
giusta la riflessione sui framework, ma openlayers può andare bene se l’applicazione è pubblica e non richiede una struttura di gestione lato server.
pmapper poi è scritto e strutturato molto bene ed è un piacere lavorarci anche facendo modifiche pesanti al suo core. volendo poi si può integrare openlayer con pmapper.
By Luca Casagrande on feb 14, 2011
Complimenti Alessio, professionale come sempre
@makux Ciao, cosa intendi per integrazione OpenLayers e Pmapper? E’ stato fatto qualche lavoro in questa direzione?
By Alessio on feb 14, 2011
Ciao Luca e grazie del commento
@markuk
non ho afferrato pienamente cosa intendi con questa frase: “openlayers può andare bene se l’applicazione è pubblica e non richiede una struttura di gestione lato server”.
OpenLayers è una libreria Javascript e come tale, da sola, ha i limiti di tutte le librerie Javascript. Tuttavia puoi tranquillamente utilizzare un linguaggio di programmazione lato server per far comunicare un client basato su OpenLayers con il db anche senza passare da un mapserver e da i suoi tipici servizi web (WMS, WFS, ecc.).
Ad esempio puoi raccogliere informazioni spaziali dalla mappa tramite OL e darle in pasto a uno script PHP o ad una servlet Java per lanciare una query verso un geodb o quant’altro.
Come scrivevo nel post, le possibilità sono molte e giunti ad un certo punto, sapendo mescolare a dovere gli “ingredienti”, è (quasi) solo questione di fantasia.
PS
Mi associo alla domanda di Luca
By markux on feb 14, 2011
scusate, in effetti non mi sono capito nemmeno io
intendevo che pmapper è un’applicazione completa server-client, mentre openlayer è solo client. Differenza che mi pareva poco evidenziata nell’articolo.
sull’integrazione intendevo utilizzare pmapper come “gateway” tra il server gis e openlayers, ed onestamente conviene utilizzarli separatamente creandosi una propria webapp con openlayers (come diceva @Alessio) o pmapper con le sue.
cmq dipende sempre dalle specifiche del lavoro richiesto.
By Marco Cerruti on feb 15, 2011
Complimenti, mi sono permesso una citazione su FGI
By Luca Casagrande on feb 15, 2011
Anche p.mapper è solo un client e si appoggia a MapScript di UMN MapServer come dice giustamente Alessio. Se prendi il mapfile e abiliti il servizio WMS per ciascun layer, puoi visualizzare gli stessi dati in OpenLayers.
Ciao!
By Pietro Grimaldi on feb 15, 2011
Complimenti per l’articolo,
che chirisce in maniera sintetica punti fondamentali del nuovo modo di conoscere il territorio.
Mi preoccupa la frase “Lungi dall’essere delle applicazioni GIS in senso stretto”, in quanto non riesco a capire il “senso stretto”. Un GIS (inteso come Global Information System e non più solo “geographical information system”) come
http://serracapriola.net
ha la sua validità?
Grazie,
Piero Grimaldi
By Alessio on feb 15, 2011
@Marco Cerruti: grazie, è un piacere
@Pietro Grimaldi: con “applicazioni gis in senso stretto” intendo quelle nate per analizzare e manipolare i dati spaziali vettoriali e raster attraverso algoritmi specifici. Questo vale sia per l’ambiente web che per quello desktop.
Google Maps e simili sono “mappe” (estremamente performanti e con risoluzioni spaziali altissime su larghe aree). Applicazioni come Google Earth, tanto per citarne una con una forte integrazione con il desktop, sono utilissime in molte situazioni ma le vedo ancora come strumenti accessori in un ambito professionale dove oltre alla necessità di localizzazione si ha anche quella di elaborazione ed analisi.
Ciao
By Francesca on feb 16, 2011
Se si parla di webmapping e di standard Mi permetto di segnalare il Geoportale (http://www.geoportale.it/) un’ iniziativa avviata da Planetek per sostenere lo sviluppo in Italia delle IDT (Infrastrutture di Dati Territoriali). Si tratta di’ un prototipo di IDT in grado di accogliere nel proprio catalogo i metadati di tutti coloro che vogliano condividere le proprie basi informative spaziali.
Buon lavoro a tutti
By Pietro Grimaldi on feb 16, 2011
Mi sembra molto strano definire “mappe” rappresentazioni digitali e georeferite (anche se affette da errori sistematici). Inoltre desidero far notare che con le API e i Tools di Google è possibile costruirsi strumenti di analisi oltrtemodo sufficienti per operazioni di “elaborazione ed analisi” per lo studio del territorio.
Ricordo il mio motto: “… un buon rilievo è già metà progetto!!!”
In realtà il problema, in particolar modo in Italia, è abituarsi all’utilizzo delle “nuove tecnologie” senza preconcetti: purtroppo abbiamo una nuova serie di “predicatori” definibili “cavernicoli del 2000″.
Grazie,
Piero Grimaldi
By Alessio on feb 16, 2011
E’ ovvio che se estendiamo il discorso alle molte ottime API e strumenti messi a disposizione da Google (e non solo), le considerazioni da fare aumentano, ma ritengo che sia una discussione che esula dall’argomento trattato. Diverse vole, qui su TANTO, abbiamo parlato (e parleremo) di cose come quelle a cui ti riferisci.
Nel post ho menzionato applicazioni come Google Maps per evidenziare la spinta che – secondo me – hanno dato, insieme ad altri fattori, alla crescita della consapevolezza dell’utilità di diffondere l’informazione geografica in maniera rapida e fruibile.
Però *Google Maps* per me non è un GIS, ma un’applicazione web che consente a chiunque di esplorare quelle che vengono comunemente e, se vuoi, impropriamente, spesso definite “mappe”.
By Alessio Di Lorenzo on feb 16, 2011
@Francesca: grazie della segnalazione
By Luca Casagrande on feb 17, 2011
Penso che l’ambito web possa difficilmente considerarsi adatto a svolgere le operazioni di analisi che tipicamente si fanno con gli applicativi Desktop GIS.
Fatta esclusione per semplici strumenti che calcolano percorsi più brevi, buffer o visibilità, l’ambito webmapping si limita alla visualizzazione e consultazione del dato.
A questo si può aggiungere anche che spesso (se non sempre) per l’elaborazione l’utente ha bisogno dei propri dati e per questo subentrano situazioni tecnologiche più complesse.
Tutto si fa (son quasi 4 anni che lavoro con lo standard WPS), ma conviene davvero o diventa un semplice esercizio di stile?
Personalmente vedo l’aspetto innovativo in progetti come GeoNode che offrono sistemi dinamici per la creazione e condivisione di mappe.
By Alessio on feb 17, 2011
Luca, concordo.
Spesso capita che chi commissiona un lavoro chieda “l’esercizio di stile” perché non ha idea di quali siano i limiti di alcune tecnologie e le possibilità di altre.
Sta a noi suggerire le soluzioni giuste per ogni esigenza… nella speranza di essere ascoltati ovviamente
By Andrea D on mar 22, 2011
Alessio,
volendo partire dal basso con un DB come PostGIS, con un punto fermo che è Open Layers per Client, quale map server consiglieresti considerando che avrò la necessità di estenderne le funzionalità per integrare dati provenienti da risorse esterne al DB spaziale (RSS,web service, etc).
Grazie e complimenti a te e a tutto il gruppo
By Alessio Di Lorenzo on mar 22, 2011
Ciao Andrea,
grazie del commento e dei complimenti a TANTO. Nel tuo caso direi che umn-mapserver e geoserver sono entrambi indicati. Personalmente ho lavorato di più con umn-mapserver, lo trovo leggermente più flessibile. Per il resto, non mi preoccuperei più di tanto delle risorse esterne: openlayers è in grado benissimo di maneggiare da solo georss, json, gml, ecc.
Ciao
By Italo on mar 27, 2011
Mah! Non riesco ancora a capire perchè si dica che Google Maps non è un gis … Eccome se lo è. E direi che è anche il più bello di tutti.
Ha l’unica (e non trascurabile) pecca che non è del tutto opensource (come magari Openlayers). O meglio lo sarà fino a quando Google vorrà farlo essere (ed alle sue condizioni).
Sono anni che mi occupo di applicazioni gis … e tra le tante altre, cose come quelle sottolinkate sono riuscito a farle solo con google maps api …
http://www.italomairo.com/Italo_Mairo_personal_web_site/WebGIS_Aziende_ER_ita.html
http://www.italomairo.com/Italo_Mairo_personal_web_site/WebGIS_APEA_ER_ita.html
anche se sicuramente anche con Openlayers ci sarei riuscito, in parte. La personalizzazione dei markers e di tante altre cose a sensazione penso mi avrebbe creato molte maggiori tribolazioni.
PS: Complimenti a tutti … questà è la community di riferimento!
By Antonio Falciano on mar 27, 2011
Un conto è parlare di webmapping, un altro di webGIS. Google Maps rientra nella prima categoria, in quanto così com’è ti consente esclusivamente di consultare una mappa, farci qualche ricerca e nulla di più (a patto di non affiancarci altri strumenti/codice vicino). I webGIS – GIS in ambiente web – dovrebbero invece essere in grado di realizzare analisi spaziali più o meno complesse (v. servizi WPS), ovvero quelle operazioni che in genere sei perfettamente in grado di realizzare in ambiente desktop. Per questo Google Maps non è un (web)GIS, nell’accezione più stretta del termine. Ciao.
By Italo Mairo on mar 27, 2011
il ragionamento non fa una piega,
ma mi sembra l’approccio tradizionale ed ormai un tantinello datato.
Che i Gis tradizionali (Arcis, QuantumGis, ecc.) siano GIS non è da dubitare.
Ma ormai parlare di Webmapping può coincidere con l’implementazione del Gis stesso … in quanto una applicazione web (cartografic è perfettamente in grado di implementare anche qualsiasi tipo di analisi spaziale. Certo. E’ necessario definire degli algoritmi ed implementare del codice ad hoc (o prenderlo da altrove se già fatto), lato server o lato client che sia … Ma alla fine il risultato è anche quello.
Con l’ulteriore indubbio vantaggio di non dover più tanto distinguere l’interfaccia web da quella desktop. Può davvero bastare quella web … implementando l’ambiente di back end per l’amministrazione dei dati e dei parametri di configurazione e funzionamento dell’applicazione. Qualsiasi parametro e funzonamento …
Come facile e pratico esempio provare a consultare la seguente scheda:
http://atlante.ervet.it/apa/detail_page.php?codice=03701
e focalizzare ad esempio l’attenzione sul grafico a torta, che tra l’altro via ajax si aggiorna in tempo reale pannando e zoomando sulla (google)map …
Certo, si tratta di una rappresentazione dinamica di dati (webmapping), ma difficile sostenere che non sia un’analisi spaziale in tempo reale, di un qualcosa che serviva a quello scopo. Ed a quello specifico scopo è stato scriptato …
E volendo ci si metterebbe poco ad implementare una funzione per esportare i risultati, in ogni istante, nel formato desiderato (excel, xml, json, ecc.)
Più Gis di così … ! O sbaglio comunque?
By Alessio on mar 27, 2011
Ciao Italo,
“tradizionale” e “datato” Antonio Falciano? No dai, non scherziamo
Parlare di webmapping e webgis significa parlare di cose piuttosto diverse e la distinzione è proprio quella spiegata da Antionio.
Nel punto in cui tu scrivi:
in quanto una applicazione web (cartografic è perfettamente in grado di implementare anche qualsiasi tipo di analisi spaziale. Certo. E’ necessario definire degli algoritmi ed implementare del codice ad hoc
stai già ipotizzando di andare oltre Google Maps e quindi confermi quanto dice Antonio nel suo precedente intervento:
Google Maps rientra nella prima categoria, in quanto così com’è ti consente esclusivamente di consultare una mappa, farci qualche ricerca e nulla di più (a patto di non affiancarci altri strumenti/codice vicino)
Per quanto mi riguarda non posso che sottoscrivere questa affermazione. Di applicazioni (sia webgis che di webmapping) ne ho sfornate parecchie ed ho lavorato molto anche con le API di Google Maps, però se devi andare oltre la semplice navigazione/presentazione dei dati le sole API client non bastano più.
By Luca Casagrande on mar 27, 2011
Concordo completamente con Antonio.
Finché si lavorerà unicamente nella visualizzazione dei dati, avremo solamente applicazioni che forniscono dati georiferiti.
Poi possiamo condirli in mille modi e con mille soluzioni tecnologiche, ma la sostanza resta la stessa.
Solo quando avremo strumenti web che permettano all’utente di integrare i dati forniti con i propri e di eseguire elaborazioni non prestabilite, potremo iniziare a parlare di sistemi webgis.
Ciao
Luca
By Italo Mairo on mar 27, 2011
Ma no, ma no …
non mettetemi in bocca cose che non ho detto.
Antonio Falciano non ho il piacere di conoscerlo (purtroppo) ed approfonditamente per affermare che sia “datato” … ci mancherebbe.
Probabilmente è anche + giovane di me
Poi scrive qui su Tanto e solo questo lo pone nella categoria esattamente opposta …
Per il resto non mi contrappongo, ma esprimo solo delle mie opinioni.
C’è questo che fa questo, c’è quell’altro che fa quello, ma lo fa solo se e solo se, e questo in salsa rosa e quell’altro in salsa verde …
Basta poi fermarsi e pensarci un attimo, al significato stesso dell’acronimo GIS … puro e semplice,
per inevitabilmente dover ammettere che sempre di sistemi/informativi geografici si tratta. Punto …
Ed in fondo meglio così, che così ognuno è libero di poter utilizzare ciò che meglio crede, e fregiarsi del suddetto acronimo a buon diritto, comunque e come crede.
Bon nuit!
By Alessio on mar 28, 2011
Provo a sintetizzare: se vogliamo chiamare software GIS qualsiasi sistema in grado di mostrare una mappa, allora sì, anche Google Maps così com’è può essere definito tale. Però mi sembra una definizione veramente troppo vaga.
Ci sarebbe poi un’altra cosa da precisare. Ho notato che nel tuo primo commento, Italo, scrivi che Google Maps “non è del tutto open source”. Google Maps è gratuito, ma non è open-source: non hai accesso al suo codice sorgente. Il software libero non è tale in quanto “gratuito”. La gratuità, che nel caso di Google Maps, tra l’altro, è subordinata all’uso che se ne farà (esistono infatti casi in cui è necessaria una licenza premier, che si paga a volume di traffico generato se non sbaglio [1]), è una condizione che non è sufficiente né necessaria per definire qualcosa come “software libero”
[1] http://www.google.com/enterprise/earthmaps/maps_features.html
By Italo Mairo on mar 28, 2011
vabbè sottoscrivo (ed alzo bandiera bianca) …Gmap non è ne GIS ne opensource. Me ne farò una ragione, e continuerò a goderne come tale
Sempre contento che esiste e che se lo sono inventato, visto che altrimenti il termine stesso GIS e ste discussioni sarebbero state solo per strettissimi esperti ed addetti ai lavori. Invece magari adesso riusciamo a coinvolgere ed incuriosire (e divertire) un pubblico ben più ampio …
By Andrea Borruso on mag 16, 2012
Caro Ale,
oggi ho trovato un altro bel post a tema:
http://macwright.org/2012/05/15/how-web-maps-work.html
Penso che sia utile lasciarne traccia anche qua.
Un abbraccio