Open Pronto Soccorsi: aggiornamento con nuovi dati

In seguito alla pubblicazione del primo post su Open Pronto Soccorsi ho ricevuto alcune indicazioni su ulteriori dati disponibili.

Mi ci è voluto un po di tempo ma ora sono in grado di pubblicare un aggiornamento dei dati tra cui, la quota maggiore, tutti quelli della Regione Lombardia (e colgo l’occasione per ringraziare Daniele Crespi per la segnalazione).

La nuova distribuzione su base nazionale è quindi la seguente

Quindi, con l’aggiunta dei dati lombardi (che si aggiunge a quella del Veneto e del Friuli Venezia Giulia), possiamo dire che è disponibile una continuità territoriale quasi dell’intero nord est della penisola italiana.

L’elenco completo dei Comuni per i quali sono stati recuperati i dati dei Pronto Soccorsi sul loro territorio è il seguente

Abano Terme	Cittadella	Magenta	San Daniele del Friuli
Abbiategrasso	Cittiglio	Malcesine	San Dona’ di Piave
Acquapendente	Cividale del Friuli	Manduria	San Donato Milanese
Adria	Civita Castellana	Manerbio	San Fermo Della Battaglia
Agordo	Civitavecchia	Manfredonia	San Gavino Monreale
Alatri	Cles	Mantova	San Giovanni Bianco
Albano Laziale	Colleferro	Martina Franca	San Giovanni in Persiceto
Alghero	Como	Melzo	San Marcello Pistoiese
Altamura	Conegliano	Menaggio	San Severo di Puglia
Alto Reno Terme	Copertino	Merate	San Vito al Tagliamento
Alzano Lombardo	Corato	Mestre	Sanremo
Ancona	Crema	Milano	Santorso
Andria	Cremona	Mirano	Saronno
Angera	Cuggiono	Molfetta	Sassari
Anzio	Desenzano del Garda	Monfalcone	Scorrano
Arco	Desio	Monopoli	Segrate
Arzignano	Dolo	Monselice	Seriate
Asiago	Edolo	Monserrato	Sesto San Giovanni
Asola	Erba	Montagnana	Sondalo
Bagno a Ripoli	Esine	Montebelluna	Sondrio
Bari	Feltre	Monterotondo	Sora
Barletta	Figline e Incisa Valdarno	Montichiari	Sorgono
Bassano del Grappa	Firenze	Monza	Stradella
Belluno	Foggia	Mortara	Subiaco
Bentivoglio	Fondi	Muravera	Suzzara
Bergamo	Formia	Negrar	Taranto
Bibione	Francavilla Fontana	Noventa Vicentina	Tarquinia
Bisceglie	Frascati	Nuoro	Tempio Pausania
Bologna	Frosinone	Oderzo	Terlizzi
Bordighera	Galatina	Olbia	Terracina
Borgo San Lorenzo	Gallarate	Ome	Teviglio
Borgo Valsugana	Gallipoli	Oristano	Tione di Trento
Bosa	Garbagnate Milanese	Osio Sotto	Tivoli
Bovolone	Gardone Val Trompia	Ostuni	Tolmezzo
Bracciano	Gavardo	Ozieri	Torino
Brescia	Gemona del Friuli	Paderno Dugnano	Tradate
Brindisi	Genova	Padova	Trani
Budrio	Ghilarza	Palermo	Trecenta
Bussolengo	Gorizia	Palestrina	Trento
Busto Arsizio	Grado	Palmanova	Treviso
Cagliari	Gravedona	Pavia	Trieste
Camposampiero	Iglesias	Peschiera del Garda	Triggiano
Canosa di Puglia	Imperia	Pescia	Udine
Caorle	Iseo	Piario	Valdagno
Carate Brianza	Isili	Pieve di Cadore	Valsamoggia
Carbonia	Isola della Scala	Pieve di Coriano	Varese
Casalmaggiore	Jesolo	Piove di Sacco	Varzi
Casarano	La Maddalena	Pistoia	Velletri
Caserta	Lanusei	Ponte San Pietro	Venezia
Cassino	Latina	Pordenone	Vergato
Castelfranco Veneto	Latisana	Portogruaro	Verona
Castellaneta	Lavagna	Prato	Vicenza
Castellanza	Lecce	Putignano	Vigevano
Castiglione delle Stiviere	Lecco	Rho	Villafranca di Verona
Cavalese	Legnago	Rieti	Vimercate
Cerignola	Legnano	Roma	Viterbo
Cernusco sul Naviglio	Lodi	Romano di Lomardia	Vittorio Veneto
Chiari	Lonigo	Rovereto	Vizzolo Predabissi
Chiavenna	Lovere	Rovigo	Voghera
Chioggia	Lucera	Rozzano
Cinisello Balsamo	Luino	San Bonifacio

Ricordo che i riferimenti utili per consultare i dati sono i seguenti:

• un servizio “machine readable“ per interrogare i dati per comune e distanza: http://www.cesaregerbino.it/OpenProntoSoccorsi/API/getProntoSoccorsoDetailsByMunicipality.php?municipality=Torino&distance=0 dove è possibile modificare il nome del comune e in cui il parametro distance indica, se valorizzato a zero, che la ricerca viene svolta per i pronto soccorsi che si trovano all’interno del territorio comunale del comune indicato, altrimenti permette di fare una ricerca nell’intorno del comune stesso, ad esempio distance=10000 indica una ricerca nell’intorno di 10 km dal comune indicato.
• una semplice web application che, immettendo il nome del comune di interesse ed un raggio di ricerca nel suo intorno restituisce l’elenco dei pronto soccorsi con relative info sui numeri e tempi di attese per tipologia (rif. http://www.cesaregerbino.it/OpenProntoSoccorsi/WebApp/OpenProntoSoccorsiForm.php )
• un’applicazione di web mapping che permette di visualizzare la distribuzione sul territorio italiano dei pronto soccorsi di cui si è riusciti ad individuare la pubblicazione dei dati sui numeri e tempi di attese per tipologia, e di interrogare interattivamente i dati del singolo pronto soccorso (rif. http://www.cesaregerbino.it/OpenProntoSoccorsi/WebMapping/OpenProntoSoccorsi.php )
• un bot telegram (OpenProntoSoccorsiBot), in cui è possibile indicare il nome del comune di interesse ed un raggio di ricerca nel suo intorno e che restituisce l’elenco dei pronto soccorsi con relative info sui numeri e tempi di attese per tipologia. E’ anche possibile indicare la posizione, ed un raggio di ricerca nel suo intorno, ed ottenere il medesimo risultato: in questo caso il bot permette anche di avere l’informazione del percorso per raggiungere il pronto soccorso di interesse tra quelli proposti.

Buona consultazione !!

Quattro milioni di verbali (open …) su una mappa

Tra i vari canali social che seguo ho trovato in questi giorni questo bel riferimento, il progetto Infrazioni  ….

… che usando dati i open delle infrazioni stradali della città di Torino ha realizzato una bella web gis application interattiva con cui si possono visualizzare ed interrogare i dati (potete divertirvi a cercare i luoghi, e i periodi, ove si registrano il maggiore o minore numero di infrazioni per tipologia ….diciamo che chi è di Torino intuisce rapidamente la natura dei due grossi cerchi in alto a sinistra ed in basso a destra della mappa …. 🙂 ).

Al netto dell’interfaccia  (realizzata con MapBox …), che è sicuramente curata, con buone prestazioni e di facile utilizzo, il grosso valore aggiunto è il riuso di dati aperti messi a disposizione da parte di una P.A., rappresentando una bella sinergia, un approccio “win-win” che sempre di più si spera di vedere.

I dati delle infrazioni infatti sono disponibili open data sul portale degli open data del Comune di Torino (e disponibili per più anni, dal 2011 al 2015 …), ma questo non è l’unico dataset utilizzato, in quanto i dati sono stati relazionati sul territorio utilizzando i dati della toponomastica comunale, anch’essi disponibili sul medesimo portale (a tale proposito, come elemento di miglioramento, si potrebbe suggerire al Comune di Torino di integrare già dalla fonte, vale a dire dalle generazione del dato delle infrazioni, la relazione spaziale, diretta o indiretta, con ìl numero civico o l’incrocio corrispondente usando la propria toponomatica al fine di rendere  così i dati relazionati strettamente ed in modo tra loro coerente. Credo che questo avrebbe fatto risparmiare parecchio tempo ai realizzatori del progetto …. se poi proprio volessimo esagerare, avere i medesimi dati disponibili come open services …. male non farebbe …).

E’ comunque un esempio “virtuoso” di collaborazione tra P.A e “privati /cittadini” che vale la pena di segnalare ed applaudire …. bravi tutti!

OpenDistributoriCarburantiBot: risparmiare sul pieno di carburante con Telegram

In questi ultimi tempi, su più fronti si sente parlare molto spesso di Telegram, non solo e non tanto come app di messaggistica (per certi versi in alternativa o in opposizione / concorrenza a WhatsApp), quanto per la possibilità offerta di poter realizzare delle chat automatiche (denominati “bot”), il cui scopo è quello di rispondere alle nostre domande, alle nostre richieste, e facilitare in generale operazioni varie.

Si và da esempi molto semplici, piccoli giochi, sino a cose più serie ed articolate. Riporto ad esempio:

• @webcamstravelbot che fornisce l’elenco delle webcam intorno ad un punto di interesse
• @escilaricettaBot che permette di ricercare ricette dato un certo ingrediente di interesse
• @emergenzeprato_bot per le segnalazioni meteo a di rischio dell’area del comune di Prato
• @divinacommediabot che permette di ricercare versi della Divina Commedia di Dante
• @gttorari_bot con cui la compagnia dei trasporti pubblici di Torino informa i propri utenti dei passaggi degli autobus

…. sino ad arrivare, notizia proprio degli ultimi giorni, al canale @pgpompei attraverso il quale Papa Francesco fà arrivare giornalmente il Vangelo del giorno!!! Quindi davvero dal “sacro” al “profano” …..

Non mi dilungo qui a spiegare più nel dettaglio: su internet si trovano abbondanti informazioni sia sulla piattaforma sia su cosa sono questi bot, per cui rimando a queste fonti tutti coloro che fossero interessati ad approfondire.

Più che lo strumento di messagistica in sè, con le sue dichiarate caratteristiche peculiari di maggior sicurezza e rispetto della privacy (nel bene e nel male ….), rispetto ai suoi concorrenti, mi ha incuriosito la possibilità di realizzare queste chat automatiche e quindi, volendone approfondire l’argomento, ho deciso a provare a realizzarne una.

Mi mancava un caso d’uso che non fosse un classico “Hello World!” e che, ovviamente, avesse anche una sua componente “spaziale”.

Dopo qualche riflessione ed ipotesi mi sono ricordato di un bel lavoro fatto tempo fà da Stefano Sabatini (@__sabas) sui distributori di carburanti in Italia che mi sembrava fosse adatto allo scopo: dati “reali”, dati open, liberamente utilizzabili (licenza iodl 2.0), aggiornati giornalmente, con coordinate e quindi facilmente trasformabili in un dato spaziale per poi essere utilizzabili anche con funzionalità spaziali.

E’ così che è nata l’ipotesi, pian piano concretizzatasi, di OpenDistributoriCarburantiBot.

Questo bot permette di sapere, dato un comune italiano, quali sono i distributori di carburante che vi ricadono o, data una posizione georiferita, quali sono i distributori di carburante che ricadono nel suo intorno per una certa distanza (scelta tra 500, 1000, 2000 e 3000 metri).

I dati sono aggiornati giornalmente a partire dalle 08.30 attingendo direttamente dagli open del Ministero dello Sviluppo Economico (MISE).

E’ possibile selezionare il carburante di proprio interesse ed i risultati sono ordinati sulla base del prezzo: è quindi possibile individuare quelli più convenienti per le nostre esigenze.

A seconda del tipo di ricerca effettuata, e se si è fornita o meno la posizione georiferita, è possibile:

• visualizzare su mappa OpenStreetMap la localizzazione del distributore
• visualizzare la descrizione del percorso per raggiungere il distributore dalla posizione corrente
• visualizzare, su mappa 2D, il percorso per raggiungere il distributore dalla posizione corrente
• visualizzare, su mappa 3D, il percorso per raggiungere il distributore dalla posizione corrente. Per questa ultima funzionalità è necessario disporre di un web browser di ultima generazione che supporti webGL (le ultime versioni di Mozilla Firefox e Chrome sono già abilitate)

Il suo utilizzo è molto semplice: nel seguito vi illustro una sequenza di passi per il suo utilizzo e anche una breve sessione utente registrata in video.

Occorre ovviamente avere installato Telegram sul proprio smartphone, tablet o desktop (nota: la versione desktop è un pò limitata per le funzonalità supportate, ad esempio non è possibile fornire la propria posizione, o almeno io non ci sono riuscito): fatto questo è sufficiente ricercare “OpenDistributoriCarburantiBot” come illustrato

All’avvio viene visualizzato un messaggio di benvenuto con una una breve sintesi sulle sue caratteristiche.

Occorre avviare il bot se si intende utilizzarlo

In qualunque momento questo messaggio è nuovamente visualizzabile scrivendo il comando /start.

Sono disponibili anche altri due comandi, rispettivamente /info (per avere informazioni di dettagli tecnico)…

…. e /credits (per i doverosi e necessari ringraziamenti) ….

E possibile scrivere il nome di un comune italiano: il nome può essere scritto minuscolo o maiuscolo in modo indifferente. Sono trattati anche nomi di comuni con spazi ed apostrofi.

Per i comuni il cui nome contiene lettere accentate è necessario utilizzare gli apici

A questo punto occorre selezionare, dal menù visualizzato, il tipo di carburante e attendere il risultato della ricerca

Se la ricerca produce risultati questi sono ordinati per prezzo crescente e, per ogni risultato, è possibile visualizzare su una mappa OpenStreetMap la localizzazione del relativo distributore

L’indicazione del comune non è l’unica modalità di ricerca: è infatti possibile indicare le propria posizione corrente o di interesse cliccando sull’icona della graffetta che in queste videate compare in basso a destra e poi selezionare l’opzione ‘Posizione‘

A questo punto è necessario selezionare, dal menù visualizzato, il raggio di ricerca

A questo punto occorre selezionare, dal menù visualizzato, il tipo di carburante

In questo caso, se la ricerca produce risultati questi sono ordinati per prezzo crescente e, per ogni risultato, è possibile:

• visualizzare su una mappa OpenStreetMap la localizzazione del relativo distributore
• visualizzare la descrizione del percorso per raggiungere il distributore di interesse a partire dal punto di ricerca
• visualizzare il percorso per raggiungere il distributore di interesse a partire dal punto di ricerca su una mappa OpenStreetMap bidimensionale
• visualizzare il percorso per raggiungere il distributore di interesse a partire dal punto di ricerca su una mappa OpenStreetMap tridimensionale (OSM Buildings)

Ed ecco ora in video come avviene dal vivo una sessione utente immaginandone la fruizione durante una gita nel territorio Albese:

Come detto in precedenza i dati sono giornalmente tratti direttamente dal Ministero dello Sviluppo Economico (MISE) a cui è demandato il livello di completezza e aggiornamento rispetto alle diverse realtà locali: devo dire che ho notato, almeno nelle zone che conosco, che, da quando ho iniziato a fare questo piccolo esperimento, aggiornamento e completezza sono in crescita.

Per concludere devo ringraziare tutti coloro da cui ho tratto spunti ed ispirazione, nonchè supporto diretto in varie forme, e quindi, sperando di non dimenticare nessuno direi:

• Stefano Sabatini (@__sabas), per il suo lavoro iniziale da cui ho tratto spunto per l’idea
• Matteo Tempestini (@il_tempe), Francesco “Piersoft” Paolicelli (@Piersoft) e Gabriele Grillo da cui ho tratto il codice inziale e per il loro supporto via mail
• Alessandro Furieri, per il suo grandissimo lavoro su Spatialite, data base open source che ho usato come tool per memorizzare i dati georiferiti, e per il suo paziente supporto online
  Fabrizio Massara per la pazienza ed il suo supporto a 360° nonchè, per la condivisione del server su cui stà girando il codice del bot in produzione
• mia moglie, per il tempo che le ho rubato per fare tutto ciò

Un ringraziamento particolare, perchè si è dimostrato un vero “signore” (merce rara …), lo devo a @Piersoft per la sua disponibilità a rinunciare a pubblicare un lavoro analogo in buona parte realizzato, pur di non “bruciarmi” la news ….. grazie mille!!!!

Per chi fosse interessato a maggiori dettagli tecnici per sapere “come è fatto dentro” rimando ad un altro post

A questo punto non resta quindi che iniziare a provare ad usare di OpenDistributoriCarburantiBot e vedere di iniziare a risparmiare facendo il pieno nei distributori più convenienti!

OpenDistributoriCarburantiBot: come è fatto “dentro”

In questo post vedo di fornire qualche dettaglio su quelle che sono le caratteristiche e soluzioni tecniche che stanno alla base di OpenDistributoriCarburantiBot.

Non mi dilungo qui a spiegare nel dettaglio la piattaforma Telegram e la basi dei bot: rimando coloro che fossero interessati ad approfondire ad attingere dalle innumerevoli fonti presenti in rete.

Schematicamente l’architettura della soluzione è la seguente:

Nel diagramma sono citati i vari componenti del sistema che:

• è ospitato su una macchina Ubuntu 14.0.4 LTS
• utilizza come database SQLite3 + Spatialite 4.4.0
• implementa la logica di business in PHP 5
• si avvale di servizi di OpenStreetMap, OSM Buildings, Mapquest e Google ShortLink

Si tratta di una soluzione che utilizza tutti software open source e attinge da servizi disponibili in rete.

Per una soluzione più scalabile è possibile passare ad utilizzare POSTGRESQL con la sua estensione POSTGIS, non cambiando la logica di funzionamento.

Nel diagramma sono anche illustrati i passi delle diverse operazioni coinvolte e precisamente:

• giornalmente il sistema scarica dal MISE (0a) i dati e li memorizza sul db (0b)
  l’utente invia una richiesta dal proprio client (1)
• il sistema recupera le richieste con un’operazione di getUpdates (2)
• effettua le ricerche su DB (3)
• nell’elaborazione della risposta invoca i servizi di Google Shortlink per abbreviare le url (4)
• con un’operazione di sendMessage risponde (5)
• Telegram inoltra la risposta al client (6)
• l’utente può fruire dei diversi link contenuti nella risposta (7, 7a, 7b e 7c)

Il “cuore” del sistema sono i dati: questi sono tratti giornalmente dagli open del Ministero dello Sviluppo Economico (MISE).

I dati sono forniti nella forma di due file .csv che riportano le anagrafiche dei distributori ed i prezzi dei carburanti. Tra i dati delle anagrafiche dei distributori, informazione importante, sono disponibili anche le coordinate, espresse in latitudine e longitudine.

NOTA: negli esempi si suppone che il sw sia installato in /var/www/html/Telegram per cui la variabile <base_path> = /var/www/html/Telegram

Tutte le mattine, con un crontab schedulato, i dati sono prelevati via wget,

wget -U "Opera" -O <base_path>/OpenDistributoriCarburantiBot/Dati/prezzo_alle_8.csv http://www.sviluppoeconomico.gov.it/images/exportCSV/prezzo_alle_8.csv

wget -U "Opera" -O <base_path>/OpenDistributoriCarburantiBot/Dati/anagrafica_impianti_attivi.csv http://www.sviluppoeconomico.gov.it/images/exportCSV/anagrafica_impianti_attivi.csv

Si provvede ad eliminare la prima riga dei files

sed '1d' <base_path>/OpenDistributoriCarburantiBot/Dati/anagrafica_impianti_attivi.csv > <base_path>/OpenDistributoriCarburantiBot/Dati/anagrafica-temp.csv

sed '1d' <base_path>/OpenDistributoriCarburantiBot/Dati/prezzo_alle_8.csv > <base_path>/OpenDistributoriCarburantiBot/Dati/prezzo.csv

Nel file delle anagrafiche è necessario eliminare il carattere “doppi apici” che influisce negativamente nell’import in Spatialite

sed 's/"//g' <base_path>/OpenDistributoriCarburantiBot/Dati/anagrafica-temp.csv > <base_path>/OpenDistributoriCarburantiBot/Dati/anagrafica.csv

A questo punto è possibile creare il data base Spatialite ….

/usr/local/bin/spatialite <base_path>/OpenDistributoriCarburantiBot/Dati/PrezziCarburanti < <base_path>/OpenDistributoriCarburantiBot/Dati/CreaPrezziCarburanti.txt

….. con i seguenti dettagli …

CREATE TABLE anagrafica_impianti_attivi( idImpianto TEXT,
Gestore TEXT,
Bandiera TEXT,
Tipo Impianto TEXT,
Nome Impianto TEXT,
Indirizzo TEXT,
Comune TEXT,
Provincia TEXT,
Latitudine DOUBLE,
Longitudine DOUBLE );
CREATE TABLE prezzo_alle_8( idImpianto TEXT,
descCarburante TEXT,
prezzo TEXT,
isSelf TEXT,
dtComu TEXT );
.mode csv

.separator ;

.import <BASE_PATH>/OpenDistributoriCarburantiBot/Dati/anagrafica.csv anagrafica_impianti_attivi

SELECT AddGeometryColumn('anagrafica_impianti_attivi','geometry',4326,'POINT',2); UPDATE anagrafica_impianti_attivi SET geometry = GeomFromText('POINT('||"Longitudine"||' '||"Latitudine"||')',4326);

.import <BASE_PATH>/OpenDistributoriCarburantiBot/Dati/prezzo.csv prezzo_alle_8

.quit

La logica di business è stata implementata in php sebbene questa non sia una scelta esclusiva od obbligata. E’ possibile scegliere linguaggi di programmazione diversi: nel mio caso è stata una scelta di opportunità visto che in PHP avevo la possibilità di trovare maggiore esempi e supporto.

Di potenziale interesse riporto come sono implementate le ricerche, ad esempio quella per i distributori di un comune

SELECT distr.Comune, distr.Gestore, distr.Indirizzo, distr.Bandiera, distr.Latitudine, distr.Longitudine, prz.descCarburante, prz.prezzo, prz.dtComu FROM anagrafica_impianti_attivi as distr JOIN prezzo_alle_8 as prz ON (prz.idImpianto = distr.IdImpianto) WHERE distr.Comune = :Comune ORDER BY prz.prezzo ASC

dove ovviamente il parametro :Comune sarà poi valorizzato dal nome del comune corrente indicato dall’utente.

Analogamente, una ricerca spaziale che individua i distributori di un certo carburante, nell’intorno di una certa distanza da un punto, caratterizzato da una determinata coppia di coordinate, sarà

SELECT distr.Comune, distr.Gestore, distr.Indirizzo, distr.Bandiera, distr.Latitudine, distr.Longitudine, prz.descCarburante, prz.prezzo, prz.dtComu, ST_Distance(distr.geometry, MakePoint('.$lon.', '.$lat.', 4326), 1) AS dist FROM anagrafica_impianti_attivi as distr JOIN prezzo_alle_8 as prz ON (prz.idImpianto = distr.IdImpianto) WHERE dist <= '.$dist.' AND prz.descCarburante = \''.$carburante.'\' ORDER BY prz.prezzo ASC, dist ASC

Ovviamente i risultati delle query sono poi parsificati opportunamente per andare a costruire il messaggio finale che arriverà sul dispositivo dell’utente finale.

Ecco come …..

try {
$stmt = $db->prepare($q);
$results = $stmt->execute();
$count = 0;
while (($row = $results->fetchArray(SQLITE3_ASSOC)) AND ($count < $limit_search)){
$data .= "Marca: ".$row['Bandiera'];
$data .= "\n";
$data .= "Carburante: ".$row['descCarburante'];
$data .= "\n";
$data .= "Prezzo: ".$row['prezzo'];
$data .= "\n";
$data .= "Data: ".$row['dtComu'];
$data .= "\n";

$longUrl = "http://www.openstreetmap.org/?mlat=".$row['Latitudine']."&mlon=".$row['Longitudine']."&zoom=18";
$shortUrl = CompactUrl($longUrl);
$data .= "Mappa: ".$shortUrl;
$data .= "\n";

$longUrl = $base_url."/Telegram/DistributoriCarburanti/RenderRoute.php?lat_from=".$lat."&lon_from=".$lon."&lat_to=".$row['Latitudine']."&lon_to=".$row['Longitudine']."&map_type=0";
$shortUrl = CompactUrl($longUrl);
$data .= "Descrizione Percorso: ".$shortUrl;
$data .= "\n";

$longUrl = $base_url."/Telegram/DistributoriCarburanti/RenderRoute.php?lat_from=".$lat."&lon_from=".$lon."&lat_to=".$row['Latitudine']."&lon_to=".$row['Longitudine']."&map_type=2";
$shortUrl = CompactUrl($longUrl);
$data .= "Percorso su mappa 2D: ".$shortUrl;
$data .= "\n";

$longUrl = $base_url."/Telegram/DistributoriCarburanti/RenderRoute.php?lat_from=".$lat."&lon_from=".$lon."&lat_to=".$row['Latitudine']."&lon_to=".$row['Longitudine']."&map_type=3";
$shortUrl = CompactUrl($longUrl);
$data .= "Percorso su mappa 3D: ".$shortUrl;
$data .= "\n";

$data .= "\n";
$count = $count + 1;
}
if ($count >= $limit_search){
$data .= "La ricerca ha prodotto troppi risultati !!! Si presentano solo i primi ".$limit_search.". Per maggiori dettagli provare a cambiare comune, tipo di carburante, posizione o raggio di ricerca";
$data .= "\n";
}
return $data;
}
catch(PDOException $e) {
print "Something went wrong or Connection to database failed! ".$e->getMessage();
}
}
}

I messaggi di Telegram non possono superare i 4096 caratteri e dovendo fornire le url per la visualizzazione dei dettagli del percorso o della sua rappresentazione su mappa, ho dovuto “restringere” le url stesse avvalendomi del servizio di Google URL Shortener.

Il tutto avviene invocando un’apposita funzione …

function CompactUrl($longUrl)
{
$apiKey = API;

$postData = array('longUrl' => $longUrl);
$jsonData = json_encode($postData);

$curlObj = curl_init();

curl_setopt($curlObj, CURLOPT_URL, 'https://www.googleapis.com/urlshortener/v1/url?key='.$apiKey.'&fields=id');
curl_setopt($curlObj, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($curlObj, CURLOPT_SSL_VERIFYPEER, 0);
curl_setopt($curlObj, CURLOPT_HEADER, 0);
curl_setopt($curlObj, CURLOPT_HTTPHEADER, array('Content-type:application/json'));
curl_setopt($curlObj, CURLOPT_POST, 1);
curl_setopt($curlObj, CURLOPT_POSTFIELDS, $jsonData);

$response = curl_exec($curlObj);

// Change the response json string to object
$json = json_decode($response);

curl_close($curlObj);
$shortLink = get_object_vars($json);

return $shortLink['id'];
}

Siccome tutte le comunicazioni sono “stateless”, mentre per alcuni passaggi necessitavo di mantenere traccia delle opzioni selezionate ai passi precedenti, ho implementato una piccola gestione di sessione sul db SQLite 3.

In questo modo aggiorno i dati quando necessario …

try {
$base_path = BASE_PATH;
//## Preparo di dati di sessione da memorizzare nel data base per il'id di chat ...
$session_data = array(
array('Chat_id' => $chat_id,
'Comune' => $comune,
'My_Lat' => $lat,
'My_Lon' => $lon,
'Search_Distance' => $search_distance
)
);
//## Accedo al db di sessione per memorizzare i dati per il'id di chat ...
$db_data_sessions = new SQLite3($base_path.'/DistributoriCarburanti/DataSessionsDB');
//## Accedo al db di sessione per eliminare i dati di sessione per di interesse per l'id di chat ...
$q="DELETE FROM data_sessions WHERE Chat_id = :Chat_id";
try {
$stmt = $db_data_sessions->prepare($q);
$stmt->bindvalue(':Chat_id', $chat_id, SQLITE3_TEXT);
$results = $stmt->execute();
}
catch(PDOException $e) {
print "Something went wrong or Connection to database failed! ".$e->getMessage();
}

//## Prepare INSERT statement to SQLite3 file db ...
$insert = "INSERT INTO data_sessions (Chat_id, Comune, My_Lat, My_Lon, Search_Distance) VALUES (:Chat_id, :Comune, :My_Lat, :My_Lon, :Search_Distance)";
$stmt = $db_data_sessions->prepare($insert);

//## Bind parameters to statement variables ...
$stmt->bindParam(':Chat_id', $Chat_id);
$stmt->bindParam(':Comune', $Comune);
$stmt->bindParam(':My_Lat', $My_Lat);
$stmt->bindParam(':My_Lon', $My_Lon);
$stmt->bindParam(':Search_Distance', $Search_Distance);

//## Loop thru all messages and execute prepared insert statement ...
foreach ($session_data as $data) {
//## Set values to bound variables ...
$Chat_id = $data['Chat_id'];
$Comune = $data['Comune'];
$My_Lat = $data['My_Lat'];
$My_Lon = $data['My_Lon'];
$Search_Distance = $data['Search_Distance'];

//## Execute statement ...
$stmt->execute();

$db_data_sessions = null;
}

}
catch(PDOException $e) {
print "Something went wrong or Connection to database failed! ".$e->getMessage();
}

ed in questo modo recupero i dati quando necessario ….

$db_data_sessions = new SQLite3($base_path.’/DistributoriCarburanti/DataSessionsDB’);
$q="SELECT ds.Chat_id, ds.Comune, ds.My_Lat, ds.My_Lon, ds.Search_Distance
FROM data_sessions as ds
WHERE ds.Chat_id = :Chat_id";
try {
$stmt = $db_data_sessions->prepare($q);
$stmt->bindvalue(':Chat_id', $chat_id, SQLITE3_TEXT);
$results = $stmt->execute();
while ($row = $results->fetchArray(SQLITE3_ASSOC)){
$comune = $row['Comune'];
$my_lat = $row['My_Lat'];
$my_lon = $row['My_Lon'];
$search_distance = $row['Search_Distance'];
}
}
catch(PDOException $e) {
print "Something went wrong or Connection to database failed! ".$e->getMessage();
}

Per il calcolo dei percorsi utilizzo il servizio di routing di MapQuest (rif. https://developer.mapquest.com/products/directions): tale servizio, gratuito sino a 15.000 chiamate al giorno (non credo di superare tali limite …. ne sarei piacevolmente stupito ….), si basa sui dati di OpenStreetMap e permette di ritornare sia la semplice descrizione testuale del percorso, sia i suoi dettagli geografici in formato JSON.

Ecco un esempio di chiamata ….

http://www.mapquestapi.com/directions/v2/route?key=YOUR_KEY_HERE&from=Lancaster,PA&to=York,PA&callback=renderNarrative

Il richiamo del servizio avviene via CURL

$url = 'http://open.mapquestapi.com/directions/v2/route?key=&outFormat=json&routeType=fastest&timeType=1&narrativeType=html&enhancedNarrative=true&shapeFormat=raw&generalize=0&locale=it_IT&unit=k&from='.$lat_from.','.$lon_from.'&to='.$lat_to.','.$lon_to.'&drivingStyle=2&highwayEfficiency=21.0';

//#Set CURL parameters
$ch = curl_init();
curl_setopt($ch, CURLOPT_AUTOREFERER, TRUE);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, TRUE);
curl_setopt($ch, CURLOPT_PROXY, '');
$data = curl_exec($ch);
curl_close($ch);

//#Convert to string (json) the route ...
$json = json_decode($data);

ed ecco come aggiungere il json del percorso sulla mappa Leaflet …..

var json_route = <?php echo json_encode($json); ?>;

//# Calculate the new map center based on the route bounding box ...
lng_ul = json_route.route.boundingBox.ul.lng;
lat_ul = json_route.route.boundingBox.ul.lat;
lng_lr = json_route.route.boundingBox.lr.lng;
lat_lr = json_route.route.boundingBox.lr.lat;
lng_center = (lng_lr - lng_ul)/2 + lng_ul;
lat_center = (lat_ul - lat_lr)/2 + lat_lr;


var map = L.map('map').setView([lat_center, lng_center], 15);

L.tileLayer('https://api.tiles.mapbox.com/v4/{id}/{z}/{x}/{y}.png?access_token=’, {
maxZoom: 18,
attribution: 'Map data © OpenStreetMap contributors, ' +
'CC-BY-SA, ' +
'Imagery © Mapbox',
id: 'mapbox.light'
}).addTo(map);

the_coords = '';

for (i = 0; i < json_route.route.shape.shapePoints.length; i++) {
if (i == 0) {
the_coords = the_coords + '[' + json_route.route.shape.shapePoints[i+1] + ',' + json_route.route.shape.shapePoints[i] + ']';
}
else {
if ((i % 2) == 0) {
the_coords = the_coords + ',[' + json_route.route.shape.shapePoints[i+1] + ',' + json_route.route.shape.shapePoints[i] + ']';
}
}
}

//# Create the lineString json (text) of the route ...
var my_lineString = '{\"type\": \"Feature\", \"properties\": {}, \”geometry\”: {\”type\”: \”LineString\”, \”coordinates\”: [‘ + the_coords + ‘]}}’;

//# Create le lineString json (object) of the route ...
var lineString = JSON.parse(my_lineString);

//# add the lineString json (object) of the route to the map ...
L.geoJson(lineString).addTo(map);

Per la rappresentazione su mappa 3D l’approccio è del tutto analogo, con una unica eccezione: non essendo possibile sovrapporre alla mappa OSM Buildings un oggetto Linestring il percorso viene trasformato in un oggetto poligonale calcolandone un piccolo buffer di 1 metro. Il calcolo del buffer avviene avvalendosi della libreria Turf.js (rif. http://turfjs.org/).

Ecco come avviene il tutto ….

//# Extract the route coordinates ...
the_coords = '';

for (i = 0; i < json_route.route.shape.shapePoints.length; i++) {
if (i == 0) {
the_coords = the_coords + '[' + json_route.route.shape.shapePoints[i+1] + ',' + json_route.route.shape.shapePoints[i] + ']';
}
else {
if ((i % 2) == 0) {
the_coords = the_coords + ',[' + json_route.route.shape.shapePoints[i+1] + ',' + json_route.route.shape.shapePoints[i] + ']';
}
}
}

//# Create the lineString json (text) of the route ...
var my_lineString = '{\”type\”: \”Feature\”, \”properties\”: {}, \”geometry\”: {\”type\”: \”LineString\”, \”coordinates\”: [‘ + the_coords + ‘]}}’;

//# Create le lineString json (object) of the route ...
var lineString = JSON.parse(my_lineString);

//# Set the unit measure and calculate the buffer using Turf.js ....
var unit = 'meters';
var buffered = turf.buffer(lineString, 1, unit);
var result = turf.featurecollection([buffered]);

//# Convert to string the buffered json ....
var my_json = JSON.parse(JSON.stringify(result));

//# Create an empty Polygon json to put in OSM Building map ....
var geojson_route = {
type: 'FeatureCollection',
features: [{
type: 'Feature',
properties: {
color: '#FF0080',
roofColor: '#ff99cc',
height: 0,
minHeight: 0
},
geometry: {
type: 'Polygon',
coordinates: [
[
]
]
}
}]
};

//# Add the coordinates at the Polygon json bringing them from the buffered json ....
for (var i = 0; i < my_json.features[0].features[0].geometry.coordinates[0].length; i++) {
geojson_route.features[0].geometry.coordinates[0][i] = my_json.features[0].features[0].geometry.coordinates[0][i];
}

//# Add the Polygon json to the map ....
osmb.addGeoJSON(geojson_route);

//# Refresh of the map to show the labels ...
map.setPosition(map.getPosition());

Ovviamente per maggiori dettagli mi potete contattare direttamente.

Numeri civici Open Data in Italia: disponibile la release 3.0 della raccolta

A febbraio 2015 ho pubblicato la seconda versione della raccolta di quelli che sono i numeri civici georiferiti open data disponibili nel panorama italiano.

E’ giunta quindi l’ora di un ulteriore aggiornamento, per cui ora è rendo disponibile la release 3.0 della raccolta stessa.

La raccolta è resa disponibile con licenza CC0 1.0 Universal: ovviamente per i singoli dataset restano valide le licenze originali che sono riportate nella raccolta stessa.

Con questo aggiornamento siamo arrivati a 188 dataset diversi : ci sono aree ancora completamente vuote, intere regioni in cui mancano dati, regioni per cui vi sono dati ridondanti, ecc … ma i numeri stanno crescendo

Ecco quali sono “release notes” di questa versione della raccolta:

• verificati, per tutti i dataset già esistenti, i link di pubblicazione e download: nel tempo alcuni erano stati cambiati dagli Enti
• verificate tutte le licenze d’uso: anche qui vi sono casi in cui le licenze sono state modificate
• aggiunti nuovi dataset, in particolare:
  • Comune di Storo
  • Provincia Autonoma di Bolzano
  • Regione Piemonte
  • Regione Lombardia

La percentuale dei numeri civici resi disponibili come tali, e non “derivati” da altri tematismi,  sale dal 10% al 25 % sul totale delle informazioni raccolte e quindi un buon risultato in termini di crescita  (la prima versione vedeva una percentuale del 5%)

Come consueto i dati sono consultabili via web grazie ad un piccolo esempio in web mapping basato su HTML, Javascript e Leaflet.

I dati sono anche resi consultabili, da un punto di vista geografico, usando il software open source QGIS:

• progetto QGIS + dati in formato Spatialite

A differenza delle versioni precedenti della raccolta, viste le dimensioni raggiunte, non mi è più stato possibile rendere disponibile anche i dati in formato ESRI shapefile insieme al progetto QGIS di consultazione. Resta comunque possibile, per chi interessato, poter scaricare i singoli dataset in formato ESRI shapefile e convertiti un WGS84 utilizzando i link di download resi disponibili all’interno del file della raccolta stessa

Ricordo una breve nota tecnica: per rendere operativo lo sfondo OpenStreetMap è necessario che, qualora si operi su una rete locale, si verifichi la corretta configurazione del proxy, e che, nel QGIS utilizzato, sia presente ed attivo il plugin OpenLayers.

I progetti QGIS sono stati realizzati con la versione 2.6.1 (Brigthon).

Segnalazioni di dati mancanti per aggiornare la raccolta sono particolarmente gradite …. grazie sin da ora!

Numeri civici Open Data in Italia: disponibile la release 2.0 della raccolta

A settembre 2014 ho pubblicato la prima versione della raccolta di quelli che sono i numeri civici georiferiti open data disponibili nel panorama italiano, ripromettendomi di rilasciare un aggiornamento ogni trimestre.

Un po’ in ritardo rispetto alle previsioni ma riesco a mantenere ora la promessa e quindi ecco pronta la release 2.0 della raccolta stessa (il totale di ciò che ho raccolto è reso liberamente disponibile nel rispetto delle licenze d’suo dei dati originali).

Quali sono le aggiunte? Non moltissime in termini di numero di Enti ma direi, discrete in termini di volumi di civici georiferiti aggiunti in quanto vanno ad aggiungersi ben 4 Regioni che hanno reso open data questo livello informativo.

L’elenco completo delle aggiunte di questa release è il seguente:

• Comune di Rovereto
• Comune di Verona
• Regione Toscana
• Regione Umbria
• Regione Sicilia
• Comune di Modena
• Regione Sardegna
• Comune di Verona
• Comune di Biella
• Provincia di Biella

Alcune di queste fonti informative sono già state oggetto di import nella base dati di OSM (Comune di Biella), per altre (Regione Sardegna), l’attività è, ad oggi, in corso e altre lo potrebbero diventare a seconda della compatibilità della licenza d’uso.

La percentuale dei numeri civici sale dal 5% al 10 % sul totale delle informazioni raccolte e quindi un buon risultato in termini di crescita.

I dati sono consultabili via web grazie ad un piccolo esempio in web mapping basato su HTML, Javascript e Leaflet.

Analogamente alla release 1.0 tutti i dati sono anche resi consultabili, da un punto di vista geografico, usando il software open source QGIS, in due modalità:

• progetto QGIS + dati in formato ESRI shapefile
• progetto QGIS + dati in formato Spatialite

Ricordo una breve nota tecnica: per rendere operativo lo sfondo OpenStreetMap è necessario che, qualora si operi su una rete locale, si verifichi la corretta configurazione del proxy, e che, nel QGIS utilizzato, sia presente ed attivo il plugin OpenLayers.

I progetti QGIS sono stati realizzati con la versione 2.6.1 (Brigthon).

La mappa nazionale inizia a riempirsi di pallini colorati come vedete sotto, anche se ci sono ancora parecchi buchi e regioni in cui, per il momento, non sono riuscito a rintracciare nulla per cui chiedo, a chiunque interessato, di farmi avere riferimenti utili così che possano essere inclusi nei successivi rilasci.

Una nota doverosa, relativamente a questa release, sono i ringraziamenti a coloro che, in varia forma, mi hanno dato una mano con i loro contributi quindi procedo:

• Giovanni Allegri (@_giohappy_), per i dati di Regione Toscana
• Maurizio Napolitano (@napo), per i dati di Regione Umbria
• Andrea Borruso (@aborruso), per l’ispirazione metodologica che ho utilizzato per i dati di Regione Sicilia
• Francesco Fiermonte (@ffierm), per il tempo speso a farmi da “tester”

In conclusione una riflessione: questo lavoro mi costa fatica, tempo da dedicarci, ecc …., quindi ci tengo ma al tempo stesso sarei lieto di chiuderlo, definitivamente, nel momento in cui vi fosse la disponibilità dei civici georiferiti open data per come prevista nell’elenco dell’Agenda Digitale 2014: purtroppo al momento le date indicate sono state, più o meno ampiamente, disattese, …… ma resto fiducioso …… 🙂

 

Open data e Open service basati su standard: come ottenere lo shapefile dei Numeri Civici Open Data della Regione Sicilia partendo dai servizi resi disponibili

Tutto è nato da una mail di Andrea Borruso, apparsa sulla lista GFOSS proprio alla vigilia di Natale, in cui si annunciava, da parte della Regione Sicilia e per una serie di comuni, la disponibilità, in modalità WFS, di un dataset dei numeri civici georiferiti.

I servizi sono fruibili direttamente da client diversi, desktop, web, mobile, ecc …. che ovviamente supportino lo standard OGC WFS,  cosa oramai ampiamente diffusa, piuttosto facile da fare e alla portata di un’utenza, seppur tecnica, piuttosto ampia.

Con una chiamata standard è anche possibile avere l’elenco dei comuni per cui sono disponibili i dati dei numeri civici: la chiamata è la seguente:

ogrinfo -ro wfs:"http://map.sitr.regione.sicilia.it/ArcGIS/services/CART_2000/Numeri_Civici/GeoDataServer/WFSServer"

Bello ma, per il mio interesse cioè quello di raccogliere i civici open data disponibili sul panorama nazionale, mancava una visione di insieme che mi fornisse TUTTI i civici a livello regionale.

Ma, essendo tutto basato  su standard, si trattava solo di avere un po di voglia e tempo per fare un interessante (??? 🙂 ) esercizio informatico e “rinfrescare” alcune conoscenze messe un po’ da parte negli ultimi tempi.

Provo a riassumere quanto fatto, primo per mie note personali, ma anche perchè credo / spero possa interessare a chi voglia /debba poter replicare un’esigenza analoga.

Premetto che quello indicato NON è l’unico modo possibile per raggiungere l’obiettivo, ve ne possono essere diversi altri, anche più “eleganti”.

In tutto è organizzato in 3 passi logici.

Step 1: scaricare i dati collegandosi ai servizi

Nota organizzativa: gli eseguibili shell che illustro nel seguito operano nel rispetto di questa organizzazione su file system:

I servizi sono esposti in WFS e quindi possono essere contattati via chiamata http ottendo in risposta, tra le altre cose, il dato in formato GML.

Purtroppo gli attuali servizi non permettono di ottenere i dati in formati diversi.

In questo caso, essendo 376 i comuni da scaricare, e quindi le chiamate da fare, ho creato un piccolo eseguibile shell, lanciabile da linea di comando, che, usando il comando CURL disponibile in ambiente Linux e/o Windows a seconda delle installazioni (nel mio caso ho utilizzato CygWin …), scaricherà, completamente, tutti i singoli GML, uno per ogni comune.

La chiamata, per un singolo comune è la seguente …

curl "http://map.sitr.regione.sicilia.it/ArcGIS/services/CART_2000/Numeri_Civici/GeoDataServer/WFSServer?SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&TYPENAME=CART_2000:NumeriCivici_81008_Erice&SRSNAME=EPSG:4326" -o CiviciComuniSicilia/GML/81008_Erice_4326.gml

Visto che i comuni erano molti ho realizzato un programmino shell, denominato DownloadCiviciByCurl.sh, reso parametrico ….

echo "Download civici $1 ......"
curl "http://map.sitr.regione.sicilia.it/ArcGIS/services/CART_2000/Numeri_Civici/GeoDataServer/WFSServer?SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&TYPENAME=CART_2000:NumeriCivici_$1&SRSNAME=EPSG:4326" -o CiviciComuniSicilia/GML/$1_4326.gml
echo "Sleeping for 30 sec: don't load too much the server ...."
sleep 30

il quale è poi richiamabile da un programmino di lancio denominato LauncherDownloadCiviciByCurl.sh…

echo "Starting download civici Sicilia ......"
sleep 5
./DownloadCiviciByCurl.sh 81008_Erice
./DownloadCiviciByCurl.sh 83040_Limina
./DownloadCiviciByCurl.sh 87001_Aci_Bonaccorsi
......
......

da completare con l’elenco dei comuni ricavato dall’istruzione ogrinfo mostrata in precedenza.

I files .sh sono mantenuti nella cartella “Work”.

Ecco uno snapshot dell’esecuzione di questo primo passo …

Step 2: convertire i dati in formato ESRI shapefile

Il mio obiettivo finale era quello di avere un unico file con tutti gli indirizzi georiferiti disponibili per la Regione Sicilia, e quindi dovevo in un qualche modo unire tra loro, geograficamente, i singoli files GML scaricati.

L’aggregazione geografica di più files GML non sembra sia possibile (dopo una veloce ricerca sul web …), e quindi ho deciso di convertire ogni singolo file GML in uno shapefile per poi unificali tra loro in uno step successivo.

Per eseguire l’operazione di cui sopra ovviamente il tool che meglio si adatta sono ancora le librerie GDAL con il seguente comando ogr2ogr

ogr2ogr -f "ESRI Shapefile" 81008_Erice_4326 CiviciComuniSicilia/GML/81008_Erice_4326.gml

Nel preparare questa trasformazione mi sono accorto che lo shapefile prodotto risultava privo del file di proiezione (.prj), e quindi, con una seconda operazione ogr2ogr ho provveduto ad aggiungere allo shapefile prodotto, il file .prj relativo al sistema di riferimento che volevo utilizzare (EPSG: 4326)

ogr2ogr -a_srs EPSG:4326 CiviciComuniSicilia/Shapefile/NumeriCivici_81008_Erice.shp 81008_Erice_4326/NumeriCivici_81008_Erice.shp

Anche in questo caso  ho poi realizzato un programmino shell, denominato ConvertShapefile.sh, reso parametrico ….

echo Convert $1 civici GML into ESRI shapefile .....
ogr2ogr -f "ESRI Shapefile" $1_4326 CiviciComuniSicilia/GML/$1_4326.gml
echo Adding .prj to $1 civici shapefile .....
ogr2ogr -a_srs EPSG:4326 CiviciComuniSicilia/Shapefile/NumeriCivici_%1.shp $1_4326/NumeriCivici_$1.shp
echo Delete temporary files .....
rm -R $1_4326

il quale è poi richiamabile da un programmino di lancio denominato LauncherConvertShapefile.sh …

echo "Starting converting civici Sicilia in shapefiles ......"
./ConvertShapefile.bat 81008_Erice
./ConvertShapefile.bat 83040_Limina
./ConvertShapefile.bat 87001_Aci_Bonaccorsi
......
......

I files .sh sono mantenuti nella cartella “Work”.

Ecco lo snapshot dell’esecuzione di questo secondo passo …

Step 3: creare un unico shapefile di dati

A questo punto non restava che “fondere” insieme i vari shapefile dei singoli comuni in un unico shapefile a livello regionale.

Anche qui viene in aiuto la libreria GDAL con le ogr2ogr che permettono di effettuare questa operazione eseguendo un semplice ciclo: anche in questo caso ho racchiuso il tutto in un programmino shell che ho nominato UnionShapefileComuni.sh

#!/bin/bash
for f in `ls *.shp`
do
echo "Append shapefile " $f " ....."
ogr2ogr -update -append civici_sicilia.shp $f -f "ESRI Shapefile" -nln civici_sicilia
done

Il file .sh è mantenuto nella cartella “Shapefile”.

Ecco uno snapshot dell’esecuzione di questo terzo passo …

Ed ecco che il gioco è fatto, replicabile e, volendo,  completamente automatizzabile mettendo i vari passi in un unico shell.

Il risultato è il seguente:

L’intero dataset è scaricabile e disponibile nel rispetto delle licenze originali dei dati di partenza (CC-BY SA).

Come detto in precedenza quello descritto non è l’unico metodo ma ve ne possono essere molti altri, anche più eleganti: ne cito uno, illustrato da Andrea Borruso, che mi sembra di particolare interesse e che si basa sul fatto che i servizi della Regione Sicilia sono contattabili anche via REST, e quindi, partedo da questo,  si potrebbe replicare l’esperienza fatta da Maurizio Napolitano nel caso di Regione Umbria.

Un primo utilizzo delle informazioni che ho aggreato? Per visualizzare i dati delle mia raccolta degli indirizzi georiferiti open data in Italia (di cui stò preparando la nuova release … stay tuned!!!): portando i dati su un db POSTGIS e poi usando TileMill ho prodotto i tiles che permettono di visualizzare rapidamente l’intero dataset insieme a tutti gli altri raccolti a livello nazionale.

Spero che queste info possano essere utili.

OSM & Pubblica Amministrazione: non è proprio collaborazione stretta ma i punti di contatto aumentano

Negli ultimi tempi chi segue un po’ le vicende e le attività su OpenStreetMap, e in generale i temi degli open  data (georiferiti), ha potuto notare che c’è stato un bel fiorire di iniziative che, a partire dai dati resi disponibili dalle P.A. e con licenze compatibili alla ODbL (Open Data Commons Open Database License), hanno portato ad incrementare i dati presenti nel data base di OSM

Cito i casi di:

• carta tecnica del Comune di Lecce caricati in OMS
• edificato dell’intera Regione Sardegna caricato in OSM
• autorizzazione al ricalco èper OSM delle ortofoto rilasciata da Regione Sicilia

Oltre a queste esperienze, che rappresentano se vogliamo un effetto collaterale, non direttamente strutturato, della pubblicazione di open data georiferiti, spicca sicuramente l’iniziativa di Regione Toscana che, sulla falsariga dell’accordo stabilito qualche anno fa con GFOSS.it nell’ambito del software open source in campo GIS, per prima in Italia su scala regionale, ha recentemente messo a disposizione come Open Data la produzione regionale della sua banca dati topografica in scala 1:2.000.

In tale iniziativa viene sottolineata la ferma intenzione di aprire un dialogo ed una collaborazione stretta con OpenStreetMap, con l’obiettivo di veicolare i dati della Regione Toscana (strade, civici, edifici, copertura del suolo, idrografia, toponimi, ecc.) all’interno di OSM, facendone crescere la qualità nell’ambito del territorio toscano e fornendo quindi, anche tramite la mappa pubblica, un servizio migliore al territorio regionale.

I dati messi potenzialente a disposizione sono molti: si parla, per ciascun comune, di oltre 90 livelli informativi in formato ESRI shapefiles.

La Regione ha dimostrato ampia disponibilità permettendo di estendere la possibilità di portare in OSM anche i dati dei livelli informativi di strade e civici.

Sembra quindi che per la prima volta, sul panorama nazionale, qualcosa si stia muovendo nella forma di una collaborazione strutturata ed ufficiale: si spera, e sarebbe auspicabile, che quanto fatto da Regione Toscana costituisca ben presto una best practise seguita da altre P.A.

Non sullo stesso livello di impatto ma iniziativa comunque ufficiale è anche la seconda edizione del Piemonte Visual Contest organizzato dal Consiglio Regionale del Piemonte, dal Consorzio TOP-IX , dal CSI Piemonte e altri, che per il 2015 è incentrato con un mappathon su OSM, segnale anche questo di un occhio di riguardo e di attenzione da  parte di una pubblica amministrazione nei confronti della realtà costituita da questa comunità mondiale.

Tutti gli esempi di cui sopra sono riferiti al flusso di dati “dalla P.A verso il  mondo OSM“, mentre meno battuta è ancora la strada inversa che permetterebbe, una volta aperta, di innescare invece aspetti decisamente interessanti.

In questo senso si iniziano però a smuovere un po’ le acque: andando oltre lo stretto rapporto OSM – PA ed iniziando ad affrontare le problematiche di un ciclo virtuoso di collaborazione  tra “neo-geografia” e la modalità classica della produzione dei dati geografici da parte della P.A, occorre citare il workshop sul tema dei dati geografici armonizzati che si è tenuto ad ASITA e che è stato sintetizzato nel post di Massimo Zotti sul “Collaudo collaborativo dei dati geografici“.

Nell’ambito del workshop si è discusso sull’adottare nuovi modelli di produzione e aggiornamento dei dati geografici, basati su servizi web centralizzati invece che sulle tradizionali  produzioni distribuite su client stand-alone e sul ripensamento dei processi della Pubblica Amministrazione secondo il  paradigma della neogeografia, che prevede il coinvolgimento degli  utilizzatori del dato geografico fin dalle prima fasi della sua produzione.

Mentre il ragionamento di cui sopra si svolge più su un piano organizzativo e di processo, occorre evidenziare che anche da un punto di vista prettamente tecnico iniziano ad affacciarsi tecnologie che potrebbero essere abilitanti: già da tempo i principali produttori commerciali di software GIS  propongono soluzioni per il version control dei dati spaziali ed ora anche le comunità software del mondo gis open source stanno presentando analoghe soluzioni. L’ultima nata in questo campo che sembra essere piuttosto promettente è Versio un distribuited version control per dati spaziali che viene proposto da Boundless.

Sembra quindi che ci siano convergenze e humus fertile per far maturare, o almeno intraprendere, iniziative volte ad una collaborazione fattiva e proficua tra il mondo della  VGI (Volunteered Geographic Information) o neo-geography, e di OMS in particolare, ed il mondo dei “authoritative data” offerti e gestiti dalla P.A.

Di lavoro da fare ce nè ancora molto ma se non si inizia sicuramente non lo si riesce a portare a termine ed invece, forse, si stanno finalmente muovendo i primi passi: se son rose fioriranno come si suol dire e, almeno personalmente, spero di vederle presto spuntare fiorite da qualche parte!!!

Numeri civici Open Data in Italia (hashtag #IndirizzatiItalia!): ce ne sono? Quanti sono? Chi li mette a disposizione? Dove sono?

Spesso a volentieri, seguendo le varie discussioni legate al geocoding di informazioni sulla base dell’indirizzo, si argomenta sulle potenzialità di georeferenziare oggetti sfruttando questa possibilità che, indubbiamente, permette di localizzare sul territorio molte informazioni.

Diversi sono gli sforzi di sensibilizzazione in tal senso: ultimi in ordine di tempo, la lettera aperta al Presidente del Consiglio Matteo Renzi sulla geo-localizzazione per i servizi ai cittadini  e il white paper sulla geo-localizzazione per i servizi ai cittadini, la cui stesura è in corso in modo collaborativo e sul quale, nel corso della prossima conferenza AM/FM il 25 Settembre a Roma, si terrà un convegno.

Argomento altamente dibattuto quindi la georeferenziazione per indirizzo ….. ma spesso se ne parla senza citare (o porre l’enfasi che si dovrebbe ….), quello che è l’elemento essenziale la cui disponibilità rende il tutto disponibile e fattibile, cioè l’indirizzo georiferito, al quale è poi possibile associare gli elementi che si intende localizzare / posizionare sul territorio stesso.

Per “indirizzo georiferito” si intende non tanto l’indirizzo espresso nei termini <via><n° civico>, con cui poi si effetta il geocoding usando strumenti e librerie commerciali e/o open source, ma, bensì, la coppia di coordinate che caratterizzano quell’indirizzo sul territorio.

• Queste informazioni ci sono da qualche parte?
• Sono liberamente disponibili / utilizzabili?
• Quanti ce ne sono di liberamente disponibili / utilizzabili?
• In quale modalità?
• Quali Enti li stanno mettendo a disposizione?
• Dove e come sono distribuiti sul territorio Nazionale?

Queste sono solo alcune delle domande che, personalmente, mi sono posto e a cui ho provato a cercare di dare una risposta.

Risposta sicuramente non esaustiva e definitiva, ma che al tempo stesso può essere un punto di partenza da integrare / arricchire con l’obiettivo di avere finalmente contezza di ciò di cui si stà parlando in modo oggettivo e tangibile rendendo queste informazioni disponibili nel loro insieme.

La mia ricerca è partita da quanto mette a disposizione per questa tematica OpenStreet Map con i suoi dati liberamente scaricabili. La situazione, come è normale attendersi per una comunità mondiale che si basa sul crowdmapping, è “a macchia di leopardo” , in special modo in Italia.

Ho poi proseguito sfogliando i vari geoportali e portali open data delle diverse Regioni, Province e Comuni Italiani per vedere se e quali di questi Enti mettessero a disposizioni i dati dei numeri civici georiferiti.

Con un po di pazienza sono arrivato al termine della mia ricerca ed il risultato non è stato esaltante.

Solo i seguenti Enti amministrativi mettono a disposizione questo livello informativo in modo esplicito:

• Comune Anzola dell’Emilia
• Comune di Torino
• Comune di Bologna
• Comune di Trento
• Comune di Cesena
• Comune di Rimini
• Comune di Pavia
• Regione Friuli Venezia Giulia

(NOTA: a questa lista va aggiunta la Regione Toscana che, il 22/09/14, ha dato notizia della disponibilità dei dati del proprio database topografico alla scala 1:2000, tra i cui livelli sono presenti  anche i numeri civici. News troppo a ridosso della pubblicazione di questo post per cui non ho avuto ancora il tempo di raccogliere ed integrare questi dati).

Una prima considerazione, oltre al plauso dovuto per la disponibilità offerta all’utenza per questi dati: se lo hanno fatto loro vuol dire che …. SI …. PUO’ …. FARE!!!

Un po’ poco però se lo immaginiamo rispetto al panorama nazionale.

Allora ho allargato un po’ la mia ricerca andando a cercare anche ciò che fosse stato reso disponibile come informazioni, legate a livelli informativi puntuali, che tipicamente avessero un indirizzo georiferito (se hanno un indirizzo ciò significa che questo esiste sul territorio ….)

Questa ricerca ha richiesto, ovviamente, molto più tempo, ma alla fine ha permesso di incrementare, sino agli attuali 149, il numero dei tematismi con indirizzi georiferiti potenzialmente disponibili  e, come effetto collaterale, anche individuare una serie di tipologie di livelli informativi che “tipicamente” sono messi a disposizione come open data georiferito, la cui distribuzione è la seguente:

Si noti come la tipologia dei numeri civici veri e propri rappresenti “solo” il 5% del totale delle informazioni raccolte.

Il totale di ciò che ho raccolto è reso liberamente disponibile nel rispetto delle licenze d’suo dei dati originali.

Nel documento è possibile trovare, per ogni livello informativo:

• i riferimenti relativi al nome dell’Ente che lo mette a disposizione in modalità open data
• la sua url di pubblicazione
• la sua url di download
• il riferimento della licenza d’uso del dato
• la url di download al dato trasformato in formato ESRI shapefile (senza alterazione della struttura dati), con sistema di riferimento WGS84

I dati sono anche resi consultabili, da un punto di vista geografico, usando il software open source QGIS, in due modalità:

• progetto QGIS + dati in formato ESRI shapefile
• progetto QGIS + dati in formato Spatialite

Una breve nota tecnica: è necessario, per la consultazione di livelli informativi del Geoportale Nazionale, che, qualora si operi su una rete locale, si verifichi la corretta configurazione del  proxy, e, per rendere operativo lo sfondo OpenStreetMap, che, nel QGIS utilizzato, sia presente ed attivo il plugin OpenLayers. I progetti QGIS sono stati realizzati con la versione 2.0.1 (Dufour).

Per una consultazione web ho invece realizzato un piccolo esempio in web mapping basato su HTML, Javascript e Leaflet.

Nel caso dell’applicazione web, per ragioni di semplificazione, i dati disponibili sono stati “aggregati” per Regione e/o Ente.

L’applicazione permette di:

• localizzare l’area di interesse per indirizzo o nome della località
• attivare / disattivare i layer di interesse (il dettaglio dell’indirizzo <via> <civico> è fornito solo alle scale di maggior dettaglio)
• interrogare interattivamente il livello informativo “Civici Geoportale Nazionale – (WFS)”

Per tutti i dettagli tecnici di approfondimento si rimanda al post relativo.

Questa è una semplice raccolta di informazioni “as-is” mirata a dare un quadro d’insieme a livello nazionale della libera disponibilità di questa tipologia di informazioni, e nulla è stato fatto per armonizzare tra di loro i dati o per controllarne la qualità, sia della georeferenziazione, sia dell’informazione associata: è possibili quindi, anzi direi che è praticamente certo, che vi siano livelli informativi diversi che riportino il medesimo indirizzo localizzato sul territorio in punti diversi. Questo è sicuramente un lavoro che sarebbe di gran valore aggiunto ma che va oltre gli scopi e le finalità di questo post.

Cosa si potrebbe fare a questo punto? Beh tantissime cose, a partire dall’ampliare la disponibilità di questo tipo di dato da parte sia della P.A. Locale (Regioni, Province e Comuni), seguendo l’esempio di quelle che lo hanno già fatto, ma anche da parte della P.A centrale, con il completamento e la disponibilità aperta del Anagrafe delle Strade e dei Numeri Civici (ma ovviamente con la georeferenziazione dei civici ….. non come recentemente è stato fatto da ISTAT …:-) …), che era stato annunciato nel Decreto Digitalia, rinominato “Ulteriori misure urgenti per la crescita del Paese” (D.L. n.179 del 18 ottobre 2012) e di cui non si più saputo molto a 2 anni di distanza.

L’informazione georiferita, e quindi anche, ed in particolare direi, quella georiferita o georiferibile per indirizzo, può infatti essere considerata un fattore importante anche come elemento di crescita per lo sviluppo del Paese, argomento ultimamente ampiamente dibattuto nel contesto nazionale: se ne sono accorte (anni fa direi ….), realtà commerciali mondiali quali Google e la stessa Apple (con meno successo … ),  e quindi potrebbe esserlo, con i dovuti rapporti di scala, anche per il panorama Italiano, iniziando a vedere le informazioni georiferite come “infrastruttura” per i servizi futuri, ma con orizzonti che devono essere brevissimi.

Il dato disponibile in modalità open e con licenza compatibile, potrebbe poi andare ad integrare  e completare la copertura del livello di civici per OpenStreetMap in Italia (che al momento non è esaltante e non paragonabile ad altre realtà europee quali, ad esmepio. la Germania … ),  rendendo ancora più ampia la diffusione su larga scala di questo livello informativo anche oltre i confini nazionali. Come esempio di campo di applicazione si pensi ad esempio ai diversi motori di calcolo percorsi open source già oggi disponibili  (OpenTriplanner, OSRM, Graphopper, ecc …), che si basano su dati OSM e che non hanno nulla da invidiare (anzi in alcuni casi e per alcune caratteristiche a volte si dimostrano anche migliori … ).

Per evitare che questo lavoro resti una mera “fotografia” ad oggi, ma abbia una sua vita ed evoluzione, mi propongo di mantenerne un aggiornamento più o meno trimestrale, continuando a monitorare ogni annuncio utile che mi possa permettere di individuare nuove disponibilità (ovviamente chi interessato e a conoscenza di dati che non compaiono ancora nella raccolta me lo può segnalare liberamente, e sarà mia cura andarli ad integrare e rendere disponibili, nella medesima modalità, in versioni successive della stessa), poi …. non pongo limiti!.

Chiudo con i dovuti e necessari ringraziamenti a tutti coloro a cui, in varia modalità ho “rotto” un po’ le scatole nell’arco temporale (più lungo del previsto ma il tempo è sempre poco ….), che ha richiesto questo lavoro: a tutti un grazie per il tempo, poco o tanto non importa, che hanno speso per rispondere alle mie domande e per il supporto fornito. Cito i nomi sparsi ……. @napo, @simonecortesi,  @sbiribizio, @aborruso, @Piersoft, @ffierm, Diego.

P.S: Last but not least … un ringraziamento particolare, con menzione, a mia moglie Mary per la pazienza e per il tempo che un po’ le ho rubato.

Un tranquillo week end …… con gli open data: Spaghetti Open Data 2014 (#SOD14)

Dal 28 al 30 Marzo 2014 a Bologna si è svolto l‘annuale raduno di Spaghetti Open Data (#SOD14).

Mi sono perso il primo giorno per ragioni di lavoro ma sono riuscito a seguire completamente gli altri due: è stato il mio primo SOD e devo dire che è stato, per varie ragioni, davvero interessante.

Provo a fare un breve resoconto anche se so che questo non renderà giustizia e non riusicrà a trasmettere l’atmosfera dell’incontro.

Dove si è svolto ….

Sede di Working Capital (Telecom Italia) che si trova qui

Location molto carina in pieno centro e in cui tutto ha funzionato a puntino, compreso il wi-fi messo a disposizione per tutto (credo > 100 persone), quindi doverosi complimenti all’organizzazione (ce ne si dimentica sempre, ma senza questo sarebbe stata dura …. e non volevo lasciarlo nei titoli di coda ….)

Su cosa ho lavorato …

Eh si a SOD14 si è …. lavorato … e di sabato! E gratis .. o meglio, a proprie spese! E si fa pure levataccia per arrivare in tempo!!

Il primo giorno infatti è stato dedicato a diversi hackaton: io ho partecipato a quello Open Data Census delle città Italiane, ma assicuro che c’era l’imbarazzo della scelta. Abbiamo lavorato  a coppie (a proposito, grazie Nicolò Gnudi per la collaborazione e la pazienza …), per aggiornare la situazione del censimento che prova a “misurare”, sulla base di alcuni indicatori individuati da OKFN, il livello e la qualità della pubblicazione di dati open nelle città italiane. Io e Nicolò ci siamo concentrati su Ferrara che ad inizio hackaton era  poco o nulla documentata e a fine giornata stazionava al quarto / quinto posto della classifica … non male, soddisfazione di aver fatto un buon lavoro (senza barare …. 🙂 …).

Nota: giusto oggi è apparso in rete un post che cita l’analoga iniziativa lanciata nel Regno Unito: nel post viene citato letteralmente … “The project is still in its information gathering stage so, at the time of writing, only 6 cities have their data partially, or fully, entered. The census for Italian cities, for example, is looking more complete“. Olè !!!!

Cosa ho imparato ….

Ho anche avuto modo di imparare parecchie cose. Il secondo giorno infatti è stato infatti dedicato a due mini-corsi: qui la scelta è stata davvero difficile e combattuta ed è stato un vero peccato dover rinunciare ad uno dei due. Alla fine ho optato per il Data visualization lab tenuto da Dataninja (Alessio Cimarelli) e Density Design (Giorgio Uboldi).

Per chi non ha potuto partecipare ecco il riferimento per le slide.

A livello tecnico (angolo geek ….), e solo per punti:

• la soluzione per la presentazione delle slide: basata su Reveal.js (open source)
• datawrapper : per fare grafici dinamici “al volo” e poi fare embedded in pagine HTML
• crossfilter: libreria javascript per fare dsahboard fatta su D3.js
• Gephi: libreria per rappresentare reti (Sigma.js per esportare su internet)
• Umap:  per fare geocoding su OSM
• RAW:  prodotto italiano realizzato da Density Design. Basato su D3.js ed Angular.js. A breve sarà personalizzabile. Uno degli aspetti più interessanti che lo differenziano da altre soluzioni in cloud è che i dati che l’utente utilizzo NON sono mantenuti server side ma restano sul browser dell’utente. Esporta sia in formato raster sia in formato vettoriale, e questa è la caratteristica più interessante. L’idea del prodotto è quella di creare semilavorati sui dati rapidamente da elaborare poi successivamente: volendo, ma non è la sua finalità, lo si può usare per pubblicare. Esporta in diversi formati. Può essere utile per produrre il JSON da dare poi in input a D3,js. Nel corso di SOD14 è stato annunciato chea breve uscirà la versione 2.0.
• D3.js: un’introduzione passo passo a questa spettacolare libreria javascript che permette di realizzare grafici, e non solo, dinamici lavorando interamente con il DOM nel browser. Segnalo queste librerie sempre basate sul prodotto:

  • NVD3.js – Grafici riutilizzabili

  • DC.js – Grandi dataset e dashboard composite
  • d3.chart – Framework per costruire grafici riutilizzabili
  • Rickshaw – Toolkit grafico per javascript
  • D3+Three.js – Data viz in 3 dimensioni!

Ma non è stato solo un raduno di “smanettoni” si è parlato e discusso, anche criticanmente ma in modo costruttivo, di cosa e come rappresentare dati: nei miei appunti è rimasto

Alberto Cottica (@alberto_cottica): la visualizzazione dei dati rappresenta la visione di chi la sta facendo, ma potrebbero essercene altre, anche, diverse

Alessandro Masserdotti (@ales9000): in realtà anche chi struttura i dati fa già una “visualizzazione” dei dati che rappresenta una sua visione

Alessio Cimarelli (@jenkin27): se ne esce documentando o spiegando chiaramente la metodologia, il ratio, che ci sta dietro: da usare NON nell’articolo del datajournalism ma da qualche parte perchè l’utenza è diversa.

Cosa ho visto ….

Tanta gente !!! Sicuramente più di un centinaio di persone

Cosa mi sono portato a casa …..

In ordine sparso (e alcune su cui riflettere …):

• vedere di persona e stringere mani di chi sino a poco prima era una foto in un browser, un testo di una mail o di un tweet …
• “bello quel post sul tuo blog!”  ….
• lavorare fianco a fianco con chi potrebbe avere la metà dei tuoi anni …..
• cenare all’aperto alle 10 di sera il 29 di Marzo !!!! ….
• che tanta gente si faccia dei chilometri e spenda gratuitamente uno dei primi week end di primavera per “lavorare” sui dati open, per insegnare ad altri, per scambiare idee e opinioni …
• il rammarico di non aver potuto partecipare a più cose sia a livello di hackaton (es. Gli OpenData per liberare l’Energia Potenziale dei beni confiscati alle mafie) ,  sia a livello di corso (es. Tutorial su Web Semantico e Open Data). …..
• vedere che in giro c’è tanta gente brava, che ne sa e con una gran voglia di fare …. questo lascia un po di speranza!!!

Ciao #SOD14 !!!!