GeoCoding: confronto tra motori sul campo

Gisgraphy è un framework open source che offre la possibilità di fare geolocalizzazioni  e geocoding via Java API o webservices REST.

Tra le altre cose offre una semplice interfaccia web che permette di confrontare, dato un indirizzo, i risultati di geocodifica dello stesso offerti da alcuni motori di geocoding e precisamente:

• Gisgraphy (in violetto nelle immagini di cui sotto)
• Nominatim (in giallo nelle immagini di cui sotto)
• Google Maps (in rosso nelle immagini di cui sotto)
• Yahoo! Placefinder (in blu nelle immagini di cui sotto)
• MapQuest (in verde nelle immagini di cui sotto)

E’ interessante vedere quali siano le differenze tra i vari motori.

Ad esempio ho provato a prendere come zona campione Bologna che, come in un precedente post, risulta essere una delle zone più densamente mappate in OSM,  e ho preso  come indirizzo in esame Via Borgonuovo 21.

Ecco il risultato dell’operazione di geocodifica in Gisgraphy

Come si vede i vari motori, restituiscono risultati diversi sebbene con errori di approssimazione accettabili: i più precisi nel caso specifico risultano essere MapQuest e Yahoo! Placefinder.

Fonte: @borruso

GeoGit: un nuovo tool (in alpha version), offerto da OpenGeo

Ho già citato in un precedente post l’esperienza della città di Chicago che, per condividere i propri dati con gli utenti ha pubblicato alcuni dei suoi open data georiferiti su GitHub sollecitandone i fork per gli aggiornamenti,

Ora è stato recentemente annunciato da OpenGeo un nuovo prodotto open source, rilasciato in alpha version, denominato GeoGit che ha come obiettivo (cito testualmente …), “…. to propose a new approach to working with spatial data, recommending a shift from treating spatial data simply as data to considering it as programmers do source code.”

Altra frase che ha suscitato il mio interesse è la seguente: “ …. We propose that organizations can benefit from crowdsourcing spatial data while retaining control over their information repositories and maintaining authoritative data sources.“

I principi su cui si basa questa iniziativa sono stati enunciati in tre white papers di cui riporto i riferimenti:

• Distributed Versioning for GeoSpatial Data (Part 1)
• Distributed Versioning for GeoSpatial Data (Part 2)
• Distributed Versioning for GeoSpatial Data (Part 3)

Provo a riassumere nel seguito quanto descritto nel dettaglio nei tre papers di cui sopra di cui consiglio la lettura e a cui comunque rimando.

La sfida che viene proposta è sicuramente innovativa, quanto mai impegnativa ma al tempo stesso molto affascinante: provare ad affontare il tema della creazione e gestione dei dati geografici con gli stessi principi collaborativi con cui viene trattata la gestione del codice sorgente.

Questo offre prospettive interessanti come pure l’obiettivo dichiarato di ridurre il tempo dedicato alla gestione del dato stesso per andare ad aumentare il tempo dedicato a creare valore aggiunto (funzionalità e servizi), su di esso

L’idea non è completamente nuova: alcuni tentativi di introdurre un sistema distribuito di controllo di versione sui dati geografici è già stato affrontato nel tempo da ESRI con ArcSDE e dalla stessa ORACLE con Workspace Manager.

Lo stesso progetto OpenStreetMap offre un sistema di versionamento, per quanto intorno ad un unico database centralizzato.

L’idea che guida OpenGeo nell’adattare i concetti chiave del versionamento distribuito tipico del mondo software ai dati spaziali, si basa su una similitudine che è la seguente: molte persone che usano il software non sono interessate ad ottenere accesso o avere maggiore conoscenza sul codice sorgente, analogamente a come molte persone che usano le mappe non sono interssate ai dati su cui queste di basano.

Al tempo stesso come gli sviluppatori possono essere interessati al codice sorgente di un’applicazione per poterlo modifcare, correggere. migliorare, coloro che sono interessati ai dati spaziali possono avere interesse nel modificarli, correggerli e migliorarli.

OpenGeo auspica che, analogamente a come è avvenuto nel mondo del software, dove questo approccio di condivisione ha portato ad una maggiore diffusione e consapevolezza unita ad un aumento della qualità del software, lo stesso avvenga nel mondo dei dati spaziali.

Quanto proposto da OpenGeo sembra andare oltre il modello impostato e portato avanti con successo da un progetto importante come OpenStreetMap il cui obiettivo è quello di raccogliere, e ridistribuire a tutti, in un’unica banca dati le informazioni spaziali attraverso le operazioni di edit fatte da un numero di crowdmapper volontari e appassionati sempre maggiore: si propone un modello collaborativo che richiede un nuovo paradigma e nuove problematiche da dover affrontare.

Un approccio che porti ad un modello collaborativo basato su un modello di versionig distribuito sui dati dovrebbe facilitare la collaborazione tra diverse organizzazioni / enti che hanno necessità di utilizzare e gestire i medesimi livelli informativi.

Ad oggi queste esigenze, per quanto le diverse iniziative / strumenti / tools che gravitano intorno ai concetti di Spatial Data Infrastructure (SDI), in senso lato, cerchino di mitigare la duplicazione di dati, non hanno ancora avuto una risposta esaustiva e resta sempre necessaria un’autorità centrale che si faccia carico di integrare (con diversi livelli di possible automatismo ma pur sempre con un elevato grado di controllo umano), le diverse sorgenti di informazione.

Un modello di versionig distribuito sui dati potrebbe semplificare la collaborazione, in quanto ogni organizzazione /ente manterrebbe il controllo completo sulla propria copia dei dati (potendovi applicare i propri processi di quality assurance), e non cedere così il controllo ad un’autorità esterna, ma al tempo stesso avrebbe visione di ogni change presenti su ogni repository delle altre organizzazioni e decidere se e quando effettuare i merge (per chi interessato nell’articolo originale viene riportato un esempio di dettaglio).

Il modello proposto potrebbe essere anche strumento abilitante per permettere un colloquio fattivo tra due mondi che ad oggi proseguono il loro cammino parallelamente guardandosi a distanza: il mondo dei dati geografici “ufficiali” o certificati (authoritative), generalmente gestiti da organizzazioni governative in grado di certificare le proprie informaizoni, ed il mondo della neo-geografia o del Volunteered Geographic Information (VGI) in cui rientrano tutti gli utenti crowdsourced legati a realtà quali OpenStreetMap, Google MapMaker, Ushahidi, ecc … .

I due mondi hanno ovviamente cicli di vita applicati ai dati completamente diversi: l’approccio VGI basato sul crowdsourcing permette a chiuque di fare edit dei dati, permettendo così si avere dati più aggiornati per quanto potenzialmente (????!!!!), passibili di errori, mentre l’approccio “authoritative” permette un modello centralizzato in cui il dato viene aggiornato e alterato in modo controllato, permettendo un dato di maggiore precisione (????!!!!), ma inevitabilmente con tempi più lenti.

Con un modello di versioning distribuito sui dati le organizzazioni / enti ufficiali potrebbero disporre del meglio di entrambi.

Infatti se da un lato con lo stesso approccio potrebbero collaborare con  altre organizzazioni / enti come descritto in precedenza, dall’altro potrebbero anche collaborare con singoli o gruppi interessati a vario titolo al miglioramento del dato stesso.

Il fornitore del dato può continuare a pubblicare versioni dei dati pienamente testati e verificati con un ciclo di vita del dato più “lento” per chi interessato a questa tipologia di dato, mentre chi usa il dato e ha necessità di avere un livello informativo più generale ed aggiornato, anche a scapito della sua certificazione, può mantenere una copia del dato certificato su cui fare le proprie modifiche / aggiornamenti e periodicamente riportarle sul repository del dato “authoritative” da cui questi poi rientreranno nel ciclo di vita del dato ufficiale (anche qui per chi interessato nell’articolo originale viene riportato un esempio di dettaglio).

Un modello di versioning distribuito sui dati avrebbe vantaggi anche nel caso di utilizzo di strumenti portabili di acquisizione di dati sul campo dove spesso non è garantita la copertura di rete o la sua affidabilità. In questo caso infatti il dispositivo mobile potrebbe essere visto come l’ennesimo repository da sincronizzare verso la base dati centrale o master.

A livello di rete questo tipo di approccio potrebbe trovare ulteriori vantaggi se si considera che il traffico potrebbe essere limitato rispetto ad una situazione tradizionale di upload / download in quanto sarebbero interessate solo le features create / modificate e non l’intero livello informativo.

Alcuni vantaggi, non molto in realtà se confrontato all’effettiva necessità ed onere, si potrebbero avere anche a livello di metadati in quanto gli strumenti di controllo di versione raccolgono metadati automaticamente, alcuni dei quali potrebbero essere utilizzati per tracciare la storia di ogni dataset per conoscere chi ha modificato cosa quando.

OpenGeo, dopo aver valutato diverse alternative, ha infine scelto di prendere in prestito le idee migliori da un software, non-geospaziale,  di versioning distribuito come Git e di costruire qualcosa di nuovo che fosse in grado di gestire dati geospaziali.

Si tratta di un primo passo ma altri possibili sono previsti come possibili alternative / evoluzioni:

• usare un approccio “ibrido” introducendo un database spaziale per fornire acecsso rapido e indicizzazione spaziale ai dati lasciando a Git le parti di versioning e history
• usare la tecnologia che sta alla base di CouchDB. Questo approccio permette di seperare il back end ed il front end così che se qualche novità interessante si presentasse sul mondo degli strumenti open source sia possibile e facilitato il suo utilizzo

GeoGit non è direttamente compatibile con Git o GitHub ma adatta i concetti di base di Git al contesto dei dati spaziali e si basa sia su GeoSynchronization Service module (una specifica OGC sulla sincronizzazione dei dati), sia sugli standard del Web Feature Service 2.0 (WFS-T). Le features sono implementate usando il  formato binario Hessian e il formato Well Known Binary (WKB), standard OGC che è ampiamente supportato da diversi tool ( per chi interessato nell’articolo originale viene riportato un esempio di dettaglio).

Ovviamente ci sono diversi punti ancora aperti: editando direttamente un datastore POSTGIS con un qualunque client gis desktop senza passare attraverso GeoGit si creano situazioni di inconsistenza, in modo del tutto analogo a come avverebbe se, in un utilizzo tradizionale di GitHub,  si facessero accessi diretti sul repository remoto senza fare il push delle modifiche sul repository locale.

Ovviamente per permettere di poter lavorare in una situazione “mista” in cui si possano fare editing sia in modo tradizionale sia attraverso l’utilizzo di WFS-T sarebbe necessario implementare delle strategie di notifiche sul repository attraverso trigger a livello del db POSTGIS oppure con plugin specifici sui vari client, quindi un mondo ancora piuttosto complesso.

Altri limiti attuali sono:

• è possibile utilizzare repositories con versioni lineari quindi non ci sono possibilità di fare branch, diff o rollbacks
• è stato testato su POSTGIS ma è stato progettato per lavorare con qualunque datastore che possa restituire degli ID stabili e quindi dovrebbe lavorare con ORACLE, ArcSDE, SQL Server e DB2

Al netto di queste limitazioni e come detto in precedenza il prodotto è disponibile nella sua alpha version.

Proseguono le attività tra cui:

• un’interfaccia javascript based realizzata sulla base di GXP così da essere facilmente incorporata in GeoExplorer, GeoNode e altre applicazioni che permetta di avere un’applicazione demo di front end così da interagire con la componente di back end
• uno strato di API javascript che permetta funzionalità di “diff”, “rollbacks” ma anche visualizzare l’history, fare confronti tra versioni sia sui dati spaziali sia sui dati associati. Questa fase è considerata molto complicata in quanto si tratta di andare ad affrontare concetti completamente nuovi se applicati ad un contesto geospaziale: quali sono i significati di un “diff”, un “merge” o un “clone” nel contesto del versionamento distribuito di dati spaziali?
• integrazione in GeoNode
• integrazioni sia nel mondo Mobile sia nel mondo Desktop. In particolare per quest’ultimo aspetto c’è da considerare la proliferazione di strumenti sia open source sia proprietari

In conclusione quindi GeoGit si presenta come soluzione tutt’altro che matura, anzi, nella versione attuale decisamente limitata, ma indubbiamente si tratta di un progetto interessante da seguire nelle sue evoluzioni.

Fonte: Blog OpenGeo

Crowdmapping: se ne parla sempre più spesso

Seguendo sulle rete le news legate al mondo GIS e i suoi dintorni,  in questi ultimi tempi emerge in misura crescente l’interesse sul fenomeno del crowdmapping.

Iniziano ad esserci esperienze o tentativi di un maggiore coinvolgimento della componente volontaristica da parte di Enti, Pubbliche Amministazioni, ecc .. nel processo di raccolta e condivisione distribuita delle informazioni georiferite.

Le modalità sono le più diverse ed eterogenee, ma il segnale comune sembra essere quello che due mondi, quello delle istituzioni pubbliche che “ufficialmente” detengono i dati e il mondo del VGI (Volunteered Geographic Information) in generale, inizino a parlarsi cercando collaborazioni ed interazioni.

Sicuramente il movimento degli Open Data ha contribuito a creare il terreno con l’humus giusto su cui basare queste collaborazioni, anche perchè una volta che i dati sono resi liberamente disponibili, occorre capire come gestire i processi di aggiornamento del dato stesso, che oggi potrebbero avere modalità e canali diversi rispetto  al recente passato, si pensi alla distribuzione dei dispositivi mobili in grado di raccogliere o comunque fornire supporto ed essere abilitanti per la raccolta / aggiornamento di molti dati, e all’esistenza di realtà / comunità come quella di OpenStreet Map in grado di avere una platea molto ampia di potenziali (ed entusiasti …), contributori.

In questo contesto riporto alcune delle iniziative che considero più significative.

HealthMap, la crowdmap per le emergenze sanitarie (fonte: Sardinia OpenData), è un progetto basato su Ushahidi che offre una mappa utilizzata per monitorare epidemie e informazioni sulla salute in tutto il mondo.

La mappa, gestita da un team del Boston’s Children’s Hospital,  rappresenta i tipi di malattia e luoghi in cui si manifestano, il numero di casi, gli avvisi e gli avvertimenti di eventuali epidemie

Lo strumento include anche informazioni sui sintomi della malattia, così come una serie di dati sulla salute degli animali e dell’ambiente.

I dati vengono estratti da diverse fonti aperte, relazioni dei testimoni oculari, aggregatori di notizie on-line e validati rapporti ufficiali. Le fonti includono dati dell’Organizzazione Mondiale della Sanità, dell’Organizzazione mondiale per la salute degli animali, l’alimentazione e l’agricoltura (UN) e altri.

Attraverso un processo automatico, i dati vengono analizzati ogni ora, prendendo in considerazione le diverse tipologie di malattia e la loro posizione, che man mano vengono ritirate dal set di dati.

HealthMap è disponibile online e su dispositivi mobili, come Android e iPhone.

HealthMap anche creato l’applicazione Outbreaks Near Me, che fornisce le ultime segnalazioni di epidemie e malattie infettive. Inoltre, è stata creata anche Flu Near You, che tiene traccia della diffusione del virus dell’influenza chiedendo ai partecipanti di compilare sondaggi periodici sullo stato di salute. Infine c’è il Vaccine Finder che può essere aggiunto al tuo sito web sotto forma di widget.

Lo U.S. Geological Survey  ha attivato un programma denominato The National Map Corps (fonte: @pietroblu) che ha come obiettivo quello di espandere il coinvolgimento dei volontari nel migliorare la raccolta delle informazioni sia aggiungendo nuove features, sia correggendo dati esistenti usando The National Map database. I livelli informativi coinvolti sono scuole, ospedali, uffici postali, stazioni di polizia, ecc ….

Sono già stati fatti dei progetti pilota in Colorado che hanno avuto una durata di 10 mesi coinvolgendo 143 volontari che hanno operato su più di 6.400 strutture.

Ora il progetto saràò esteso ad altri stati americani quali: Arkansas, Alaska, Colorado, Delaware, Georgia, Idaho, Maryland, Michigan, Montana, North Dakota, New Jersey, New Mexico, Ohio, Oregon, South Carolina, Utah, Washington, West Virginia.

I dati raccolti grazie ai volontari saranno disponibili agli utenti “free of charge“

La città di Chicago ha deciso di utililizzare GitHub per condividere i propri dati con gli utenti sollecitandone i fork per gli aggiornamenti.

L’utilizzo di GitHub per tale scopo è senz’altro di interesse e quindi degno di nota.

Questa iniziativa non ha intenzione di andare a sostituirsi al portale degli open data di Chicago,  ma è stata presentata come un esperimento per testare un modello collaborativo.

La scelta di GitHub è stata fatta in quanto lo strumento permette di fare download, fork e merge sui dati originali analogamente a come avviene per la gestione software per cui lo strumento è principalmente utilizzato.

E sin qui abbiamo esempi di crowdsourcing spontaneo, ma riporto anche un  riferimento di un caso di crowdsourcing diversamente spontaneo nell’utilizzo di tools di CAPTCHA per riconoscere o verificare un numero civico all’interno della piattaforma Blogger di Google all’atto della conferma di commenti a dei post, cosa che ovviamente sembra essere un po’ per lo meno borderline rispetto ad un coinvolgimento consapevole da parte dell’utente.

 

Libri e presentazioni open sui GIS

Recentemente sono apparse in rete alcune news sulla disponibilità open di libri e presentazioni su tematiche GIS.

Eccone i riferimenti:

• An Open Geospatial Textbook: autore David Di Biase direttamente da Pennsylvania State University (fonte: @aborruso)
• Map Projections: A working Manual: autore John Snyder dell’USGS (fonte: @aborruso)
• Online GIS: autore Christopher Brown (fonte: GIS Lounge)
• Once Upon a Time …. OpenLayers: autore Antonio Santiago. Bella presentazione di OpenLayers con riferimenti ad esempi tratti dal libro OpenLayers Cookbook (fonte: @cedricmoullet)

 

Google Fusion Tables e strumenti GIS

Tenpo fa, per pubblicare su mappa dei dati open e non disponendo di un database e di un motore GIS, ho provato ad utilizzare Google Fusion Tables come possibile soluzione, rappresentando poi il tutto usando le Google Maps API.

Recentemente ho trovato due interessanti post che possono essere di spuntoi per provare ad integrare Google Fusion Tables con il mondo e gli strumenti GIS.

GIS Lounge suggerisce un metodo per caricare direttamente uno shapefile su Google Fusion Tables senza passare da una precedente conversione in KML, mentre Webrian suggerisce come impostare una tabella di Google Fusion Tables come sorgente dati per QGIS 1.9.

Fonte: GIS Lounge e Webrian

OpenGeoData: come utilizzarli su una mappa? Ad esempio sfruttando il cross layer filtering di Geoserver

Sempre più spesso si parla di open data e tra questi di quelli che maggiormente sono ricercati dagli utenti, vale a dire quelli georiferiti.

La disponibilità di open dati open georiferiti sta infatti pian piano aumentando come testimoniato nella recente conferenza sugli OpenGeoData tenutasi a Roma il 28 Febbraio. Gli ultimi esempi degni di nota in tale direzione sono stati la pubblicazione in modalità open data di informazioni georiferite messe a disposizione del Comune di Venezia, e da quello di Trento, mentre, ancora più recente, è la notizia relativa alla volontà di prossima pubblicazione in modalità open dei dati georiferiti della Provincia Autonoma di Bolzano.

L’aumentare della disponibilità va sicuramente a “saziare”, in parte, l’appetito di quel mondo di tecnici e appassionati che per skill personali, sanno cosa farci e come usare questi dati ma resta tutto un mondo di potenziali utenti (privati ma anche del mondo business), che, non provenendo dal mondo GIS classico o della neo-geography,  non hanno quindi dimestichezza con questa tipologia di dati e che quindi non sa bene come usarli o nemmeno, cosa peggiore, cosa si potrebbe fare per costruirci del valore aggiunto.

Resta quindi un gap da riempire, anche di conoscenza, per valorizzare questo patrimonio informativo messo liberamente a disposizione che, se non colmato, rischia di vanificare in parte il grosso sforzo che si sta facendo negli ultimi anni per rendere open data più informazioni possibili, le quali rischiano sì di uscire dal cassetto di un qualche funzionario della P.A, ma per finire, dimenticati, su un qualche portale open data che con il passare del tempo perderà di interesse.

Esempio

Lo scopo di questo post è quello di illustrare un possibile utilizzo di tali dati sfruttando le funzionalità di cross-layer filtering offerte da GeoServer.

I dati

Come dati di esempio ho utilizzato due shapefile messi a disposizione dal Comune di Torino e precisamente:

• il livello informativo dei numeri civici. Il Comune di Torino censisce infatti in modo puntuale tutti i numeri civici presenti sul territorio comunale e li rende disponibili in scarico in formato ESRI shapefile dal suo portale degli open data AperTO con licenza IODL v20. Il dato è costituito da più di 43.000 punti.
• il livello informativo degli esercizi commerciali. Il Comune di Torino censisce infatti in modo puntuale tutti gli esercizi commerciali presenti sul territorio comunale e li rende disponibili in scarico in formato ESRI shapefile dal suo GeoPortale  con licenza Creative Commons public licence” Attribuzione – 2.5 (ITALIA). Il dato è costituito da più di 27.000 punti.

I dati sono praticamente direttamente utilizzabili: per mia comodità ho aggiunto ad entrambi i dati, visto che ne erano privi, un campo chiave univoco (KEY), numerico che ho valorizzato con un progressivo e poi ho trasformato l’SRS di riferimento adottando l’EPSG:900913. Per fare queste operazioni ho utilizzato QGIS Desktop ma sono operazioni che si possono fare con qualunque strumento GIS Desktop.

Per chi volesse replicare gli esmepi riportati in questo post i dati sono liberamente scaricabili.

Cross Layer Filtering in GeoServer

Come  ho anticipato in questo esempio ho sfruttato la funzionalità di cross-layer filtering offerte da GeoServer. Questa funzionalità permette di ricercare features di un layer (A) che abbiano una qualche relazione spaziale con features di un altro layer (B).

In generale quindi permette ad esempio di cercare tutte le stazioni di autobus (layer A)  che sono entro una certa distanza da un certo negozio (features del layer B), oppure che sono dentro un certo quartiere (layer B).

Ho utilizzato un pc Windows 7 con 4 core e 8 Gbyte di RAM con GeoServer 2.2.3 con le seguenti caratteristiche:

• Git Revision 0fd3212ede1a8e13257ae5785cc8a752ee0a645c
• Build Date 22-Dec-2012 15:59
• GeoTools Version 8.5 (rev 06286dc3c15c2498aa5b3580de5df928f07d31dc)

Nello specifico l’esempio che ho implementato permette di individuare quali sono gli esercizi commerciali che sono nell’intorno di un certo indirizzo.

La funzionalità è stata implementata completamente in GeoServer quindi come funzionalità server-side esposta come WFS quindi potenzialmente fruibile da qualunque client in grado di mandare la richiesta secondo questo protocollo (con i corretti parametri ovviamente), interpretandone poi il GML ottenuto come risposta.

Ecco la chiamata POST nel caso in cui si cerchino le features del layer AttivitaCommerciali che rcadono nell’intorno di 100 metri dal numero civico identificato con la chiave 36748

<wfs:GetFeature

xmlns:wfs=”http://www.opengis.net/wfs&#8221;

xmlns:CesareWorkspace=”http://www.openplans.org/spearfish&#8221;

xmlns:ogc=”http://www.opengis.net/ogc&#8221;

service=”WFS” version=”1.0.0″>

<wfs:Query typeName=”CesareWorkspace:AttivitaCommerciali900913″>

<ogc:Filter>

<ogc:DWithin>

<ogc:PropertyName>the_geom</ogc:PropertyName>

<ogc:Function name=”collectGeometries”>

<ogc:Function name=”queryCollection”>

<ogc:Literal>CesareWorkspace:NumeriCivici900913</ogc:Literal>

<ogc:Literal>the_geom</ogc:Literal>

<ogc:Literal>KEY = 36748</ogc:Literal>

</ogc:Function>

</ogc:Function>

<ogc:Distance units=”meter”>100</ogc:Distance>

</ogc:DWithin>

</ogc:Filter>

</wfs:Query>

</wfs:GetFeature>

Il tutto lo potete eseguire dal Demo Request che trovate una classica installazione di GeoServer in

http://localhost:8080/geoserver/web/?wicket:bookmarkablePage=:org.geoserver.web.demo.DemoRequestsPage)

usando come url per l’esecuzione qualcosa di questo genere

http://localhost:8080/geoserver/CesareWorkspace/ows?

(in questo caso il mio layer si trova in un workspace denominato CesareWorkspace.

Il risultato sarà un GML con l’elenco delle features individuate dal filtro spaziale DWithin: faccio notare che nel GML sono restituite non solo le coordinate delle features ma le intere features come oggetti e quindi comprensive dei dati alfanumerici descrittivi

Un esempio di utilizzo in OpenLayers

Per poter visualizzare questo risultato ho utilizzato OpenLayers 2.12 scrivendo una piccola applicazione web che illustra come visualizzare i dati di partenza, Numeri Civici e Attività Commerciali su sfondo OpenStreetMap e che al tempo stesso permette all’utente di selezionare un indirizzo e sulla base di questo indicare una distanza di ricerca: confermando l’operazione l’applicazione esegue una chiamata in POST verso GeoServer e ne visualizza i risultato sotto forma di VectorLayer di OpenLayers tratto dal GML di risposta.

L’intero codice dell’applicazione è scaricabile e liberamente utilizzabile. Il codice è ampiamente commentato e quindi dovrebbe essere piuttosto chiaro (ovviamente per chi conosce OpenLayers …), il suo modo di operare.

Ecco solo alcune note importanti per la sua esecuzione:

1) se Apache e GeoServer sono su server diversi o sono sullo stesso server ma rispondono su porte diverse è necessario usare un proxypass definito nell’httpd.conf di Apache. Nel mio caso Apache e GeoServer sono sullo stesso server ma Apache risponde sulla porta 80 mentre GeoServer sull’8080 e quindi nel file ci configurazione di Apache ho riportato quanto segue:

<Location /local-geoserver/>

             ProxyPass http://localhost:8080/geoserver/

             ProxyPassReverse http://localhost:8080/geoserver/

          </Location>

2) come anticipato i due layers adottano il sistema di riferimento EPSG:900913. Questa è stata una semplificazione voluta visto lo scopo didattico dell’esempio. Se si intende replicare ed adattare l’esempio con latri dati occorre tenere presente il sistema di riferimento adottato e fare le opportune modifiche

// *****************************************************************

            // ** Set up projection used                                      **

            // *****************************************************************

            var map_projection = new OpenLayers.Projection(“EPSG:900913″);           

            var map_display_projection = new OpenLayers.Projection(“EPSG:900913″);

e nella definzione del layer la riga

   projection: new OpenLayers.Projection(“EPSG:900913″) 

3) ad ogni cambio di indirizzo e/o di distanza di ricerca è necessario aggiornare la mappa ma al tempo stesso occorre anche eliminare le features precedentemente disegnate: nel mio caso ho deciso di essere un po “drastico” eliminando e ricreando i layer interessati ogni volta

// ***********************************************************************************

            // ** Remove overlay layers: I’ve to update them ….                                                                     **

            // ***********************************************************************************

            if (my_address_wfs != null) {              

               layers = map.getLayersByName(‘Indirizzo in esame’);                

               for(layerIndex = 0; layerIndex < layers.length; layerIndex++)

                  {

                 map.removeLayer(layers[layerIndex]);

                  }

            }

          

            if (my_address_wfs != null) {             

               layers = map.getLayersByName(‘Attività Commerciali vicino ad indirizzo’);                 

               for(var layerIndex = 0; layerIndex < layers.length; layerIndex++)

                  {

                 map.removeLayer(layers[layerIndex]);

                  }

            }

4) occorre considerare che la chiamata verso geoserver e la successiva elaborazione della risposta è un processo asincrono per cui si perde un po’ il controllo del flusso di esecuzione che è demandato completamente ad OpenLayers: può essere quindi un po’ complicato disegnare le features al momento giusto, effettuare i corretti zoom (le features potrebbero non ancora essere state disegnate e il layer risulta “vuoto” ….), ecc .. Nel mio caso per il layer che rappresenta il mio indirizzo in esame (my_address_wfs) ho deciso di utilizzare una strategia Fixed

strategies: [new OpenLayers.Strategy.Fixed()]

e un listener che “scatta” quando tutte le features sono state aggiunte così da poter fare, solo a quel punto, le necessarie considerazioni e azioni, nello specifico fare uno zoom all’indirizzo in esame solo se non siano state individuate attività commerciali nell’intorno dell’indirizzo stesso.

eventListeners: {

                “featuresadded”: function(event) {

                      if (theAttivitaExtent == null) {

                         this.map.zoomToExtent(this.getDataExtent());

                      }

                }

            }

Non potendo mettere a disposizione una versione live dell’esempio in oggetto eccovi un filmato di una sessione di utilizzo

(doveroso … un ringraziamento a Fabrizio C., Diego S. e Fabrizio M., in memoria dei vecchi tempi e per la pazienza ed il supporto che mi hanno dato nella realizzazione di questo esempio di fruizione in OpenLayers)

Conclusioni

Questo è solo un esempio ma illustra un principio di utilizzo che si può estendere e generalizzare, ad esempio:

• il fatto di sfruttare una funzionalità offerta server-side da GeoServer basata su protocolli standard (WFS, GML), permette di riusare la funzionalità stessa da client diversi, sfruttando anche, in caso di necessità, la scalabilità server side offerta dal motore GIS
• la stessa applicazione, pur didattica, sarebbe portabile su un dispositivo mobile. In questo caso la scelta dell’indirizzo potrebbe essere facilmente sostituita dalla posizione corrente dell’utente via localizzazione GPS
• i dati messi a disposizione potrebbero essere più significativi di quelli utilizzati nell’esempio per rendere più utile l’applicazione stessa. Ad esempio localizzazione di servizi di pubblica utilità (ad esempio nel caso in cui si sia in una città che non si conosce …), offerte di business nel campo del commercio (quali negozi offrono quali opportunità nell’intorno di un indirizzo o posizione … ), micro-marketing (caratteristiche dell’utenza nell’intorno di un indirizzo o in un’area), ecc ..
• utilizzo di altre tipologie di filtro spaziale

Ordinance Survey rilascia in modo aperto gli SLD per tematizzare i propri dati

L’Ordinance Survey britannico ha annunciato di rendere disponibili in modalità libera gli stili SLD di  tutti i propri dati vettoriali così che chiunque possa facilmente e rapidamente replicare le mappe dopo aver scaricato i dati utilizzando i medesimi tematismi.

In questo modo in teoria (da verificare all’atto pratico perchè poi dipende tutto da come i vari motori GIS hanno implementato lo standrad SLD e le sue varie versioni: personalmente ho fatto delle prove di portabilità degli stili SLD tra GeoServer e MapServer e qualche differenza in efetti c’è per cui la portabilità non è detto che sia completa ma in ogni caso acettabile e comunque mi sembra sia la via corretta …. ), è possibile pubblicare via WMS i dati in modo omogeneo e utilizzando le simbologie “ufficiali” indipendentemente dal motore GIS di pubblicazione disponibile e in modalità standard OGC.

Interessante iniziativa

Fonte: @alesarrett

Nuovi rilasci: GeoServer 2.3 beta, MapStore 1.0.0 e FME 2013

Oggi è stata una giornata caratterizzata da una serie di rilasci di nuove versionidi prodotti del mondo GIS.

Direttamente dal blog di GeoServer è stato annunciato GeoServer 2.3 beta la prima versione della nuova generazione del GIS server open source forse più duffuso.

Le novità elencate sono davvero tante:

• un nuovo modulo community che permette di gestire la configurazione in un database relazionale (i test sembra che diano buone performance anche con milioni di layer …..)
• il sottosistema disk quota subsystem è stato completamente rivisto e la dipendenza da Berkeley DB Java è stata eliminata permettendo l’utilizzo di RDMS standard. Il prodotto viene distribuito con un database H2 ma permette di utilixzzare RDBMS estreni quali PostgrSQL o Oracle ed è anche permesso ad un cluster di istanze di GeoWebCache di condividere la stessa disk quota information
• miglioramento dei Layer Group
• miglioramenti sul fronte del sottosistema di sicurezza
• miglioramenti sul fronte WPS: sarà possibile associare processi a determinati utenti
• integrazione con INSPIRE con un modulo community dedicato

Per maggiori dettagli si rimanda al post del blog ufficiale di GeoServer.

GeoSolutions ha rilasciato MapStore 1.0.0, un nuovo prodotto per creare, salvare e condividere mappe.

MapStore è basato sul framework  GeoExplorer Open Source ed è licenziato con licenza GPL.

Permette di fare mashup di contenuti con Google Maps, OpenStreetMap, MapQuest, Bing ma anche servizi WMS.

Internamente utilizza GeoStore (la soluzione di GeoSolutions per il resource storing and retrieving), e Http-proxy per comunicare con server come quelli che offrono contenuti via WMS.

Infine Safe ha annunciato il rilaascio di FME 2013 che ora supporta più di 300 formati, nuove funzionalità di trasformazione, 3D e molte altre feature. E’ stto pubblicato anche un video di presentazione.

 

QGIS puo’ usare database Oracle (tramite un driver nativo)

Ci siamo!. Era stato annunciato al GFOSS 2012 di Torino e ora è disponibile nella versione in sviluppo.

QGIS supporta ORACLE con un driver nativo.

Annuncio sulla lista GFOSS.it e su Nathan’s QGIS and GIS Blog

GeoPackage: OGC apre il periodo dei pubblici commenti

L’OGC GeoPackage ha fatto un ulteriore passo avanti: è stato aperto infatti il periodo dei pubblici commenti che ci chiuderà il 7 Febbario 2013.

A tale scopo è stato reso disponibile il draft dello standard.

Per chi interessato ecco anche un intervento di James Fee dal blog di WeoGeo.

Fonte: Open Geospatial Consortium