Archivio

Archive for the ‘GIS’ Category

Realizzare automaticamente storytelling usando Mapillary? Ci si può provare …

2 ottobre 2016 4 commenti

Mapillary è un servizio per condividere foto georeferenziate sviluppato da una startup, con sede a Malmö, Svezia. I suoi ideatori vogliono rappresentare il mondo intero (non solo le strade) con delle foto. Ritengono che per coprire tutti i posti interessanti nel mondo siano necessari un progetto crowd-sourced indipendente e un approccio sistematico alla copertura di aree interessanti.

Si pongono quindi, fatte le debite proporzioni, in alternativa a Google Street View.

Contribuire è facilissimo: chiunque può scaricare l’app di Mapillary sul proprio smartphone / tablet ed iniziare a scattare foto muovendosi a piedi, in bici o in auto, effettuare poi l’upload sulla piattaforma, e dopo pochissimo tempo rendere disponibile il frutto del proprio “lavoro” al resto della community di Mapillary.

Tempo fa ho usato questo approccio per mappare l’intero mio comune.

Di chi sono le immagini caricate sul sistema e come si possono usare? Le immagini su Mapillary possono essere usate da chiunque secondo la licenza internazionale Creative Commons Attribution-ShareAlike 4.0 (CC-BY-SA).

Un permesso speciale è concesso per derivare dati dalle foto per contribuire ad OpenStreetMap.

Le tracce GPX possono essere usate senza restrizioni.

Sino a non molti mesi fà queste immagini erano consultabili solo attraverso il sito di Mapillary: interessante ma un po’ “chiusa” come possibilità.

A Febbraio 2016 però Mapillary se n’è uscita con Mapillary JS,  che è quanto segue (citando esattamente quanto pubblicato … )

“…MapillaryJS is a tool used for displaying street level photos anywhere on the internet. Today we are putting it into your hands. It enables you to add street level photos to your blog, website or even into your professional mapping applications. …”

E’ quindi ora possibile utilizzare le immagini di Mapillary all’interno di una qualunque applicazione web usando un’interfaccia Javascript che ne facilità la fruizione.

Tra gli esempi forniti con Mapillary JS, ha colpito la mia curiosità quello relativo allo storytelling.

Da qui ho iniziato a pensare se fosse possibile, per produrre il codice della pagina di esempio, automatizzare le scelta delle immagini e delle relative sequenze partendo da un percorso che l’utente poteva disegnare su una mappa.

Il risultato ora c’è ed è … SAMBA !!!  (il nome deriva dall’influenza del periodo olimpico che ha coinciso con lo sviluppo dell’applicativo??? 🙂 ….  comunque l’acronimo stà per Storytelling Author Mapillary BAsed).

samba

L’applicativo permette di scegliere una qualunque area del mondo, per nome o indirizzo, visualizzare su una mappa quelle che sono le tracce delle sequenze di immagini di Mapillary che sono disponibili per quell’area e, sulla base di queste, interattivamente, di impostare quelli che sono i punti di interesse per cui si vuole che il nostro percorso passi (sino ad un massimo di 25 punti …. ).

L’applicativo calcolerà il percorso ed individuerà quelle che sono le immagini di Mapillary più vicine ai punti del percorso stesso (nel verso della percorrenza … ), e proverà a proporre una prima versione dello storytelling di cui l’utente può fare il preview in una sorta di “filmato”.

Se il preview è giudicato soddisfacente l’utente può scaricare il codice sorgente HTML / Javascript per una sua esecuzione autonoma o per poter essere incluso nella pagina web del proprio sito.

Qualora nel preview vi siano immagini non corrette o che generano problemi nell’esecuzione del “filmato” stesso (situazione piuttosto comune …), o qualora l’utente desideri inserire dei piccoli commenti testuali in corrispondenza di alcune delle immagini, è possibile effettuare un raffinamento, deselezionando le immagini da escludere dalla restituzione e/o editando il testo.

Nuovamente sarà possibile effettuare un preview e/o scaricare il codice sorgente HTML / Javascript: il processo di raffinamento può essere eseguito più volte sino ad arrivare alla configurazione di gradimento.

Ogni passo è corredato da un help ed un filmato di esempio di utilizzo.

Riporto qui i filmati per completezza di informazione (nel loro insieme rappresentano una sessione di utilizzo completa).

Step 1

Step 2

Step 3

Step 4

Step 5

I vincoli per l’utilizzo sono i seguenti:

  • utilizzo di un browser di recente generazione e che supporti WebGL: l’applicazione è stata testata su Chrome e Firefox
  • numero massimo punti per il calcolo percorso: 25
  • non si possono usare lettere o caratteri speciali nel testo descrittivo che viene aggiunto all’immagine. Non è possibile usare tag HTML (es. per mettere link)

L’applicazione non è fruibile da smartphone / tablet in quanto risulta comunque difficoltosa l’interazione sulla mappa nel momento in cui si disegnano i punti di interesse o, peggio ancora quando li si desidera riposizionare / trascinare sulla mappa stessa.

Sono comunque fruibili da smartphone / tablet gli storytelling generati.

Esistono problemi noti, che sono:

  • il servizio di routing di MapBox ha un piccolo bug per cui, a volte, non riporta nel percorso l’ultimo punto (destinazione). Ho cercato di aprire una richiesta su StackExchange,  ma ad oggi non ho ancora avuto risposte, nemmeno da MapBox stessa. Il bug non è comunque bloccante anche se fastidioso

Ecco alcuni esempi di storytelling prodotti con SAMBA:

Il codice dell’applicazione e’ disponibile su GitHub con licenza Licenza MIT Copyright (c) [2014].

Ora non vi resta che provare … enjoy!

 

Annunci

Storytelling Author Mapillary BAsed (SAMBA): come è fatto “dentro”


In questo post vedo di fornire qualche dettaglio su quelle che sono le caratteristiche e soluzioni tecniche che stanno alla base di SAMBA, Storytelling Author Mapillary BAsed.

Schematicamente l’architettura della soluzione è la seguente:

architecture

L’applicazione è una tipica web mapping application realizzata in HTML / Javascript avvalendosi di una componente PHP 5 ospitata su web server Apache.

Per implementare le sue funzionalità utilizza una serie di librerie Javascript e di alcuni servizi e precisamente:

  • mapbox-gl-draw.js: fornisce il supporto per disegnare ed editare features su mappe basate su MapBox GL JS
  • Mapillary API: le API di accesso alle immagini e sequenze di Mapillary
  • MapBox Directions API: le API MapBox per il calcolo dei percorsi
  • MapBox GL Geocoder: il Geocoder per mappe basate su MapBox GL JS
  • Turf.JS: libreria Javascript realizzata da MapBox per il calcolo di funzioni geospaziali direttamente sul browser
  • il servizio (vector tiles), delle sequenze di Mapillary  pubblkicato su http://d25uarhxywzl1j.cloudfront.net/v0.1/{z}/{x}/{y}.mvt

Il codice dell’applicazione e’ disponibile su GitHub con licenza Licenza MIT Copyright (c) [2014].

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

29 maggio 2015 7 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!

 

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!!!

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.

foss4g2015_c

FOSS4G2015-EU

 

 

 

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!!!

 

Quel fattaccio brutto dell’Agenzia delle Entrate: the day after …


E come è andata a finire oggi? Direi due notizie sulle altre:

La prima è la risposta ufficiale di Agenzia delle Entrate che potete vedere sotto …

RispostaAgenziaEntrate

In parte era prevedibile, e lo avevo anticipato nel mio post di ieri (troppo facile fare il profeta in questo caso …), ma almeno è una risposta e dobbiamo accontentarci.

A questo punto aspettiamo la presa di posizione di SOGEI e vediamo.

La seconda è il ripristino delle regole: da oggi nella mappa di Geopoi di campeggia, correttamente,  in basso a destra, la citazione della licenza di OpenStreetMap

LicenzaOSM-OK

Va quindi dato atto ad Agenzia delle Entrare di aver ripristinato il rispetto delle regole in un solo giorno dopo aver sollevato la questione. Bene!

Al tempo stesso fa un po effetto vedere, su una web application della Pubblica Amministrazione che detiene dati territoriali, il riferimento all’uso di dati di una comunità open source: un bel punto segnato dal mondo del crowdsourcing!

Ora, come anticipato ieri, sarebbe il caso di NON fermarsi e fare diventare questo il primo passo di in cammino comune: la disponibilità della comunità OSM è dichiarata !!

DisponibilitaOSM-1

DisponibilitaOSM-2