Archivio del mese di agosto, 2009

30 agosto, 2009 | di

A Novembre si terrà a Bolzano la “Seconda Conferenza Italiana sul Software Geografico Libero“.

Nei giorni 11 e 12 novembre 2009 si terrà a Bolzano la Seconda Conferenza Italiana sul Software Geografico Libero.

L’evento costituirà un appuntamento ideale per aziende, professionisti e pubbliche amministrazioni di tutta Italia attive sia nel settore del Software Libero Geografico, che di soggetti che desiderano avvicinarsi ad esso.

Durante la Conferenza sono previsti workshop, sessioni di presentazioni tematiche ed eventi paralleli a carattere applicativo, divulgativo e di sviluppo.

Per chi fosse interessato a proporre argomenti per le presentazioni, segnaliamo sin da ora che il termine per l’invio degli abstract è il 15-9-2009.

Seguiranno inoltre a breve indicazioni relative all’iscrizione agli workshop e ad altri aspetti organizzativi.

È possibile consultare le informazioni più aggiornate relative all’evento alla pagina http://www.gfoss.it/drupal/gfossday

La conferenza è organizzata dall’Associazione italiana per l’informazione geografica libera (GFOSS.it) in collaborazione con R3 GIS, Hydrologis, Free Software Center e Provincia Autonoma di Bolzano (Ufficio Coordinamento Territoriale) e si terrà al TIS – Techno Innovation Park di Bolzano.
Il giorno 13 Novembre si terrà nella stessa sede la Free Software Conference dell’Alto Adige, appuntamento annuale sul tema dei software liberi.

26 agosto, 2009 | di

E’ recentissima l’edizione 2009 dell’Atlante di geografia statistica e amministrativa pubblicato dal’ISTAT, che aggiorna il loro precedente lavoro realizzato nell’ormai lontano 1997.

Come lo stesso Istituto fa presente nell’introduzione, il lavoro ha come obiettivo essenzialmente quello di compendiare svariati dati di carattere amministrativo. Ma un altro passaggio degli editori, che mi ha positivamente colpito, mette in evidenza il ruolo della “geografia amministrativa”, che ha come scopo soprattutto quello di analizzare la suddivisione geografica dei soggetti pubblici che hanno competenze territoriali, e valutare l’efficacia della loro articolazione.

Per ribadire l’importanza e la necessità di un approccio “geografico” alle realtà amministrative, mi piace richiamare l’illuminante articolo sulla Geografia Giudiziaria di Gerlando Gibilaro che ne ha poi ispirato uno di Andrea Borruso. E’ stata una reazione a catena, e anche io mi son poi fatto prendere dall’entusiasmo creando una mappa sul costo delle Prefetture italiane, a mia volta ispirato da un articolo de Lavoce.info proprio sulla questione riorganizzazione delle amministrazioni nel nostro Paese.

Il volume è organizzato in otto capitoli che descrivono:

  • Caratteristiche del territorio (zone altimetriche, classificazione dei Comuni secondo l’altitudine, il grado di urbanizzazione, gli agglomerati morfologici urbani).
  • Unità amministrative (circoscrizioni comunali, comunità montane, comunità isolane).
  • Unità funzionali: area economica (Direzioni regionali e provinciali del lavoro, Camere di Commercio, Centri per l’impiego, Agenzia del Demanio, Agenzia delle Entrate, Agenzia del Territorio, Agenzia delle Dogane, Distretti Industriali, Aree obiettivo UE).
  • Unità funzionali: area istruzione, turismo, cultura e servizi sanitari (Uffici Scolastici Regionali e Provinciali, Circoscrizioni turistiche, Dir. regionali beni culturali e paesaggistici, Soprintendenze beni AA, ASL)
  • Unità funzionali: area ambiente, trasporti e reti (ARPA/APPA, ATO, Aree naturali protette, CFS, Compartimenti ANAS, Compartimenti rete ferroviaria, ENAC, CAP, Distretti telefonici).
  • Unità funzionali: area difesa, sicurezza, giustizia (Questure, CC, GdF, Capitanerie di porto, VVFF, Corti d’appello, Tribunale ordinario, Giudici di pace).
  • Unità statistiche (Nomenclatura delle unità territoriali per le statistiche, Sistemi locali del lavoro, Specializzazione produttiva prevalente dei sistemi locali del lavoro, Distretti industriali).
  • Altre partizioni (Diocesi, Regioni ecclesiastiche).

Per ciascuna entità amministrativa viene descritta l’organizzazione dell’ente e le sue principali funzioni. Per ognuna di esse viene messo a disposizione uno shapefile (UTM 32 WGS84) e un file Excel con riportate informazioni descrittive minime. Gli strati geografici – come spiega lo stesso ISTAT – sono stati realizzati partendo dai confini amministrativi dei Comuni, aggregati con operazioni topologiche di dissolve a seconda dell’organizzazione territoriale di ogni entità presente nell’atlante.

La reale importanza della pubblicazione è sostanzialmente quella di raccoglie in maniera sistematica informazioni di carattere amministrativo relative a numerosi soggetti pubblici difficilmente reperibili altrove da fonti ufficiali.

Mancano d’altro canto, per ciascuna di esse, dati di tipo quantitativo che avrebbero costituito il vero valore aggiunto dell’atlante, come ad esempio il numero di scuole, di docenti e di alunni afferenti a USR e USP, il numero di poliziotti in carico alle Questure, o quello dei Carabinieri a Tenenze e Stazioni. Informazioni che avrebbero potuto costituire la base di dati necessaria per poter fare proprio quel lavoro di analisi dell’efficacia, del dimensionamento e dell’articolazione dei soggetti e degli operatori pubblici di cui si parlava prima. Fare geografia amministrativa è ancora difficile in Italia, perchè spesso i dati vanno aggregati ad hoc, ma questo atlante è già un importante passo avanti.

Ah, dimenticavo… rimane come al solito il problema della licenza di utilizzo di questi dati. La dicitura in quinta pagina del volume “Si autorizza la riproduzione a fini non commerciali e con citazione della fonte” è abbastanza chiara, ma per completezza vi invito a leggere con attenzione l’esperienza che hanno avuto gli amici di GFOSS.it sempre con l’ISTAT, sembra comunque positiva.

20 agosto, 2009 | di

Il titolo è buttato lì solo per fare audience, ma piegare bene una mappa non è cosa da poco.

Avete presente quei viaggi in macchina estivi, 40° all’ombra, 5 posti auto occupati, macchina piccola, tanta fame, tanto sale sul corpo? Cercate un luogo che vi sarà di sollievo e subito, voi grandi esperti cartografi, vi mettete a cercare quel famoso agriturismo su una mappa. Il bello è poco dopo, quando volete piegarla (sudata ormai anche lei) e volete farlo con cura, perché il viaggio è ancora lunga ed una mappa di carta è un oggetto prezioso: “la piego ioooo” la mappa, “ci penso ioooo” che faccio GIS, etc..

Io in queste circostanze, mi sono spesso sentito stupido. Raramente sono riuscito a piegare correttamente una carta che già aveva i segni di piega, figurarsi una carta stampata in casa ed ancora non piegata.

rubik_map

Ci viene in aiuto un godibile manuale di dominio pubblico dell’esercito degli Stati Uniti d’America: “Map reading and land navigation“.  L’appendice B si intitola “MAP FOLDING TECHNIQUES” e ci illustra tre tecniche che ci faranno ottenere sia la portabilità di una mappa  (riducendola di dimensioni), che l’usabilità della stessa (non sarà necessario aprirla interamente per leggerla). Qui sotto ne trovate illustrate due (classiche).

due tecniche per piegare una mappa

Il volume è acquistabile su Amazon, ed è leggibile liberamente in html e su Scribd (da cui potrete scaricarlo anche in  PDF).

via  Free Geography Tools

P.S. il cubo di Rubik (mia moglie che è cinefila dice alle volte “di Kubrik” ;-)   ) vettoriale con cui ho “composto” la prima immagine l’ho scaricato da deviantART.

10 agosto, 2009 | di

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.

imagePer 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”.

imageLo 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”.

image 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.

image

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.html

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>.

imageDulcis in fundo… il modulo che genera il vero e proprio GeoRSS… voilà, si tratta di “Location Extractor”.

imageVoi 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.

image

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!!!”.

2 agosto, 2009 | di

esriPosso 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! :D


TANTO non rappresenta una testata giornalistica ai sensi della legge n. 62 del 7.03.2001, in quanto non viene aggiornato con una precisa e determinata periodicita'. Pertanto, in alcun modo puo' considerarsi un prodotto editoriale.