Archive

Posts Tagged ‘Numeri Civici’

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

27 settembre 2015 14 commenti

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%)

DistribuzioneCivici-V03

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

CiviciItalia2

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

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!

Come convertire indirizzi in coordinate geografiche (geocoding) usando i servizi WFS del GeoPortale Nazionale e Open Refine

29 maggio 2015 4 commenti

Quante volte si ha la necessità di convertire un indirizzo nella corrispondente coppia di cooordinate e quindi,  in un dato spaziale riutilizzabile?

E quante volte si avrebbe la necessità di  farlo su un insieme di indirizzi?

E quanti dati si potrebbero georiferire per indirizzo, portandoli inizialmente su una mappa, per poi usarli ed analizzarli con funzionalità “spaziali” incrociandoli con altri dati georiferiti?

Certo, a queste domande si potrebbe rispondere (e spesso si opera in tal modo ….), dicendo ” …. ma ci sono i servizi di geocoding di Google (o similari)!!“.

Vero, cosa buona e giusta, non si fà peccato, e chissà quante volte questi sono stati (e saranno …), utilizzati anche da coloro che abitualmente lavorano con i dati spaziali, compreso chi sta scrivendo questo post.

Però è altrettanto vero che esistono modalità alternative le quali possono fare uso di open data o open services pubblicamente disponibili.

Semplicemente ……. è meno noto e quindi non le si utilizza, sprecando piccole o grandi miniere che sono state faticosamente messe pubblicamente disponibili a tutti, e che quindi sono a tutti gli effetti ……”roba” nostra!

Con queste modalità è inoltre possibile evitare i limiti di licenza che si devono, professionalmemte, rispettare qualora si utilizzino le modalità di geocoding che si avvalgono, ad esempio, delle Google Geocoding API che riporto, per sintesi e chiarezza, in modo integrale (qui il link per il riferimento ufficiale completo) :

==================================================================================================

The Google Geocoding API has the following limits in place:

Users of the free API:
  • 2500 requests per 24 hour period.
  • 5 requests per second.
Google Maps API for Work customers:
  • 100 000 requests per 24 hour period.
  • 10 requests per second.

Note: These limits apply to the Google Geocoding web service which is primarily intended for server-side geocoding. If you are geocoding data in response to user input on the web, or on a mobile device, consider using client side geocoding.

These limits are enforced to prevent abuse and/or repurposing of the Geocoding API, and may be changed in the future without notice. Additionally, we enforce a request rate limit to prevent abuse of the service. If you exceed the 24-hour limit or otherwise abuse the service, the Geocoding API may stop working for you temporarily. If you continue to exceed this limit, your access to the Geocoding API may be blocked.

For guidance on strategies for optimizing quota usage, please refer to Usage Limits for Google Maps API Web Services and Geocoding Strategies.

The Geocoding API may only be used in conjunction with a Google map; geocoding results without displaying them on a map is prohibited. For complete details on allowed usage, consult the Maps API Terms of Service License Restrictions.

==================================================================================================

La frase The Geocoding API may only be used in conjunction with a Google map è fortemente vincolante e, sinceramente, non so quanto sia nota e rispettata.

Questo non vuol dire che gli open data, o gli open services, sui civici georiferiti siano liberamente utilizzabili e siano privi di licenza, tutt’altro: hanno anch’essi le loro, spesso e volentieri non sono le licenze più “permissive” come potrebbe essere una Creative Commons — CC0 1.0 Universal, ma al tempo stesso spesso permettono, nei rispetto delle stesse, un utilizzo più ampio dei dati georiferiti rispetto ad esempio a quelle di BigG .

Partendo da questi presupposti e avendo ad esempio ipotetico una serie di informazioni, magari su un documento testuale o un foglio elettronico, per le quali si abbiano gli indirizzi comprensivi di nome comune, via e numero civico, cosa serve quindi per poter essere operativi ?

Direi che servono potenzialmente due cose (oltre ad un pò di pazienza e la voglia di sporcarsi un pò le mani ….):

  • degli open data relativi ai civici georiferiti
  • degli open services relativi ai civici che permettano di essere interrogati per indirizzo restituendo, possibilmente in un formato standard,  le rispettive coordinate in un qualche sistema di riferimento

Sul primo punto direi che mi sono già espresso e trovate riferimenti in proposito in altri post in questo stesso blog: la P.A si stà pian piano muovendo (un pò in ordine sparso a dire il vero ….), sulla base di questo stò, faticosamente, cercando di mantenere una raccolta di quelli che sono gli open data sui civici ad oggi disponibili sul territorio  nazionale ed esisterebbe anche la teorica disponibilità dei civici georiferiti open data prevista nell’elenco dei dataset dell’Agenda Digitale 2014, purtroppo al momento ampiamente disattesa.

Sul secondo, che è quello di maggior interesse per gli obiettivi di questo post, non esistono molti open services che permettano di fare un geocoding, ma, fortunamente, in questo caso viene in aiuto il GeoPortale Nazionale e, per la precisione, il servizio WFS dei civici, nello specifico denominato Numeri civici – Aggiornamento 2012. 

Per tale servizio sono resi disponibili:

NOTA: ovviamente dello stesso dataset esiste anche il servizio WMS che trovate, con lo stesso nome, in questo elenco http://www.pcn.minambiente.it/PCNDYN/catalogowms.jsp?lan=it

Le opportunità che tale servizio offre sono:

  • implementazione secondo protocolli di interoperabilità standard (WFS)
  • intera copertura nazionale

E’ quindi possibile, potenzialmente, inviare una richiesta WFS al servizio facendosi restituire le features che soddisfano alle condizioni di richiesta: sono restitituiti tutti i dati relativi alle features stesse, comprese le geometrie e quindi si possono ottenere le coordinate di un qualunque indirizzo sul territorio nazionale.

Nella pratica, andando poi a vedere nel dettaglio, non è detto che ci siano tutti tutti gli indirizzi, ma ci si augura che la copertura, come anche la qualità dell’informazione, sia in continua crescita.

La disponibilità di un tale servizio è comunque, e sicuramente, elemento prezioso e tanto vale provare ad usarlo.

La prima cosa da fare è sapere quelle che sono le caratteristiche (metadati), del servizio e queste le si possono ottenere con la seguente chiamata al servizio wfs:

http://wms.pcn.minambiente.it/ogc?map=/ms_ogc/wfs/Numeri_Civici_2012.map&service=wfs&request=getCapabilities

Il secondo passo è sapere come è strutturata l’informazione associata, questo per individuare i campi su cui elaborare la richiesta: questo lo si può ottenere con la seguente chiamata al servizio wfs:

http://wms.pcn.minambiente.it/ogc?map=/ms_ogc/wfs/Numeri_Civici_2012.map&service=wfs&request=DescribeFeatureType

A questo punto è possibile elaborare la query: un esempio è il seguente (l’indirizzo ricercato è Berbenno, Via Milano 55):

http://wms.pcn.minambiente.it/ogc?map=/ms_ogc/wfs/Numeri_Civici_2012.map&VERSION=1.1.0&service=wfs&request=GetFeature&TYPENAME=IN.NUMERICIVICI.2012&Filter=<ogc:Filter xmlns:ogc="http://www.opengis.net/ogc"><AND><ogc:PropertyIsEqualTo matchCase="false"><ogc:PropertyName>comune</ogc:PropertyName><ogc:Literal>Berbenno</ogc:Literal></ogc:PropertyIsEqualTo><ogc:PropertyIsEqualTo matchCase="false"><ogc:PropertyName>nome</ogc:PropertyName><ogc:Literal>Via Milano</ogc:Literal></ogc:PropertyIsEqualTo><ogc:PropertyIsLike matchCase="false" wildCard="*" singleChar="." escapeChar="!"><ogc:PropertyName>civico</ogc:PropertyName><ogc:Literal>*55*</ogc:Literal></ogc:PropertyIsLike></AND></ogc:Filter>

la quale produce il seguente risultato (in evidenza la porzione di XML in cui vi sono le coordinate del punto)

<?xml version='1.0' encoding="ISO-8859-1" ?>
 <wfs:FeatureCollection
 xmlns:ms="http://mapserver.gis.umn.edu/mapserver"
 xmlns:gml="http://www.opengis.net/gml"
 xmlns:wfs="http://www.opengis.net/wfs"
 xmlns:ogc="http://www.opengis.net/ogc"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://mapserver.gis.umn.edu/mapserver http://wms.pcn.minambiente.it/ogc?map=/ms_ogc/wfs/Numeri_Civici_2012.map&amp;SERVICE=WFS&amp;VERSION=1.1.0&amp;REQUEST=DescribeFeatureType&amp;TYPENAME=IN.NUMERICIVICI.2012&amp;OUTPUTFORMAT=text/xml;%20subtype=gml/3.1.1 http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.1.0/wfs.xsd">
 <gml:boundedBy>
 <gml:Envelope srsName="EPSG:4326">
 <gml:lowerCorner>45.808287 9.575815</gml:lowerCorner>
 <gml:upperCorner>45.808287 9.575815</gml:upperCorner>
 </gml:Envelope>
 </gml:boundedBy>
 <gml:featureMember>
 <ms:IN.NUMERICIVICI.2012 gml:id="IN.NUMERICIVICI.2012.1225789">
 <gml:boundedBy>
 <gml:Envelope srsName="EPSG:4326">
 <gml:lowerCorner>45.808287 9.575815</gml:lowerCorner>
 <gml:upperCorner>45.808287 9.575815</gml:upperCorner>
 </gml:Envelope>
 </gml:boundedBy>
 <ms:boundary>
 <gml:Point srsName="EPSG:4326">
 <gml:pos>45.808287 9.575815</gml:pos>
 </gml:Point>
 </ms:boundary>
 <ms:id>13800026062251</ms:id>
 <ms:nome>Via Milano</ms:nome>
 <ms:civico>55</ms:civico>
 <ms:istat>03016023</ms:istat>
 <ms:cap>24030</ms:cap>
 <ms:comune>BERBENNO</ms:comune>
 <ms:nome_ted> </ms:nome_ted>
 <ms:provincia>BERGAMO</ms:provincia>
 <ms:regione>LOMBARDIA</ms:regione>
 </ms:IN.NUMERICIVICI.2012>
 </gml:featureMember>
 </wfs:FeatureCollection>

Nota tecnica solo per chi interessato: analizzando il contenuto del filtro WFS della richiesta si può notare che abbiamo tre condizioni in AND: in due casi si usa l’operatore ogc:PropertyIsEqualTo mentre in uno si usa invece l’operatore ogc:PropertyIsLike.

<AND>
 <ogc:PropertyIsEqualTo matchCase="false">
 <ogc:PropertyName>comune</ogc:PropertyName>
 <ogc:Literal>Berbenno</ogc:Literal>
 </ogc:PropertyIsEqualTo>
 <ogc:PropertyIsEqualTo matchCase="false">
 <ogc:PropertyName>nome</ogc:PropertyName>
 <ogc:Literal>Via Milano</ogc:Literal>
 </ogc:PropertyIsEqualTo>
 <ogc:PropertyIsLike matchCase="false" wildCard="*" singleChar="." escapeChar="!">
 <ogc:PropertyName>civico</ogc:PropertyName>
 <ogc:Literal>*55*</ogc:Literal>
 </ogc:PropertyIsLike>
</AND>

La ragione è legata al fatto che MapServer (che è l’application server GIS utilizzato dal GeoPortale Nazionale per esporre i servizi di interoperabilità OGC compliant), ha delle difficoltà a trattare numeri espressi come stringhe e quindi occorre necessariamente usare questo workaround: il dettaglio è trattato qui: http://osgeo-org.1560.x6.nabble.com/How-to-use-filter-encoding-in-MapServer-in-a-WFS-query-td5205424.html

 A questo punto quello che resta da fare sono due ulteriori passi:

  • automatizzare le richieste nel caso, tipico, di un elenco / insieme di dati geroriferiti per indirizzo
  • estrarre le coordinate dei civici così georiferiti dall’XML di risposta

Per entrambi può tornare utile come tool Open Refine da un lato, e le preziose indicazioni di questo post “Using OpenRefine to geocode your data with Google and OpenStreetMap API” da cui ho preso spunto ed ispirazione dopo aver assistito al mini-corso della sezione di  “da UglyData a Mappa in un pomeriggio: passando per OpenRefine, R e Turf.JS” (tenuto da Simone Cortesi, Andrea Zedda, Michele Ferretti e con la partecipazione di Fabrizio Tambussa e Stefano Sabatini che ringrazio in blocco…..), svoltosi nella giornata di chiusura del raduno Spaghetti Open Data 2015 (SOD15) a Bologna.

Il post di cui sopra illustra come fare geocoding usando i servizi di geocoding  Google Maps e OpenStreetMap, nello specifico MapQuest Nominatim API: ho pensato di provare ad estenderlo usando come servizio di geocoding il servizio WFS dei civici del GeoPortale Nazionale.

Premessa: non descrivo qui nel dettaglio come usare OpenRefine, è out-of-scope di questo post. Sulla rete è disponibile ampio materiale illustrativo e tutorial per muovere i primi passi.

Immaginiamo di partire da un foglio elettronico in cui vi siano i dati da georiferire con le informazioni di Comune, Via e Numero Civico, sommate ovviamente ad altre informazioni descrittive.

La prima cosa da fare, dopo aver ovviamente caricato il foglio elettronico in OpenRefine, è preparare i dati in modo che Comune, Via e Numero Civico siano rispettivamente su tre colonne separate che chiameremo “Comune“, “Ubicazione” e “Civico“, e che, qualora vi siano degli spazi, questi siano sostituiti dalla corrispondente sequenza di escape %20, se compaiono apostrofi questi siano sostituiti dalla corrispondente sequenza di escape %27, ecc … (questa operazione può essere fatta a mano o usando le funzionalità di OpenRefine).

A questo punto è necessario aggiungere una nuova colonna selezionando una colonna esistente e cliccando il tasto destro del mouse selezionando Edit column –>Add column by fetching URLs.

Nella nuova colonna che ad esempio chiameremo “PCN”, copiare la seguente chiamata http in GET parametrizzata:

'http://wms.pcn.minambiente.it/ogc?map=/ms_ogc/wfs/Numeri_Civici_2012.map&VERSION=1.1.0&service=wfs&request=GetFeature&TYPENAME=IN.NUMERICIVICI.2012&Filter=%3Cogc:Filter%20xmlns:ogc=%22http://www.opengis.net/ogc%22%3E%3CAND%3E%3Cogc:PropertyIsEqualTo%20matchCase=%22false%22%3E%3Cogc:PropertyName%3Ecomune%3C/ogc:PropertyName%3E%3Cogc:Literal%3E' + cells["Comune"].value + '%3C/ogc:Literal%3E%3C/ogc:PropertyIsEqualTo%3E%3Cogc:PropertyIsEqualTo%20matchCase=%22false%22%3E%3Cogc:PropertyName%3Enome%3C/ogc:PropertyName%3E%3Cogc:Literal%3E' + cells["Ubicazione"].value + '%3C/ogc:Literal%3E%3C/ogc:PropertyIsEqualTo%3E%3Cogc:PropertyIsLike%20matchCase=%22false%22%20wildCard=%22*%22%20singleChar=%22.%22%20escapeChar=%22!%22%3E%3Cogc:PropertyName%3Ecivico%3C/ogc:PropertyName%3E%3Cogc:Literal%3E*' + cells["Civico"].value + '*%3C/ogc:Literal%3E%3C/ogc:PropertyIsLike%3E%3C/AND%3E%3C/ogc:Filter%3E'

Quando si procederà, confermando, saranno inviate tante chiamate in GET quante sono le righe del foglio elettronico e per ognuna verrà mantenuto l’XML di risposta: per l’indirizzo in esame ecco l’XML risultato della chiamata con evidenziati i campi che contengono le coordinate dell’indirizzo

<?xml version='1.0' encoding="ISO-8859-1" ?>
 <wfs:FeatureCollection
 xmlns:ms="http://mapserver.gis.umn.edu/mapserver"
 xmlns:gml="http://www.opengis.net/gml"
 xmlns:wfs="http://www.opengis.net/wfs"
 xmlns:ogc="http://www.opengis.net/ogc"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://mapserver.gis.umn.edu/mapserver http://wms.pcn.minambiente.it/ogc?map=/ms_ogc/wfs/Numeri_Civici_2012.map&amp;SERVICE=WFS&amp;VERSION=1.1.0&amp;REQUEST=DescribeFeatureType&amp;TYPENAME=IN.NUMERICIVICI.2012&amp;OUTPUTFORMAT=text/xml;%20subtype=gml/3.1.1 http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.1.0/wfs.xsd">
 <gml:boundedBy>
 <gml:Envelope srsName="EPSG:4326">
 <gml:lowerCorner>45.808287 9.575815</gml:lowerCorner>
 <gml:upperCorner>45.808287 9.575815</gml:upperCorner>
 </gml:Envelope>
 </gml:boundedBy>
 <gml:featureMember>
 <ms:IN.NUMERICIVICI.2012 gml:id="IN.NUMERICIVICI.2012.1225789">
 <gml:boundedBy>
 <gml:Envelope srsName="EPSG:4326">
 <gml:lowerCorner>45.808287 9.575815</gml:lowerCorner>
 <gml:upperCorner>45.808287 9.575815</gml:upperCorner>
 </gml:Envelope>
 </gml:boundedBy>
 <ms:boundary>
 <gml:Point srsName="EPSG:4326">
 <gml:pos>45.808287 9.575815</gml:pos>
 </gml:Point>
 </ms:boundary>
 <ms:id>13800026062251</ms:id>
 <ms:nome>Via Milano</ms:nome>
 <ms:civico>55</ms:civico>
 <ms:istat>03016023</ms:istat>
 <ms:cap>24030</ms:cap>
 <ms:comune>BERBENNO</ms:comune>
 <ms:nome_ted> </ms:nome_ted>
 <ms:provincia>BERGAMO</ms:provincia>
 <ms:regione>LOMBARDIA</ms:regione>
 </ms:IN.NUMERICIVICI.2012>
 </gml:featureMember>
 </wfs:FeatureCollection>

Per evitare di sovraccaricare il server di chiamate (ed essere magari “bannati” dal GeoPortale …..), occorre essere professionali: la disponibilità di un servizio non ne implica un abuso e quindi è doveroso, ed opportuno, schedulare le chiamate verso il server in modo che siano sufficientemente distanziate nel tempo.

Open Refine lo permette di fare impostando un parametro “Throttle delay” quando si crea una colonna Add column by fetching URLs.

ThrottleDelay

Di default tale parametro è valorizzato a 5000 millisecondi ed è quindi opportuno aumentarlo così da ridurre il carico di richieste verso il server

Una volta ottenute le  diverse risposte, una per ogni riga del nostro foglio elettronico, quello che resta da fare è estrarre dall’XML le coordinate e riportarle in campi della tabella creati appositamente.

E’ quindi possibile creare due nuove colonne partendo dalla colonna “PCN”, rispettivamente “Lat” e “Lon”, per ognuna delle quali si dovranno applicare le seguenti regole espresse in linguaggio GREL:

  • toNumber(split(trim(substring(value.parseHtml().select(“gml|Point gml|pos”)[0].toString(),10, -10)), ” “)[0])
  • toNumber(split(trim(substring(value.parseHtml().select(“gml|Point gml|pos”)[0].toString(),10, -10)), ” “)[1])

Terminate queste attività è quindi possibile eliminare, se ritenute non più utili, tutte le colonne di servizio: quello che si otterrà è lo stesso foglio elettronico iniziale con due nuove colonne “Lat” e “Lon” in cui saranno valorizzate le coordinate dell’indirizzo (questo se la chiamata al servizio del GeoPortale ha dato esito positivo, quindi per un indirizzo presente nella base dati, altrimenti ovviamente non avremmo alcun valore).

Tutto sommmato piuttosto semplice rispetto al grosso valore aggiunto che si ottiene: buon divertimento!

 

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

4 febbraio 2015 8 commenti

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.

TortaCivici2

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

DettaglioMappa

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à:

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.

CiviciItalia2

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:

OrganizzazioneCartelle

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 …

DownloadCiviciSicilia

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 …

ConvertShapefile

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 …

Append

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

Il risultato è il seguente:

Sicilia1

Sicilia2

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:

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?

24 settembre 2014 4 commenti

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:

DistribuzioneTipologieSi 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à:

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.

DettaglioMappa

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.