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!

 

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

 

 

Quel fattaccio brutto dell’Agenzia delle Entrate ….


Oggi è successa una cosa brutta nel mondo delle mappe: una violazione di licenza esplicita, cosa di per se già poco piacevole, ma che a volte succede, solo che questa volta  l’autore della violazione è qualcuno da cui non te l’aspetteresti, qualcuno che in generale dovrebbe rispettarle le regole, spesso dettandole anche in modo  restrittivo, la pubblica  amministrazione nella figura dell’Agenzia delle Entrate.

Non ci credete? Leggete ed aprofondite allora i seguenti post:

Non entro nel dettaglio, credo che i due articoli di cui sopra siano più che esplicativi: se poi volete vedere le reazioni / commenti sui social ecco la raccolta dei tweet.

Tra l’altro l’operazione è stata fatta pure male o per lo meno con sufficienza, senza curarsi troppo di come i dati siano stati integrati, a volte malamente (rispetto ai dati originali)….

DuomoMessina

altre volte senza provvedere ad eliminare o nascondere le tracce della provenienza del dato che fanno inequivocabilmente vedere l’origine del dato stesso
EtichettaProvv

oltre ovviamente a non curarsi di citare le fonti e di rispettare le licenze

Di questa faccenda, di cui poi si finirà col  dire (semmai si dirà qualcosa ….), che non è l’Agenzia, che magari è opera di chi ha realizzato il sistema che a sua volta girerà  la  responsabilità a chi ha fornito di dati, ecc … , la cosa che fa più tristezza è che ci sia un organo istituzionale depositario dei dati ufficiali sugli immobili italiani e che  detiene direi per  lo meno strettamente questi dati, che NON usa gli stessi dati (che a questo punto uno inizia a chiedersi a che cosa servono visto che tutto l’operazione  non sarà stata fatta a costo zero … ), per le sue applicazioni web e i suoi servizi.

E non solo oserei dire …. Allargando il discorso, chi si occupa nel mondo IT di dati, informazione e servizi geografici sà che spesso ci si riempie la bocca di termini quali:

possibile che tra tutte queste fonti dati certificate, pubbliche (open data? lo dovrebbero essere o comunque un’Agenzia nazionali dovrebbe aver modo di accedere a quei dati … oltre le proprie ovviamente), authoritative, non ve ne erano di utili o non si è trovato un modo di utilizzarle e invece è risultato più facile e comodo accedere ai dati crowd?

Voglio fare uno sforzo di ottimismo (e non è proprio la mia specialità …), e magari pensare che questo “incidente” possa servire per essere l’inizio di qualcosa di più grande: non  voglio infatti pensare pensare che  tutto sia successo e sia stato fatto  solo perchè “era più facile” o per “non conoscenza” (!!!!), ma per una ammissione, anche implicita, della bontà e  dell’utilità dei dati di OSM raccolti grazie allo sforzo, tempo, capacità e voglia distribuita di tante persone che vedono in questo un valore aggiunto.

Questa “ammissione” potrebbe ora fare un passo in più e cercare ora una collaborazione virtuosa che in tante aree locali è già iniziata e dà buoni frutti, per raggiungere insieme  il traguardo di liberare dati importanti anche per promuovere, nei fatti, quello sviluppo e quella crescita del Paese di cui tanto di parla senza azioni concrete.

Credo che i tempi e le condizioni siano oramai più che maturi.

Se invece tutto questo non porterà a nulla e si risolverà “as usual”, all’italiana, in un nulla di fatto vorrà dire che continuiamo a non imparare e ripartire dagli sbagli, ma continuiamo ad arroccarci  a difendere posizioni oramai, tra l’altro, sempre più traballanti.

Quindi, eh dai…#AgenziaUscite che noi ci siamo !!!!!!!!!!!!

P.S

Ho mutuato il titolo da un tweet di @sbiribizio di oggi che mi era piaciuto particolarmente

GeoPackage: un webinar OGC per saperne un po di più


E’ recente la notizia dell’adozione del GeoPackage Standard per le soluzioni mobile da parte dell’OGC.

Lo standard GeoPackage definisce un container SQLite aperto, non proprietario e platform indipendent per distribuire e utilizzare dati geospaziali: questo approccio permette di semplificare le fasi di sviluppo e offre alle applicazioni accesso ad un ampia varietà di servizi di geoprocessing web based.

Ora lo stesso OGC diffonde un webinar di un’ora in cui viene data una panoramica delle applicazioni e delle risorse che gli sviluppatori possono utilizzare per iniziare a sfruttare il nuovo standard.

Gli obiettivi del webinar sono quelli di illustrare:

  • come GeoPackage Standard permette agli sviluppatori di soluzioni mobile di entrare in contatto con dati e servizi di localizzazione cloud-based
  • come GeoPackage Standard lavora in situazioni dove l’accesso Internet è intermittente o completamente assente
  • come GeoPackage Standard è utile per applicazioni mobili fornite a squadre di lavoro sul territorio fornendo informazioni durante un evento di emergenza
  • come le API del GeoPackage Standard aumentano l’interoperabilità cross-platform di app e web services in un ambiente mobile

Fonte: Directions Magazine

Categorie:GIS, Mobile Tag:,

We want Italy in the INSPIRE Registry

10 febbraio 2014 1 commento

Hashtag: #italy4INSPIRE

Premise

According to INSPIRE each Member State must provide at least one endpoint for the discovery of national metadata.

To date, the majority of Member States (23 out of 28) met this requirement by registering its national endpoint in the INSPIRE geo-portal :

http://inspire-geoportal.ec.europa.eu/INSPIRERegistry/

In particular it’s worth noting that some Member States have recorded more than one endpoint, e.g. Austria, Belgium and Latvia : it is also possible to register multiple national endpoints.

In spite of this, Italy has not yet registered its endpoint for the discovery service.

In order to get this registration, a simple communication ( e-mail ) of the INSPIRE National Contact Point addressed to the JRC (michael.lutz@jrc.ec.europa.eu) is needed.

Question

Why the CSW service exposed by the RNDT has not yet been registered as one of the Italian endpoints?

From the regulatory point of view , both the transposition of the INSPIRE Directive (Legislative Decree 32/2010 ) and the Codice dell’Amministrazione Digitale report that RNDT is the national reference in this context :

The national repertoire of spatial data, [… ] is the national catalog of metadata for spatial data sets” (Legislative Decree 32/2010 , Article 5) (1)

From the technical and operational point of view, otherwise, the tests carried out in July 2013 and January 2014 by the Joint Research Centre of the European Commission ( upon request of the Agenzia per l’Italia Digitale) have shown that the CSW service and almost all of the metadata harvested are fully compliant to the provisions of Regulations 1205/2008 (2)  (metadata) and 976/2009 (3)  (network services) of the European Commission, as well as the related Technical Guidelines ( 1.2 of 2010 (4)  for metadata , and 3.1 of 2011 (5) for discovery services) .

Notably the test performed in January 2014 reported 4412 metadata “passed” and 412 “passed with warnings ” out of a total of 5540 ” harvested “metadata  (the total available metadata in the RNDT are 6143) .

The level of compliance to INSPIRE is almost complete for the metadata related to data (4415 of 4462) (6) .

This is an important result and it is noteworthy better than the results obtained by other Member States.

The full report is available at this address :

http://inspire-geoportal.ec.europa.eu/resources/sandbox/INSPIRE-dc160d85-7f54-11e3-9486-d8d3855bd8fc_20140117-095358/services/1/PullResults/

We emphasize that it is important that the registration of the service is done as soon as possible because :

1) the availability of Italian metadata in the European catalog is needed to give visibility to the spatial information existing in Italy , in order to

i. support national and EU environmental policies;

ii. improve knowledge of and encourage investment in our country;

2) the initial availability of metadata can trigger a virtuous cycle by pushing government entities at every level to provide new metadata to RNDT,  to promote their activities at the international level;

3) to encourage the creation of innovative services by professionals, consultants and local SMEs, based on the availability of data, to the benefit of local authorities;

4) to instantiate the role of the Italian ” node ” within the European network ;

5) to give visibility and recognition to people who, at different scales, have actively worked for the implementation of infrastructures and services .

Conclusions

On the basis of the aforementioned considerations, we urge the INSPIRE National Contact Point to provide as soon as possible the URL of the RNDT CSW, in order to have the first italian endpoint registered in INSPIRE.


Signature (in alphabetic order)

  • Giovanni Allegri
  • Andrea Antonello
  • Andrea Borruso
  • Associazione italiana per l’informazione geografica libera – GFOSS.it
  • Stefano Campus
  • Giovanni Ciardi
  • Piergiorgio Cipriano
  • Bruno Conte, Social4Social
  • Simone Cortesi
  • Laura Criscuolo
  • Antonio D’Argenio, Nadir
  • Margherita di Leo, Joint Research Centre
  • Alessio Di Lorenzo
  • Gianfranco Di Pietro, Geofunction
  • Antonio Falciano
  • Sergio Farruggia, Stati Generali dell’Innovazione, AMFM GIS Italia
  • Daniela Ferrari
  • Maurizio Foderà, Kartoblog
  • Antonio Fregoli, MNDAssociation
  • Pietro Blu Giandonato
  • Cesare Gerbino
  • Simone Giannecchini
  • Nicola Guarino, ISTC-CNR
  • Simone Lella
  • Walter Lorenzetti, gis3w
  • Jody Marca
  • Flavia Marzano, Stati Generali dell’Innovazione e Rete WISTER
  • Giacomo Martirano, Epsilon Italia, coordinatore progetto smeSpire
  • Stefania Morrone, Epsilon Italia
  • Alessandro Oggioni
  • Mariella Pappalepore, Planetek Italia
  • Lorenzo Perone
  • Emma Pietrafesa, Stati generali innovazione (Rete WISTER)
  • Renzo Provedel, Stati Generali dell’Innovazione, SOSLOG
  • Angelo Quaglia
  • Monica Sebillo, AMFM GIS Italia
  • Gian Bartolomeo Siletto
  • Claudia Spinnato, Consorzio TICONZERO
  • Franco Vico, AMFM GIS Italia
  • Fabio Vinci, Epsilon Italia
  • Massimo Zotti

If you want to add yourself in this list, put you name in a comment please.



[1]In addition, the Decree of November 10, 2011 concerning the technical rules of RNDT, issued by the Minister for Public Administration and Innovation in cooperation with the MoE provides that the RNDT, as integral part of the national infrastructure, provides the discovery services (art. 2 of the DM) and states that the publication of metadata in RNDT ensures the compliance with the requirements laid down in Regulation (EC) No. 1205/2008 and Legislative Decree no. 32/2010 (art. 4 of the DM).

Categorie:GIS Tag: