Come convertire indirizzi in coordinate geografiche (geocoding) usando i servizi WFS del GeoPortale Nazionale e Open Refine
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:
- url: http://wms.pcn.minambiente.it/ogc?map=/ms_ogc/wfs/Numeri_Civici_2012.map
- capabilities: http://wms.pcn.minambiente.it/ogc?map=/ms_ogc/wfs/Numeri_Civici_2012.map&service=wfs&request=getCapabilities
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:
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:
A questo punto è possibile elaborare la query: un esempio è il seguente (l’indirizzo ricercato è Berbenno, Via Milano 55):
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&SERVICE=WFS&VERSION=1.1.0&REQUEST=DescribeFeatureType&TYPENAME=IN.NUMERICIVICI.2012&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&SERVICE=WFS&VERSION=1.1.0&REQUEST=DescribeFeatureType&TYPENAME=IN.NUMERICIVICI.2012&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.
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!
Open Location Code: “indirizzi” per qualunque cosa ovunque?
Questa sera mi sono imbattuto in un post di Google Open Source Blog dal titolo quanto mai accattivante e che comunque attira l’interesse per chi si occupa di georeferenziazione per indirizzo: Open Location Code: Addresses for everything, everywhere
Sembra che BigG stia provando a tirare fuori una cosa che potrebbe diventare un (piccola? grande? lo vedremo solo vivendo …), rivoluzione nel campo della georeferenziazione (tra l’altro applicabile sia in zone ove c’è la disponibilità degli indirizzi, sia in zone ove questa non è presente …), ….. SENZA fare uso di indirizzi !!!
Il tutto è spiegato, per sommi capi, direttamente sul sito di Open Location Code: il maggior dettaglio è disponibile direttamente su GitHub.
Open Location Code assegna un “codice” ad ogni luogo sulle terra, codice derivato dalle coordinate latitudine e longitudine, disponibili ovunque: questi codici sono simili ad un “numero telefonico” – 8FQ93M9M+9PF, è ad esempio quello che individua la localizzazione del Museo Egizio di Torino -, ma che può essere abbreviato a sole 4 o 6 cifre quando combinate con la località (ad esempio la stessa localizzazione di cui sopra può essere espressa come 9M+9PF Centro, Torino, Piemonte, Città Metropolitana di Torino).
Ovviamente localizzazioni che siano vicine le une alle altre avrano codici simili.
Per la codifica è stato scelto un set di 20 caratteri calcolando tutte le possibili combinazioni di 20 caratteri da 0-9A-Z in modo che costituissero più di 10.000 parole in 30 lingue diverse, questo per evitare, per quanto possibile, che le combinazioni includessero parole riconoscibili.
Il set di caratteri individuato è il seguente: 23456789CFGHJMPQRVWX.
I primi quattro caratteri descrivono un’area di un grado di latitudine per uno di longitudine. Aggiungendo altri quattro caratteri al codice, l’area si riduce di 1/20-simo di grado per 1/20-simo di grado all’interno dell’area precedente. Proseguendo nello stesso modo, ogni coppia di caratteri riduce di 1/400-esimo l’area precedente (nota: è un principio, se vogliamo, che ricorda l’organizzazone a tiles un catalogo di immagini TMS o di un servizio WMTS …..)
Ovviamente con questa tecnica ogni location è in realtà un’area e non un punto, ma si arriva a celle relative ad aree sul territorio piuttosto ristrette, ad esempio 2.6m x 2.8m
Una location può essere convertita in un codice e un codice può essere riconvertito in una location in modo completamente offline: non ci sono tabelle dati o tabelle di look up e non sono richiesti servizi online.
L’algoritmo è pubblicamente disponibile e può essere usato senza alcuna restrizione (Apache License Version 2.0).
Esiste anche un sito demo che permette di ottenere gli open location codes navigando ed interrogando interattivamente una mappa.
Per il momento non ho avuto tempo di fare prove, ma mi sembra una cosa interessante da approfondire ….
GeoWave “estende spazialmente” i “big data”?
Sembra che si inizi a pensare di utilizzare sul serio la componente spaziale dell’informazione anche nel mondo dei “big data”: un articolo interessante riporta i piani di un progetto ambiziono di GeoWave.
I pezzi salienti dell’articolo sono i seguenti:
- Geowave intends to do for “big data” databases (initially Apache Accumulo) what PostGIS does for SQL databases (PostgreSQL). GeoWave is open source software (licensed under Apache 2.0) that adds support for geographic objects, multi-dimensional indexing and geospatial operators to Apache Accumulo.
- Apache Accumulo is a distributed database that is based on Google’s BigTable design and is built on top of Apache Hadoop and other Apache projects.
- GeoWave includes a GeoServer plugin to enable geospatial data in Accumulo to be shared and visualized via GeoServer OGC standard web services. It provides plugins to connect the popular geospatial toolset GeoTools and the point cloud library PDAL to an Accumulo based data store. The PDAL plugin makes it possible to interact with point cloud data in Accumulo through the PDAL library.
- The GeoWave project Work plans to extend the same geospatial capabilities to other distributed key-value stores in addtition to Accumulo. The next data store will be HBase. It also will support other geospatial frameworks in addition to GeoTools/GeoServer. Mapnik is the next geospatial framework targeted for GeoWave support. GeoWave says it is very interested in GeoGig and support for this geospatial data versioning library is currently on their backlog. GeoGig takes the concepts used in distributed version control such as Git and applies them to versioned spatial data.
Sicuramente un progetto da tenere in osservazione …..
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à:
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!!!
FOSS4G 2015: mondiale in Corea del Sud (Seoul) ed europeo in Italia (Como)
Sono state decise le sedi di FOSS4G 2015: l’evento mondiale si terrà in Corea del Sud, a Seoul, dal 14 al 19 Settembre 2015 presso il COEX Convention & Exhibition Center, mentre quello europeo si terrà in Italia, a Como, dal 15 al 17 Luglio 2015 presso il Politecnico di Milano in Como.
GFOSS DAY 2014: Ancona 06-07 Novembre 2014
La Settima conferenza italiana sul software geografico e sui dati geografici liberi si terrà ad Ancona dal 6 al 7 Novembre 2014 presso la Facoltà di Ingegneria e di Agraria dell’Università Politecnica delle Marche ad Ancona.
Il programma ufficiale definitivo è stato recentemente pubblicato.
La partecipazione alla conferenza è libera e gratuita ma è richiesta una registrazione (meglio anticipata) per consentire una migliore organizzazione dell’evento e garantire la stampa di badge e attestati.
L’accesso ai workshop è garantito fino al raggiungimento numero massimo di partecipanti.
Partecipate numerosi!!!
Numeri civici Open Data in Italia (hashtag #IndirizzatiItalia!): un po’ di dettaglio tecnico
Nel post relativo all’annuncio di Numeri Civici Open Data in Italia (hashtag #IndirizzatiItalia!) non mi sono dilungato nei dettagli tecnici per non appesantire: ora, per chi interessato, fornisco qui alcune informazioni.
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.
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)”
Visto che nell’applicazione di web mapping non era possibile elencare i più di 100 livelli informativi, questi sono stati raggruppati per Regione e/o Ente realizzando per ognuno di essi un singolo catalogo raster TMS usando come soluzione TileMill.
Per rendere più veloce la produzione dei vari cataloghi i dati, dopo essere stati trasformati in formato ESRI Shapefile e riportati in WGS84 (EPSG 4326), sono stati caricati in POSTGIS.
Sono anche disponibili due livelli informativi tratti dai geoservizi OGC offerti dal Geoportale Nazionale, il servizio WMS dei civici aggiornamento 2012 e il corrispettivo servizio WFS che permette l’interrogazione interattiva dei singoli numeri civici (funzionalità disponibile solo alle scale di maggior dettaglio onde evitare, da un lato, di richiedere un numero di features eccessivo al server del Geoportale Nazionale, e dall’altro di appesantire la fase di rendering sul browser).
Ovviamente sono disponibili diversi livelli informativi di sfondo (baselayer).
La modalità di pubblicazione in web mapping adottata, sebbene funzionale, ha il vantaggio di essere semplice e non richiede particolari necessità infrastrututrali, è sufficente un web server e un po’ di spazio disco. Al tempo stesso ha, indubbiamente dei limiti, il primo tra tutti è che la sua “semplicità” porta a perdere il livello di dettaglio dei dati raccolti, rendendoli disponibili solo in forma aggregata e come cataloghi raster TMS.
Una soluzione più “enterprise” richiede una disponibilità di un minimo di infrastruttura che al momento non ho adottato non disponendone. Non per questo non ho individuato una possibile soluzione che permetta, da un lato, di mantenere il dettaglio del dato e al tempo stesso permetta di garantire sia buone prestazioni in consultazione sia l’interoperabilità.
Tale soluzione è basata su una pila tecnologica completamente open source (quindi facilmente replicabile da chi interessato …), che comprende:
- data base: POSTGIS
- application server GIS: GEOSERVER
- web gis viewer: GeoExplorer
Questa rappresenta “una” scelta, non l’unica adottabile nel panorama del mondo gis open source come pure nell’ambito del mondo gis bastao su soluzioni proprietarie.
Implementativamente e per ragioni di praticità, ho utilizzato OpenGeoSuite 4.0.2 (usando una installazione di default, senza alcun parametro di ottimizzazione …), su un quadcore Intel con 8Gbyte di RAM e Windows 7 Enterprise: ovviamente questa non è da considerarsi una configurazione adatta per un ipotetico ambiente di produzione.
Mentre la scelta di POSTGIS come data base spaziale direi che è quasi “inequivocabile”, la scelta di GeoServer è stata indirizzata dal fatto che, oltre ad essere un ottimo gis server, ha una caratteristica che, nel caso specifico dei dati che si dovevano trattare, tornava molto utile, vale a dire la capacità di implementare un point clustering server side per facilitare la consultazione di layer con un gran numero di punti che, altrimenti, dovrebbero essere renderizzati sul client, con prestazioni non accettabili.
Il tutto, come valore aggiunto, realizzato usando modalità standard, vale a dire uno stile SLD, ed esponendo il layer in interoperabilità secondo i consueti standard OGC (WMS e WFS).
NOTA: l’esempio di stile SLD fornito dal tutorial Buondless non permette di interrogare i singoli punti e quindi ho dovuto leggermente modificarlo e lo rendo liberamente scaricabile.
Volendo approfondire questa funzionalità ho quindi adottato questa soluzione.
Ecco un video in cui, usando GeoExplorer (integrato in OpenGeoSuite …), è possibile consultare tutti i 149 layer messi a disposizione
mentre ecco un video in cui, alcuni dei layer dei civici puntuali sono consultati come layer WMS da un client QGIS
dimostrando quindi come, se ce ne fosse ancora bisogno, grazie all’adozione di servizi GIS esposti secondo standard di interoperabilità e con architetture in grado di scalare opportunamente sia possibile offrire dati geografici a diversi fruitori, sia gis desktop (commerciali e non), sia web browser (usando librerie open source quali OpenLayers, Leaflet, ecc .. , ma anche usando soluzioni commerciali), sia mobile, ma a questo punto diventa un puro esercizio informatico che non ha grande valore aggiunto quindi mi fermo qui.
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à:
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.
Cesare Gerbino GIS Blog 