L’Osservatorio Carburanti, introdotto con una legge del 2009 (art. 51, legge 99/2009), vuole essere uno strumento di trasparenza e garanzia della concorrenza tutelato e gestito dal Ministero dello Sviluppo Economico. Dal 2013 é obbligatorio per tutti i distributori sul territorio italiano comunicare e tenere aggiornati i prezzi praticati sul portale ministeriale (https://carburanti.mise.gov.it/OssPrezziSearch/): il decreto ministeriale del 15 Ottobre 2010 prescrive l’obbligo di comunicare il prezzo iniziale, il ritocco dei prezzi al rialzo e comunque un aggiornamento ogni 8 giorni dall’ultima comunicazione, e suggerisce una serie di dati da trasmettere su base volontaria. Le sanzioni previste dalla legge, convertite in euro, variano tra 516 e 3098 euro.

La comunicazione al Ministero avviene in tre modi:

  • tramite portale web
  • tramite sistemi convenzionati (gestiti dai concessionari autostradali o da imprese accreditate)
  • tramite gestionali conformi alle specifiche ministeriali

Lato consumatore si dovrebbero aprire enormi possibilità per il monitoraggio dell’andamento dei prezzi e quindi del rispetto della concorrenza, poiché diventa sufficiente avere accesso alla rete per poter avere informazioni puntuali sui prezzi praticati dalle stazioni di rifornimento. Il mercato è attualmente composto dal portale ministeriale e dalle applicazioni create dalle imprese accreditate: il ministero tramite Infocamere contribuisce con OsservaPrezzi, una sorta di applicazione demo che mostra il potenziale di questo dataset  (2.6 valutazione media sul Play Store), mentre tra le varie proposte permane ancora la storica PrezziBenzina (4.4 valutazione media sul Play Store).

La domanda che ci siamo posti quando abbiamo iniziato l’analisi del portale è la seguente: se il database dei prezzi è nato a garanzia di trasparenza e concorrenza, perché la piattaforma non prevede ancora il rispetto dei criteri stabiliti ad esempio dall’Agenda Digitale italiana? Possiamo fare qualcosa per contribuire al suo miglioramento?

La prima azione compiuta è stata l’analisi di come funziona dietro le quinte il portale del MiSE: con sommo piacere questo è costruito con tecnologie web al passo coi tempi ed il frontend (il “lato utente”) utilizza il framework Bootstrap. Questo teoricamente potrebbe garantire la navigabilità da piattaforme mobili, ma evidentemente si è lasciato che l’utente trovasse necessario l’utilizzo delle app.
L’API che fa dialogare la parte utente con il server è stata esplorata facilmente, permettendo perfino di documentarla parzialmente: l’unica azione per rendere il servizio disponibile in chiaro alla comunità sarebbe documentare le modalità di interrogazione e fornire l’accesso tramite chiavi agli sviluppatori interessati.

L’azione successiva si è svolta su due fronti: il primo è stato provare a fornire servizi utente facilmente fruibili, mentre il secondo è stato ricavare un dump completo del database in un dato momento per permetterne l’analisi a mo’ di big data.

Se l’API fosse ufficiale sarebbe utile che fornisse anche metodi per utilizzare i dati direttamente via JavaScript (JSONP) ma, purtroppo, ciò non è possibile al momento: si è reso necessario creare un ‘proxy’ fra i nostri esperimenti ed il servizio trasformando le nostre richieste da GET a POST via PHP, superando contemporaneamente le limitazioni di sicurezza che i nostri browser mettono in atto nei confronti delle richieste a domini diversi (cross-domain).
L’endpoint position, ad esempio, permette di ottenere tutti i distributori nell’intorno di un dato punto per un raggio di 10 chilometri: l’applicazione contenuta nella pagina distributori.html permette di consultare su mappa tutti i distributori intorno alla posizione scelta dall’utente (via doppio clic o tramite geolocalizzazione), mentre quella della pagina cheap.html evidenzia il distributore più conveniente nella stessa area.

TrovaPrezzi Benzina

Il dump ottenuto tramite simulazione delle richieste all’API copre tutti i distributori disponibili e viene trasformato in automatico dalla risposta JSON ad un database costituito di due parti: una tabella raccoglie la descrizione del distributore (marca, posizione, indirizzo,…), mentre l’altra raccoglie i prezzi di ognuno di essi. Le due tabelle sono legate tra loro da un identificatore trovato all’interno della risposta (il quale andrebbe a sua volta standardizzato e reso ufficiale per permettere incroci con altre basi di dati). Questo database è reso disponibile sia come file SQLITE sia come file SPATIALITE: quest’ultimo viene anche purificato dei distributori con coordinate non valide e può essere utilizzato per analisi spaziali con Qgis.

Noi continueremo ad estrarre informazione e valutarla per mostrare cosa può significare la disponibilità aperta dei dati: più persone ci saranno a consultare ed utilizzare i dati dell’Osservatorio, maggiore trasparenza ci sarà nella gestione e nel monitoraggio del mercato dei carburanti. I segnali che provengono ci fanno credere di stare seguendo una strada giusta e con pochi accorgimenti in una fase futura di apertura tutti ne potranno trarre beneficio.

Il repository GitHub è localizzato all’indirizzo https://github.com/sabas/carburantiMiSE; l’istanza corrispondente, dalla quale scaricare anche i dump più recenti, è all’indirizzo http://toolserver.openstreetmap.it/carburantiMiSE/


italy_in_inspire_registry.png

Ben 4 mesi fa chiedevamo una cosa dovuta e utile: che anche l’Italia fosse presente nel registro INSPIRE.

Non è cambiato nulla e questo incomprensibile stallo non è stato ancora superato. Ma c’è una novità e vi chiediamo di darci una mano a sostenerla e diffonderla.

La notizia di questa carenza di attuazione della normativa è arrivata a un gruppo di parlamentari (trasversale allo schieramento politico) interessato/competente sulle tematiche dell’innovazione tecnologica. L’onorevole De Lorenzis l’ha fatta sua e ha redatto questa interrogazione parlamentare, in cui chiede al Ministro dell’ambiente e della tutela del territorio e del mare “quali iniziative intenda assumere al fine di ottemperare all’obbligo di implementazione e integrazione nel portale europeo dei servizi descritti in premessa come richiesto dalla direttiva Inspire e dal relativo decreto di recepimento della stessa”.

La recente campagna affinché l’Agenzia delle Entrate facesse quanto dovuto nei confronti della comunità OpenStreetMap, ha tra i tanti pregi quella di farci sentire più forti.

Noi scriveremo nei social network:

@minambienteIT @glgalletti vogliamo l’Italia nel registro INSPIRE e vogliamo una risposta http://bit.ly/italy4inspire #italy4INSPIRE

Fatelo con noi!


Le relazioni in QGIS consentono di sviluppare dei casi d’uso applicativi molto interessanti; una delle ragioni del post è quella di contribuire alla diffusione della conoscenza del tema.

Il caso d’uso: le strade e la loro manutenzione

Immaginate di essere i gestori del network della rete stradale della vostra città e di volere utilizzare QGIS (insieme ad altri strumenti) per farlo. Avete quindi un layer cartografico con tutte le strade (e i relativi attributi) e la necessità di associare a questo il dataset delle manutenzioni che vengono realizzate nei vari componenti della rete.

A seguire vedremo come gestire la cosa con QGIS, le relazioni e con il comodo supporto delle maschere di input personalizzabili.

Chiavi e relazione

Per mettere in relazione il dataset delle manutenzioni con quello delle strade, potrete usare il meccanismo classico delle chiavi.

Il layer delle strade sarà caratterizzato da un campo con un codice identificativo numerico univoco per ogni strada – la chiave primaria - denominato nell’esempio di questo post “pkuid”.

Il database delle manutenzioni – che è una semplice tabella senza alcun attributo spaziale – è composto dai campi “PK_UID”, “data”, “responsabile”, “compagnia”, “note”; aggiungeremo un campo che contenga il codice identificativo della strada a cui la manutezione è riferita. Questo campo farà da chiave esterna e si chiamerà “ce_pkuid”.

Il nostro modello prevede, per semplicità, che ad ogni strada sia possibile associare una o più manutenzioni; una classica relazione 1:N impostata sulle due chiavi numeriche di cui sopra.

Layer

Il layer delle strade ha la struttura sottostante, in cui sono stati introdotti dei campi per raccogliere il nome della Via, il relativo tipo (Corso, Viale, Via, ecc.) e il codice identificativo comunale.

image02

Quello delle manutenzioni conterrà un codice identificativo numerico univoco per ogni elemento, un campo in cui inserire la data dell’intervento di manutenzione, il nome del responsabile, il nome della compagnia incaricata e un campo per le note.

image10

Definire la relazione

La relazione tra i due dataset si definisce a livello di “Proprietà di progetto”. Aperto il tab Relations si farà click su “Add Relation” e si imposteranno i seguenti parametri:

  • Name, per dare un nome alla relazione;
  • Referencing Layer (Child), per il nome del layer che contiene la chiave esterna;
  • Referencing Field, per il nome della chiave esterna;
  • Referencing Layer (Parent), per il nome del layer che contiene la chiave primaria;
  • Referencing Field, per il nome della chiave primaria;
  • Id, che viene usato internamente da QGIS, deve essere univoco e fa da indice della tabella di relazione tra chiave primaria e chiave esterna.

image00

A relazione definita, questa apparirà nella finestra di dialogo:

image03

Moduli

Una volta definita la relazione, se ne avrà evidenza anche nel modulo di inserimento/modifica degli attributi del dataset delle strade. La visualizzazione a moduli in QGIS è molto utile per alcuni task di verifica ed inserimento dei dati, ed è molto personalizzabile.

image05

La tabella della manutenzioni sarà visibile in un widget del modulo dello strade, e sopra questa saranno visibili cinque pulsanti:

  1. la matita, per attivare la modifica della tabella delle manutenzioni;
  2. il “+” per aggiungere un nuovo record alla tabella, che di default verrà associato all’elemento attivo del layer “strade”;
  3. il tasto “x” per cancellare il record selezionato della tabella “manutenzioni”;
  4. il tasto “catenella” che aprirà una nuova finestra di dialogo con il quale associare qualsiasi manutenzione presente alla strada corrente;
  5. il tasto “rompi catenella” che rimuoverà l’associazione tra la manutenzione selezionata e la strada corrente;
  6. ed infine, a destra, ci sono due pulsanti per passare dalla vista “tabella” a quella modulo.

Anche per il dataset delle manutenzioni è possibile attivare il modulo di inserimento/modifica degli attributi, in modo che dia conto visivamente della relazione con il layer delle strade.

A partire dalle proprietà del layer manutenzioni, bisognerà modificare il widget del campo che fa da chiave esterna.

image04

E scegliere come tipo di widget “Relation Reference”, utilizzando i parametri visibili nella figura sottostante:

image08

Una volta scelto questo speciale widget, sarà possibile leggere la relazione tra i due layer anche nel modulo delle manutezioni:

image06

Note finali (riferimenti, file esempio e video demo)

Questo articolo è quasi una traduzione di questo di Matthias Kuhn. Sono caduto nel suo bel blog, perché tra i tipi di widget accessibili nelle proprietà dei campi di un layer ho scoperto il tipo “Relation Reference”. A me era completamente ignoto; ho provato a cercare nella documentazione, senza però trovarne traccia. Il post di Matthias mi è sembrata una piccola perla e ho creduto utile clonarlo.

Da qui potrete scaricare un file di progetto d’esempio basato su QGIS 2.2 e come formato dati su SpatiaLite. Questo ultimo farà da contenitore unico sia del file spaziale (le strade), che della tabella delle manutenzioni.

Nel progetto, per i due moduli, ho impostato altri widget diversi da quello di default (“Line edit”); alcuni sono di grande comodità come quello per il campo “data” delle manutenzioni (widget di tipo “Calendar”), o l’elenco controllato del campo “Tipo” (widget di tipo “Value map”) del layer delle strade.

image01

Per chi vuole vedere la cosa in azione ho preparato un piccolo video, che non ha alcuna pretesa didattica. Vuole essere soltanto una carrelata visuale rapida di alcune delle cose descritte in questo post.

image07

Un’ultima annotazione finale: il caso d’uso descritto è molto semplificato e non tiene conto di tutte i requisiti di un’applicazione complessa come la gestione di un network stradale. Mi è stato utile come esempio per scrivere di QGIS, relazioni, moduli e widget.


Il 28, 29, 30 di marzo si è tenuto a Bologna il raduno annuale della comunità di Spaghetti Open Data: #SOD14.

Insieme ad Andrea Borruso e Giulio Di Chiara, abbiamo deciso di partecipare spinti dalla volontà di confrontarci con una delle più importanti realtà italiane in tema di dati aperti.
Ma soprattutto abbiamo voluto esserci per completare un percorso formativo che, a partire dalla realizzazione delle Linee Guida scritte per il Comune di Palermo (documento utilizzato anche dal Comune di Matera), ci ha visti coinvolti nelle problematiche inerenti l’apertura dei dati delle PP.AA.

Ricordo ancora quando, appena qualche mese fa (agli inizi di gennaio di quest’anno), ci siamo guardati e ci siamo detti: “Però, non sarebbe male partecipare tutti e tre a SOD14“, con in faccia, tuttavia, un bel po’ di perplessità sulla fattibilità dovuta al far combaciare possibilità ed impegni.
Poi, una volta staccato il biglietto e prenotato il B&B (a proposito: grazie Giulio), tutto è diventato, come per miracolo, reale e concreto.

Queste notazioni possono sembrare cose futili, ma credetemi, non sono affatto scontate per noi (parlo a nome di tutti e tre perché so di potermelo permettere) isolani e professionisti in una realtà ancor più complicata di quello che si può immaginare.

Il raduno, come detto, si è tenuto in quella splendida cornice che è la città di Bologna (come l’anno passato).
Per la verità diverse altre città (tra cui Palermo, Matera, Napoli), avevano presentato la candidatura ad ospitare l’evento.
Ritengo che, magari per gli eventi futuri, sia importante fare un atto di coraggio e decidere di portare questi eventi laddove c’ è maggiore necessità di implementare la cultura della partecipazione e dove le Pubbliche Amministrazioni sono, per così dire, più restie a consentire il libero accesso ai dati.

Le giornate di #SOD14

Venerdì 28 è stata tenuta una conferenza in cui i partecipanti si sono aggiornati a vicenda sulle novità principali nel mondo degli open data emerse nell’ultimo anno.
La mattina è stata di plenaria, mentre il pomeriggio si sono tenuti un barcamp ed il SODcamp.

Sabato 29 vi sono stati alcuni civic hackathon: come recita la pagina di presentazione:

“produrremo insieme qualcosa di concreto. A differenza degli hackathon “normali”, il civic hackathon di SOD14 non si concentra solo sulla produzione di software, ma anche su analisi di leggi e normative o azioni di monitoraggio civico”.

Domenica 30 sono stati tenuti due mini-corsi (ritengo pratico-divulgativi essendo accessibili a molti): uno riguardava la visualizzazione dei dati, l’altro il web semantico e i linked open data.
Io non ho partecipato, in quanto, dopo tanti dati, mi sono dato ad una passeggiata turistica per le vie della città, prima di prendere il volo per Palermo. Per cui nulla posso dire al riguardo.

Il raduno generale ed i barcamp

Il primo impatto, lo dico subito, è stato molto eccitante ed euforico. Incontrare persone conosciute solamente tramite web, potersi guardare negli occhi, scoprire i volti reali delle persone dietro quelle idee e quei progetti per i quali mi sono entusiasmato, poter condividere in libertà ed informalmente, anche con il primo che passava, la propria esperienza, è stato un momento che si può riassumere in una immagine: così dovrebbero essere le Scuole e le Università in Italia!

Sarà sciocco, ma mi sono sentito come un ventenne all’Università di Stanford… o se Simone Cortesi preferisce: come un ventenne al
Queen’s College dell’Università di Oxford.
In verità non so come si sente uno studente in Università simili, ma penso che dovrebbe sentirsi proprio come mi sentivo io.
Insomma: “giro, vedo gente, mi muovo, conosco, faccio delle cose”.

Non è mia intenzione elencare qui di seguito l’intera evoluzione della mattinata, voglio solo fare qualche accenno ai momenti che adesso mi vengono così, di getto.

La presentazione di Wikidata

Come recita la pagina principale che descrive il progetto (mi raccomando fate click sui collegamenti ipertestuali):

Wikidata è una base di conoscenza libera che può essere letta e modificata allo stesso modo da umani e macchine. Fornendo un accesso centralizzato alla gestione di dati strutturati – come collegamenti interwiki e informazioni statistiche – rappresenta per i dati ciò che Wikimedia Commons è per i file multimediali. Wikidata contiene dati in tutte le lingue per le quali esistono progetti Wikimedia. Per saperne di più, è disponibile una pagina introduttiva che ne approfondisce le caratteristiche e il funzionamento.

Adam Shorland ha presentato brillantemente questo progetto: qui due presentazioni: una breve ed una lunga.

Open by default? Perché a volte i dati pubblici si riescono ad aprire e altre volte no.

Sono stati effettuati alcuni interventi programmati, moderati da Patrizia Saggini, sul tema sopra emarginato: ISTAT (Vincenzo Patruno), Regione Emilia-Romagna (Dimitri Tartari), Lombardia (Daniele Crespi), Provincia Autonoma di Trento (Lorenzino Vaccari), Palermo (Andrea Borruso), Bologna (Michele D’Alena), Ravenna (Morena Brandi)

Perché ho messo in grassetto Andrera Borruso?

Massimo Zotti Andrea Borruso Simone Cortesi

Massimo Zotti – Andrea Borruso – Simone Cortesi

Perché è un mio amico?
No, anche se “I am also a friend of @aborruso”.

Devo, invece, segnalare un piccolo fraintendimento nella comunicazione sulla partecipazione di Palermo.

Su Corriere Innovazione — rivista del Corriere della Sera online — è stato indicato che:

(…) seguiranno un dibattito con rappresentanti di enti e amministrazioni pubbliche (Istat, Provincia autonomia di Trento, Regioni Emilia-Romagna e Lombardia, Comuni di Palermo, Bologna e Ravenna), (…)

Vorrei precisare che il Comune di Palermo, purtroppo, non ha partecipato.

Andrea Borruso (sul palco e poi il giorno seguente nell’Hackaton: Gli OpenData per liberare l’Energia Potenziale dei beni confiscati alle mafie), Giulio Di Chiara ed il sottoscritto (in platea e nelle sessioni pomeridiane), hanno partecipato solo come privati cittadini, o se preferite come (anonimi) professionisti.

Potrebbe sembrare lo spunto per una polemica. Credetemi, non lo è.

Si tratta di una evidenza che non può non essere sottolineata a fronte di un’Amministrazione Comunale (Palermo) che, sebbene sollecitata, coadiuvata e pressata costantemente dai sottoscritti e da pochi altri attivisti, si è dimostrata non sufficientemente attiva e sensibile sulle politiche di partecipazione ed apertura dei dati.

All’Open Data Day che in pochissimo tempo (e senza alcuna reale risorsa)  è stato realizzato a Palermo, sono state evidenziate inadempienze e lacune sulle quali non è il caso in questa sede dilungarsi.

Devo rilevare, come riassunto in questo articolo del 24 febbraio ultimo scorso, che il Comune di Palermo è ancora pressoché fermo in ordine alla scadenze temporali relative all’attuazione delle Linee Guida.

Ad ogni modo, su tali problematicità è stato condotto l’intervento di Andrea Borruso.

Non poche perplessità, infatti, ha suscitato la comunicazione della circostanza che a fronte del contest: “ApPalermo – Palermo Open Data Contest” con un montepremi di 37.000,00 euro (che ha fatto brillare gli occhi a molti dei presenti in sala), ancora sono pochissimi, pressoché nulli, i data-set in open-data pubblicati dal Comune realmente e proficuamente utilizzabili.

Subito dopo, per l’appunto, vi è stata la premiazione dei vincitori del contest lanciato dal Comune di Ravenna, il cui ammontare totale complessivo lordo dei premi era di 3.000,00 euro.

E’ stato evidenziato come l’Amministrazione di Ravenna abbia correttamente e preliminarmente provveduto ad adottare specifiche e mirate azioni, come, ad esempio, il censimento dei dati in proprio possesso.

Un’ultima riflessione mi sia consentita sul punto: più volte mi è stato detto (anche da Dirigenti Comunali, ma non solo) che, sintetizzo: è facile effettuare questo tipo di politiche in piccoli Comuni.
Voglio rispondere, come sempre ho fatto: a chi dobbiamo ispirarci allora? Alle grandi città come Londra, New York o, in Italia, Torino? O forse mi direte che quelle realtà sono troppo grandi ed organizzate?

Metodologie e buone prassi, credo, che debbano prescindere dall’entità urbanistica.

L’apertura dei dati, aldilà della meritoria attività dei singoli attivisti, rimane una prerogativa politica.
Si dovrà ancora riflettere su come adottare delle uniformi strategie nazionali  e, soprattutto, sui rimedi concreti ed effettivi contro la disapplicazione, o l’applicazione spesso di facciata da parte della P.A., della normativa di settore.
Credo che questi temi dovranno essere il campo di battaglia su cui confrontarsi al fine di trovare un punto di incontro tra discrezionalità amministrativa ed obblighi di adeguamento.

Open Bilanci

Di pomeriggio ho seguito la sessione tenuta dall’ottimo Ettore Di Cesare su Open Bilanci.
Posso dire che il solo partecipare a questo incontro è valso di gran lunga l’acquisto del biglietto aereo per Bologna.

Dagli autori del progetto Openpolis, Open Bilanci “ha l’obiettivo di “aprire i bilanci” delle amministrazioni dei comuni italiani e renderli accessibili, comprensibili e confrontabili dai cittadini”.
Il progetto dovrebbe prendere il via a maggio (data presuntiva di rilascio) e si basa sui dati certificati dei bilanci preventivi e consuntivi che i comuni d’Italia mandano annualmente al Ministero dell’Interno (reperibili anche su Finanza Locale).

I dati (che saranno pubblicati in formato json e csv) saranno fruibili anche dal comune cittadino grazie ad una interfaccia che permetterà la visualizzazione, la consultazione, la comparazione (temporale e tra Comuni) dei bilanci di spesa dei Comuni Italiani. In più potrà essere effettuata una analisi dei bilanci comparati con l’attività delle singole amministrazione che si sono succedute nel tempo.

Le criticità del progetto cui sono andati incontro i realizzatori sono costituite dal fatto che su alcune tematiche (ad esempio rifiuti, mobilità) i Comuni si comportano in modo differente a causa della presenza delle Aziende partecipate o controllate.

IMHO

Gli aspetti positivi ed entusiasmanti di #SOD14 sono stati davvero tanti.

Mi rendo perfettamente conto anche dell’importanza di creare comunità attraverso l’entusiasmo di alcune pratiche un po’ da geek (passatemi il termine).

Francamente — ma questa è solo la mia opinione —non mi è piaciuto l’invio compulsivo di tweet (un po’ incentivato dalla proiezione dei predetti sui due maxi-schermi).
Ad ogni modo, ho preso la faccenda come un momento, diciamo, di euforia goliardica, anche se un sottile confine separa il clima goliardico, da operazioni un po’ di immagine come l’intento di entrare nei trend topic.

Non sono rimasto, invece, del tutto convinto della sessione Law4OpenData UnHackathon, il cui tema da programma era:

Fare l’analisi delle norme che non facilitano l’effettiva applicazione concreta del paradigma Open Data o che per loro complessità non semplificano il processo di liberazione dei dati. Il goal sarà quello di fare proposte concrete al nuovo ministro della Pubblica Amministrazione e fornire una tabella sinottica e grafica delle emergenti proposte sotto forma di infografica. Poiché da recenti statistiche i documenti normativi sono il secondo dataset più ambio dagli italiani, si analizzeranno anche insieme alcuni documenti giuridici (e.g. delibere comunali, piani regolatori, piani di rischio) per verificare insieme se possono essere liberati e come, applicando così il metodo preventivo dell’analisi giuridica al dataset.

Più in particolare, nella mattinata, è stata analizzata la normativa in tema di pubblicazione dei turni e degli orari delle farmacie di un Comune, prendendo le mosse da un caso concreto. L’obiettivo era quello di evidenziare punti deboli e prospettive.

Non voglio dilungarmi sul punto, tuttavia sono convinto — ma anche questa è solo una mia opinione — che la sessione poteva essere organizzata meglio, in modo più consapevole ed approfondito.
Non so che fine farà il risultato del lavoro (che, comunque, dovrà essere ulteriormente verificato), non essendo stata realizzata alcuna piattaforma collaborativa sul tema. Magari per le prossime volte sarebbe importante comunicare direttamente ai partecipanti il cuore delle problematiche da affrontare in modo da poter giungere più consapevolmente ai goals programmati.

Ad ogni modo la metodologia mi ha molto coinvolto ed è mia intenzione, nei prossimi mesi, provare ad organizzare nel mio campo professionale qualcosa di simile, soprattutto con l’ausilio di varie competenze professionali esterne.

Questo articolo

Voglio dedicare questo articolo a Lorenzo Perone ed alla sua splendida famiglia, non solo per l’accoglienza ed il caldo affetto che ci hanno dimostrato, (mi è sembrato quasi un terrone, io lo posso dire, voi no).

Ma soprattutto voglio ringraziarlo per le lasagne di sua suocera.

Lorenzo (come me qualche volta) scrive su TANTO , il bar dietro al router, dove ci siamo incontrati.

@lorenzo_perone is my friend

Post Scriptum

A proposito di dati: al rientro a Palermo abbiamo scoperto casualmente (all’andata ancora non era presente tale servizio) che la controllata (al 100%) del Comune di Palermo  Amat Palermo S.p.A. (autobus), ha rilasciato alla statunitense società Google Inc. i dati sorgenti del trasporto pubblico locale di Palermo (come per altro hanno fatto molte altre città italiane).
Qui l’articolo scritto da Giulio Di Chiara.
Nulla di male, anche se non vi è stato alcuna comunicazione ufficiale o ufficiosa.

Abbiamo già chiesto (per primo Simone Cortesi con una PEC diretta al Sindaco di Palermo) che che questi dati, in forma sorgente, vengano forniti, con le stesse modalità, alla comunità italiana opendata. L’azione di rilascio in open data sarebbe infatti in grado di dare un contributo all’innovazione a Palermo, soprattutto come base per la creazione di servizi alternativi.


NdR: la redazione di TANTO aderisce e sostiene questa campagna Team degli Sviluppatori di GRASS

In occasione dell’imminente Code Sprint di Vienna 2014, all’inizio di quest’anno il Comitato Direttivo (PSC) di GRASS ha deciso di aderire ufficialmente all’evento, considerata la grande opportunità per attività comuni. Più di 60 sviluppatori dei piu`importanti progetti OSGeo parteciperanno all’evento.

Mentre gli sviluppatori di GRASS donano il loro prezioso tempo, gli utenti appassionati (tu!) possono contribuire con donazioni, anche simboliche, che verranno utilizzate per coprire le spese vive dei partecipanti.Le aziende possono anche decidere di sponsorizzare un compito specifico! Per saperne di più non esitate a contattarci (o Markus Neteler neteler@osgeo.org).

Come sempre, tutto il lavoro svolto durante lo Sprint verrà direttamente messo a disposizione del progetto GRASS, per il beneficio dell’intera comunità  di utenti. L’obiettivo per lo Sprint è quello di pubblicare la prima versione candidata stabile di GRASS GIS 6.4.4 e la versione di anteprima tecnologica di GRASS GIS 7.

Potete utilizzare il comodo pulsante Paypal all’indirizzo: http://grass.osgeo.org/donations/. Per opzioni di pagamento alternative, potete contattare Martin Landa (landa.martin@gmail.com).

Grazie per il vostro sostegno!
Il Team degli Sviluppatori di GRASS


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.