Archivio per la categoria ‘osgeo’

15 luglio, 2009 | di

E’ appena uscito l’OSGeo Journal – Volume 5 – OSGeo 2008 Annual Report,  un volume che illustra le principali attività ed i progressi fatti dal mondo del software open source per la geomatica; viene dato spazio anche ai programmi per il futuro.

E’ un volume che contiene 60 contributi di autori da ogni parte del mondo, che ci illustrano progetti e idee sviluppati con diverse e importanti applicazioni.

Da qui il download e qui sotto lo vedete in anteprima. Buona lettura.

1 luglio, 2009 | di

I miei siti di ispirazione di web-mapping sono diversi. Nella mia top five c’è sicuramente EveryBlock, perché unisce leggibilità, efficacia, eleganza e attenzione alle buone pratiche (non soltanto dal punto di vista tecnologico).

Risponde ad una domanda “necessaria”: cosa avviene attorno a me?

Sono raccolte essenzialmente tre tipi di notizie:

  • Informazione civica — permessi di costruzione, informazioni sulla criminalità, verifiche sui ristoranti, eccetera. In molti casi l’informazione è già sul web ma è dispersa in database dell’amministrazione difficili di individuare. In altri casi l’informazione viene pubblicata per la prima volta in collaborazione con gli enti pubblici.
  • Notizie — dai principali quotidiani, settimanali locali, TV e radio, pubblicazioni e blog. L’informazione viene classificata geograficamente in modo da evidenziare la copertura mediatica di uno specifico rione cittadino.
  • Divertimento — fotografie relative alle zone coperte pubblicate su Flickr, opinioni sulle attività commerciali recensite su Yelp, annunci di oggetti smarriti/ritrovati su Craigslist e altro.

E’ un servizio disponibile soltanto per alcune città degli Stati Uniti. Questo ad esempio l’URL per New York: http://nyc.everyblock.com/

L’interfaccia è raffinata e semplice allo stesso tempo, ed è notevole il numero di informazioni che trovate raccolte. Qui una lista di quelle del quartiere “DUMBO – Vinegar Hill – Downtown Brooklyn – Boerum Hill”.

Di ciascuno di questi report è possibile averne una visualizzazione cartografica e molto spesso anche un grafico che illustra l’andamento della variabile in oggetto (ad esempio la richiesta di rimozioni di graffiti!). Le città sono esplorabili per quartieri e per CAP.

everyblock

Da oggi il codice che sta dietro EveryBlock è rilasciato in opensource, e già sogno di vederlo in azione per realtà a noi più vicine. Questo è quello che ci troverete dentro:

The main package (probably the thing you’re looking for) is the publishing system, known as ebpub.
Second, the packages ebdata and ebgeo contain Python modules for processing data and making maps.
Third, the packages ebinternal and everyblock round out the code that powers EveryBlock.com. They’re internal tools and are likely not of general use, but we’re including them to be complete.
Finally, ebblog and ebwiki are our blog and wiki software, respectively. Because, dammit, the world needs another Django-powered blogging tool.

Il codice è scritto Python sfruttando il framework web Django. Mi piacerebbe potermici sporcare le mani, ma in Python non vado oltre la dichiarazione di una variabile.

Se qualche lettore di TANTO dovesse fare qualche esperimento, ci contatti subito ;-)

Via O’Reilly Radar.

23 giugno, 2009 | di

Ci sono dei prodotti software, sviluppati con una tale costanza da fare quasi paura; sempre lì dietro l’angolo, pronti a farti fare la fine di Gatto Silvestro. Per me tra questi c’è certamente OpenLayers.

Ieri è uscita inesorabilmente la release 2.8 e come sempre tante le novità. Tra queste:

  • selezione multi-layer per oggetti vettoriali
  • renderizzazione di testo per layer vettoriali
  • supporto per il protocollo WFS
  • numerosi nuovi controlli (tra questi sottolineo il comodissimo GetFeatureInfo)
  • 5 nuovi tipi di layer (ArcXML, XYZ, MapGuide, ArcGIS Server data e ka-Map tiles)
  • supporto per lo snap, in fase di disegno vettoriale

La lista completa la trovate qui.

E’ molto piacevole fare la fine di Silvestro. OpenLayers, come il maledetto Speedy, è costante e sempre presente, e non fa sentire mai solo il “povero” sviluppatore di applicazioni di web-mapping. Grazie mille a tutti gli sviluppatori di questa applicazione ormai celebre ed importante.

1 giugno, 2009 | di

Parliamo spesso di dati e geodati su TANTO, specie negli ultimi tempi. Non abbiamo forse mai parlato di cloud computing:

In informatica, con il termine cloud computing si intende un insieme di tecnologie informatiche che permettono l’utilizzo di risorse (storage, CPU) distribuite.

Si tratta di qualcosa nota sicuramente ai più, e con cui abbiamo a che fare ogni giorno navigando per il web: guardando le mappe di google o le foto su Flickr, un filmato su YouTube o un documento su Scribd. Quando accediamo ad uno di questi servizi, e visualizziamo ad esempio un filmato, non accediamo ad un singolo file, archiviato su un solo hard disk, su un unico server. E’ quasi sempre esattemente il contrario, diverse copie del file, archiviate su numerosi hard disk residenti su molti server.
In realtà è tutto molto più raffinato e spesso non si tratta nemmeno di server “veri”, ma virtuali e distribuiti. E’ un’esigenza sempre più sentita con l’aumentare delle dimensioni dei dati ed il diffondersi di applicazioni “remote”, non installate sul nostro pc.

IBM, Amazon, Google, Microsoft e Yahoo sono tra i più grossi fornitori di servizi di cloud computing. Chi non segue questo mondo, troverà strano trovare Amazon in questo elenco: “Ma non vendono libri???”
Al contrario, chi lo fa, sa che Amazon offre da tempo questi servizi, e con grande qualità.

Quello che io non sapevo era che, oltre ad offrire servizi per realizzare applicazioni di cloud computing, avesse un catalogo di dati pubblici da utilizzare all’interno delle loro applicazioni, e che tra questi ci fosse l’intero catalogo dei dati TIGER degli Stati Uniti. 140 GB di geodati già pubblici (limiti amministrativi, strade, fiumi, costruzioni, etc.) in formato shapefile, che sono anche la base di OpenStreetMap negli USA, accessibili come un disco fisso virtuale, tramite un server virtuale. Tutto chiaro? Non credo, devo aggiungere qualche altro dettaglio.

Il servizio di Amazon per attivare questo disco virtuale di dati si chiama Elastic Block Store (EBS). EBS consente di creare volumi da 1 GB ad 1 TB che possono essere montati (a cui accedere) da un’instanza di un altro servizio fornito da Amazon: Amazon Elastic Compute Cloud (Amazon EC2). Se EBS è un disco virtuale, EC2 è un server virtuale (Linux, Windows e OpenSolaris).  In questo modo potrò sviluppare su un server di mia scelta e comodamente, la mia applicazione di webmapping. “Virtualmente” dal punto di vista dell’implementazione tecnologica, ma con molta sostanza nell’erogazione del servizio.

Il servizio non è gratuito, ma sono soldi ben spesi, specie per progetti di grosse dimensioni: risparmierete costi interni e fronteggerete con tranquillità inaspettati successi della vostra applicazione, ed il conseguente “carico” sui vostri server. Non è un servizio “per tutti”, e richiede più di una buona preparazione di base da sistemista.

Detto di questi due “difetti”, io sono rimasto molto colpito dalle opportunità che queste tecnologie e questa “mentalità” potrebbero dare ad esempio a chi sviluppa grosse (e non) applicazioni spaziali sul web. Il condizionale è legato essenzialmente ai geodati: in Italia non esistono ancora dati di dominio pubblico della stessa qualità e con la stessa copertura dei dati TIGER. Il male è che non esistano in generale; non è infatti  così importante che non ci siano dati italiani tra i dati pubblici disponibili su Amazon. Se ci fossero, basterebbe soltanto avere delle buone idee ed una buona preparazione, ma non ci sono ed in qualche modo abbiamo un po’ le ali tarpate. Mi fermo con la predica.

Chiudo segnalandovi due video che introducono al mondo del cloud computing:

via Institute for Analytic Journalism

13 aprile, 2009 | di

Gli eventi abruzzesi mi hanno toccato molto. Non poteva essere diversamente.

Sono un geologo e mi occupo di sistemi informativi geografici; posso dare un piccolo aiuto anche io, sfruttando le mie attitudini e le mie competenze?
Per giorni non ho trovato la risposta, poi mi contatta in chat Alessio Di Lorenzo, un amico biologo abruzzese e curatore  del portale cartografico del Parco Nazionale della Majella, e mi chiede se conosco una fonte da cui estrapolare dei dati sugli eventi sismici di questi giorni. Li vuole elaborare e trasformare in una sorgente geoRSS, prendendo spunto proprio da quanto abbiamo scritto qui. Inizialmente la cosa mi ha fatto piacere, ma non mi ha stimolato nulla. In seguito,  aprendo l’URL che gli ho inviato, quello del Centro Nazionale Terremoti dell’Istituto Nazionale di Geofisica e Vulcanologia, qualcosa mi ha fatto “click” in testa. Ma “poco poco, piano piano”.

Mi sono passati davanti agli occhi, i dati sismici pubblicati in questi giorni. Quelli “ufficiali”, quelli presentati dai giornali online di tutto il mondo, quelli sui blog. Alcuni sono caratterizzati da piccole grandi carenze, potenzialmente superabili con poco sforzo, ma con origini che sono profonde.

Tim Berners-Lee, uno degli “inventori” del World Wide Web, ha presentato nello scorso Febbraio una relazione orale sul futuro del Web (grazie a Stefano Costa per la segnalazione). E’ visibile in diversi siti, e gli dovreste dedicare 15 minuti del vostro tempo (se la guardate qui ci sono i sottotitoli, ha un inglese “difficile”), qualsiasi mestiere facciate.  In quella sede ha lanciato uno slogan: “raw data now“, letteralmente “dati grezzi ora”. Ha invitato il “mondo”, gli enti pubblici e quelli privati, a “liberare” i propri dati e creare i presupposti affinché questi possano essere accessibili e mescolati tra loro. Ha invitato inoltre tutti noi a stimolare chi detiene dati, a muoversi in questo senso; senza la condivisione, questi perdono quasi del tutto la loro qualità.

Berners-Lee individua tre regole:

  1. deve bastare un semplice indirizzo web, un URL, per puntare ad un dato
  2. chiunque abbia accesso a quell’URL, deve poter scaricare i dati in qualche formato standard
  3. devono essere descritte le relazioni tra i dati (Andrea è nato a Palermo, Palermo è in Italia, etc.), e queste relazioni devono essere espresse ancora una volta tramite un’URL

Questo sarà il web 3.0, basato sui dati e (si spera) sulle relazioni semantiche tra gli stessi. Ma torniamo ai dati sismici sul nostro paese. Rispettano queste tre regole?

Questa non sarà una critica al CNR ed all’INGV. Leggo sul loro sito, che gran parte dei dati da loro pubblicati in questo contesto, sono affidati (ancora una volta) al volontariato. A molti dipendenti infatti sembra non sia stato rinnovato il contratto. Non conosco questa situazione, ma è molto triste anche soltanto immaginare che una funzione di questo tipo possa essere “relegata” a semplici attività di volontariato.
Quello dei dati sismici è per me solo uno spunto, ed il discorso va allargato a tutti i contesti in cui esistano dei dati pubblicati in modalità poco efficienti (o addirittura non pubblicati).

Il formato in cui sono accessibili gran parte dei dati sismici è il CSV :

è un formato di file basato su file di testo utilizzato per l’importazione ed esportazione (ad esempio da fogli elettronici o database) di una tabella di dati.  Non esiste uno standard formale che lo definisca, ma solo alcune prassi più o meno consolidate.

Un esempio pratico è quello delle date, espresso in alcuni file dell’INGV in questo formato YYYY/MM/DD (2009/04/13). Aprendo uno di questi file con un foglio elettronico, il campo “data” verrà quasi sicuramente interpretato in automatico ed adattato alle impostazioni “locali” del vostro PC. Su molti PC italiani, sarà infatti forzato questo formato: DD/MM/YYYY (13/04/2009). E’ la stessa data? Sembra di si. Ma se iniziassimo a scambiare questi dati con colleghi, che usano un semplice blocco note per aprire il file CSV (senza quindi che i dati siano “trasformati”), o che vivono in un altro paese (quindi con un’impostazione locale differente), in quanto tempo ne perderemmo l’integrità?
Usando degli standard, ad esempio per le date l’ISO 8601 , riusciremo a dare ai nostri dati una vita più lunga ed anche una “platea” molto più estesa.

Altre volte i dati sono pubblicati come tabelle HTML. Avete mai provato a fare copia ed incolla di una tabella, da una pagina web ad un foglio elettronico? Molte volte se ne esce con le ossa rotte.
E’ giusto pubblicare i dati in html, ma dovremmo sempre fornire anche altre possibilità. Il servizio geologico americano (“so forti li americani”), lo USGS, pubblica da tanti anni un catalogo di eventi sismici in tre formati: KML (il formato di Google Earth che è ormai uno standard OGC), CSV ed XML (geoRSS). E’ una scelta che mi sembra cristallina. Si conciliano infatti formati adatti ad un’immediata divulgazione, con un formato RAW (come direbbe Tim Berners-Lee).  Il file KML e quello XML consentono ai dati di essere interpretati correttamente da una macchina e di essere “mescolati” più facilmente con altri provenienti da altri pc, scritti con altri software e  prodotti da altri gruppi di lavoro. Questa opportunità è un aspetto molto importante, in quanto l’incrocio di dati diversi spesso fa saltare agli occhi significati inaspettati; a costo di essere noioso, se non definisco i miei dati in un formato standard, sarà difficile riuscire a correlarli “immediatamente” con altri. L’INGV si sta muovendo sullo stesso solco, e in questa pagina troverete i dati degli eventi sismici degli ultimi 90 giorni sia informato CSV, che KML. Ma troverete anche questo avviso:

Le informazioni contenute in queste pagine sono state sinora garantite dalla disponibilità del personale, precario e non dell’Istituto Nazionale di Geofisica e Vulcanologia. L’agitazione del personale dell’Istituto contro l’emendamento 37bis alla proposta di legge 1441 quater, che in sostanza provocherebbe il quasi immediato licenziamento del personale precario, porterà alla sospensione di tutte le attività. Nell’immediato si procederà al blocco di ogni tipo di informazione telematica e telefonica non istituzionale.

Ma torniamo un attimo alle tre regole di sopra. La prima può sembrare meno importante, ma nasconde nella sua semplicità di formulazione un grande potere (sembra Spiderman).
Usiamo ogni giorno gli indirizzi http, gli URL. Li usiamo in modo naturale e spontaneo, senza chiederci cosa siano, su cosa si basino e come funzionino. E non c’è nulla di male.
Quando cambio canale della mia TV con un telecomando, non devo avere alcuna nozione sulla trasmissione dell’infrarosso; devo soltanto saper che devo usare un determinato tasto. Se prendo il telecomando del mio nuovo stereo, mi viene naturale utilizzarlo allo stesso modo. Così per il lettore DVD e per la mia pompa di calore (dite che questa è una forzatura?).
Anche accedere a diversi tipi di dati, di diversa origine, dovrà essere una cosa così semplice e “spontanea”. Con lo stesso protocollo, l’http, non più accedere “soltanto” a pagine web ma anche a fonti di dati grezze.

Quello che gli eventi abruzzesi mi hanno stimolato, come uomo e come professionista, è l’attenzione alla politica della gestione dei dati. Le classi dirigenti del nostro paese dovrebbero allinearsi a quanto esposto da Tim Berners-Lee. Sia perché il cittadino possa essere informato, sia per dare forza e valore ai dati, i quali se chiusi in un hd o divulgati in modo inappropriato rischiano di essere inutili e di produrre uno spreco (non soltanto economico).
Dobbiamo tenere alta l’attenzione verso questi temi.

I fatti di questi giorni, il dialogo con i colleghi di TANTO, l’indiretto stimolo di Alessio, i post di altri blogger, mi hanno spinto anche a provare a realizzare una piccola cosa concreta, proprio a partire dai dati sismici della regione Abruzzo.
Si tratta di qualcosa che a prima vista è confrontabile alle interfacce di webmapping basate su Google Maps, in cui in coincidenza della posizione di ogni evento sismico è raffigurato un “pallino”. Quello che ho provato ad aggiungere è la possibilità di modificare e “mescolare” i criteri di visualizzazione del dato: a partire dalla serie di dati che ho estratto, poter visualizzare ad esempio soltanto gli eventi sismici di Marzo, di magnitudo maggiore di 4, di profondità compresa tra 5 e 10 km e del distretto sismico del “Gran Sasso”. L’utilizzo di questi filtri mi ha dato (da utente) la sensazione di potere leggere “meglio” i dati; spero che non dipenda dall’emotività con cui ho lavorato su questo piccolo progetto.
Ho aggiunto anche una timeline, che da la possibilità di passare dalla visualizzazione degli eventi in scala spaziale, ad una efficacissima in scala temporale. Anche qui potrete usare gli stessi filtri.
C’è una visualizzazione tabellare “dinamica” in HTML, ordinabile usando qualsiasi delle colonne presenti, ed anche questa “sensibile” ad i filtri.
Infine i dati sono esportabili in diversi formati, tra i quali: RDF/XML, Semantic wikitext, Tab Separated Values. Per attivare l’export basta andare con il mouse alla sinistra del modulo “Cerca”, e cliccare sull’icona a forma di forbice che verrà visualizzata (vedi figura).
Purtroppo ho riscontrato un problema con l’export nel formato a cui tenevo di più – RDF/XML – ma spero di risolverlo nei prossimi giorni (è un piccolo autogol ;-) ).

L’interfaccia sviluppata ha però un vero grande difetto (e magari non sarà l’unico): non si aggiornerà in automatico, ogni volta che verranno pubblicati nuovi dati dall’INGV. Questo perché sono partito dai quelli pubblicati qui (una tabella HTML), e non da quelli in CSV o KML. Nei prossimi giorni proverò a partire da quelli in CSV, darli in pasto a Yahoo! Pipes ed automatizzare il processo di pubblicazione.

L’applicazione è visibile qui, e qui sotto vedete uno screenshot della timeline.

E’ realizzata con Exhibit, e ci scriverò a breve un tutorial di dettaglio. In questo post volevo “fare” altro.

Chiudo dando la disponibilità di collaborazione mia e dei miei colleghi, a chiunque ritenga che le nostre competenze possano essere d’aiuto in questo momento.

Un abbraccio forte a tutti quelli che stanno vivendo questo terribile momento; uomini, donne e bambini con una compostezza ed una dignità fuori dal comune.

Sopra le nuvole c’è il sereno” diceva Endrigo in una meravigliosa canzone  “d’amore”.


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.