Novità anche sul fronte mappe, prossimamente maggiori dettagli

]]> http://cesaregerbino.wordpress.com/2013/05/16/google-io-2013-tutte-le-novita-di-bigg/feed/ 0 cesaregerbino http://cesaregerbino.wordpress.com/2013/05/10/25-anni-in-timelapse-della-terra/ http://cesaregerbino.wordpress.com/2013/05/10/25-anni-in-timelapse-della-terra/#comments Fri, 10 May 2013 18:27:48 +0000 cesaregerbino http://cesaregerbino.wordpress.com/?p=1282 ]]> Google ha realizzato un nuovo progetto che ha denominato Timelapse  realizzato in collaborazione con la rivista statunitense Time, la NASA e la United States Geological Survey (USGS), e utilizzando immagini che fanno parte della raccolta della missione Landsat, iniziata negli anni Settanta con una collaborazione tra NASA e USGS.

Ecco alcune immagini animate che illustrano l’evoluzione nel tempo di alcune zone del pianeta:

Ecco il link ufficiale a cui trovare  tutte le immagini ed ecco invece il riferimento all’applicazione live in cui è possibile selezionare la propria zona di interesse.

Fonte: Google Lat Long Blog

Questo esempio ha lo scopo di illustrare un prototipo di web mapping che permetta di consultare una mappa interattiva rappresentante le Scuole in Piemonte (suddivise per ordine e grado), e delle informazioni scolastiche aggregate su base comunale.

I dati

I dati utilizzati sono tutti dati open source e precisamente:

• Scuole: i dati delle scuole sono stati tratti dal dato (open data), dell’anagrafe delle strutture pubblicato dal MIUR (rif. http://archivio.pubblica.istruzione.it/scuola_in_chiaro/open_data/Anagrafe.zip )
• Studenti piemontesi 2009 – 2010: i dati degli studenti piemontesi riferiti ai comuni sono stati tratti dal dato (open data), pubblicato sul sito degli open data della Regione Piemonte (rif. http://www.dati.piemonte.it/catalogodati/dato/100233-studenti-piemontesi-2009-2010.html )

Ovviamente questi dati vanno intesi come dati di prova: a fronte di un aggiornamento dei dati, mantenendo inalterata la struttura dati, l’applicazione non richiede alcun tipo di intervento.

Occorre tuttavia evidenziare che i dati originali, come tratti dai portali di cui sopra, non sono strutturati per essere utilizzati direttamente dall’applicativo ma è stato necessaria un’attività di trattamento dati preliminare per renderli “georiferibili”.

Le attività svolte sono state rispettivamente:

• Scuole: le scuole sono rese disponibili solo con il loro indirizzo e non (purtroppo ….), con le coordinate che le possano già caratterizzare sul territorio. Partendo quindi dall’indirizzo si sono sfruttati dei tools di georeferenziazione automatica presenti e disponibili sul web per ricavare la loro georeferenziazione, nello specifico ho utilizzato http://stevemorse.org/jcal/latlonbatchsecure.html?direction=forward . La precisione e l’accuratezza di questo dato è quindi approssimativa ma funzionale per il prototipo presentato.
• Studenti piemontesi 2009 – 2010: qui le informazioni di georeferenziazione erano assenti. Attraverso la manipolazione dei dati si è fatto in modo di associare ad ogni comune il suo codice ISTAT e poi sulla base di questo, con delle operazioni di join, sui dati si è riportata questa informazione su base comunale permettendo quindi la rappresentazione di queste informazioni su base comunale e la loro tematizzazione. Per il caricamento dello shapefile risultante su Google Fusion Tables ho utilizzato Shape Escape.

Procedimento

Nella realizzazione si è tenuto conto e si è preso spunto dell’esistenza del progetto “Scuole in Chiaro” (rif. http://cercalatuascuola.istruzione.it/cercalatuascuola/ ), realizzato da parte del MIUR

La soluzione del Ministero è una web application fruibile da web browser basata sull’utilizzo delle Google Maps, partendo dalle quali sono state realizzate una serie di componenti funzionali che permettono di ottenere informazioni varie sulle Scuole secondo modalità diverse.

Il sito permette la consultazione dei dati delle Scuole impostando una serie di criteri di ricerca per arrivare poi alla visualizzazione dei dati di interesse.

Da notare che è  necessario impostare dei filtri di ricerca altrimenti non è possibile visualizzare su mappa alcuna scuola. Tra l’altro, se il filtro di ricerca impostato è tale da restituire un numero elevato di risultati, viene chiesto all’utente di restringere i criteri di ricerca al fine di arrivare ad un numero di risultati gestibili applicativamente, questo per evitare lunghi tempi di risposta nella visualizzazione su mappa.

Il risultato della ricerca può essere visualizzato su mappa e poi da questa direttamente interrogato.

Partendo da questa esperienza ho provato a dare una chiave di lettura diversa alla consultazione del dato relativo alle Scuole e alle informazioni ad esse associate: questo post descrive una soluzione applicativa che permette di consultare le medesime informazioni  offerte da “La Scuola in chiaro”, in una modalità alternativa integrando le informazioni sulle Scuole anche con altro contenuto informativo, su base comunale,  sempre legato all’ambito della mondo scolastico in modalità mash-up.

Questa soluzione permette di visualizzare sempre tutte le scuole del Piemonte secondo modalità diverse che salvaguardino le prestazioni applicative, ma offrendo all’utente sempre una risposta, al limite aggregando in modo dinamico quelle informazioni che, alla scala corrente della mappa, la renderebbero poco leggibile (questa tecnica è nota con il nome di clustering e viene adottata tipicamente quando si trattano informazioni puntuali su mappa quali sono quelle della localizzazione sul territorio delle scuole).

La soluzione si presenta, per la parte mappa e nella sua forma prototipale, nel seguente modo:

ed ecco il  dettaglio della mappa ad un maggiore livello di zoom

I marker in rosso possono essere direttamente interrogati come avviene normalmente su una mappa Google, mentre i marker in blu, con un numero al loro interno, significano che in corrispondenza di quel punto ci sono “n” elementi che a quella scala non sono visibili. Se l’utente desidera visualizzarli è sufficiente che faccio uno (o più), zoom di dettaglio ulteriore.

L’applicazione propone altre funzionalità ad esempio la possibilità di posizionarsi sulla mappa per comune e/o indirizzo

La mappa si centrerà sull’elemento ricercato evidenziandolo con un pallino verde.

E’ inoltre possibile visualizzare su mappa (sempre utilizzando il meccanismo del clustering), solo le scuole di un certo ordine e grado

Infine è possibile tematizzare su base comunale per una serie di indicatori

Ad esempio ecco la mappa risultante da:

• Selezione delle Scuole Primarie
• Centrata sul Comune di Carignano
• Tematizzata per totale classi di scuole primaria per comune

Da notare che è sempre possibile interrogare sia il dato delle scuole sia il dato della tematizzazione comunale.

L’applicazione è liberamente consultabile on line.

Opportunità

La soluzione prototipale proposta disacoppia fortemente la parte di interfaccia dai dati che sono esposti tramite dei servizi JSON. (rif. https://www.google.com/fusiontables/DataSource?docid=1EuuZGh8C4VA8vkMiLomxxs_1moNbCEpZVhwtnXU  e https://www.google.com/fusiontables/DataSource?docid=1h_HGRAz91a-hhOsHrlqOYM0desNTOEw7Ko0XYmc )

Questa impostazione permette di immaginare soluzioni fruitici diverse da quella presentata delle stesse informazioni ad esempio soluzioni mobile fruibili tramite smartphone e/o tablet (anche se  in questo caso l’applicazione va completamente ripensata in quanto cambia totalmente il pattern di utilizzo)

Codice sorgente

L’applicazione è costituita da un’unica pagina HTML / Javascript che utilizza la Google Maps API e si appoggia come fonte dati a tavole mantenute su Google Fusion Tables.

Il codice sorgente è liberamente scaricabile ed utilizzabile: al suo interno sono ripotrtati commenti per facilitarne la comprensione.

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

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.

Sono disponibili gli esempi e la prima versione (incompleta), della documentazione delle API.

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)

Nel corso dello sprint è stato svolto un interessante lavoro sul vector branch ottenendo i seguenti risultati (riporto integralmente dal post originale):

• GeoJSON format support.
• Tile-based rendering of vector geometries to a 2D canvas.
• Rendering of points with a circle symbol or icons from image files.
• Stroke symbolizers (color, width, opacity) for lines and polygons.
• Fill symbolizers (color, opacity) for polygons.
• Rule based styling with filters and access to feature data, including support for multiple symbolizers per feature
• Fast rendering thanks to spatial R-Tree indexing and rendering of geometries with the same symbolizer in a single pass.

E’ stato fatto anche del lavoro sul fronte del supporto dei formati che è uno dei punti di forza di OpenLayers2. Ora sono supportati OGC Exception Report, OGC OWS Common, OGC WMS Capabilities, OGC WMTS Capabilities, e GeoJSON. E’ stato fatto anche del lavoro sul KML parser ma non è ancora pienamente supportato.

A livello di formati supportati ora OpenLayers 3 ora c’è anche il supporto del WMTS: ora è anche possibile creare WMTS source objects da WMTS Capabilities.

A livello di controlli ora sono disponibile due nuovi controlli interamente customizzabili via CSS: zoom slider e scale line control.

Sono state apportate anche delle migliorie sulle interazioni quali  DragPan, TouchPan, and TouchZoom.

OpenLayers 3 ora supporta tre tipi di renderer: DOM, Canvas e WebGL. DOM e WebGL sono stati scritti per primi, successivamente il gruppo di lavoro si è concentrato su Canvas che però deve essere ancora ottimizzato. In molti esempi il renderer può essere settato esplicitamente utilizzando un parametro nella URL, ad esempio la demo dell’utilizzo di Stamen che utilizza il Canvas renderer risponde a questa url

http://openlayers.github.com/ol3/master/examples/stamen.html?renderer=canvas

A livello di API il lavoro sembra ancora essere lungo ma inziano a vedersi i primi risultati. Ora è possibile:

• passare un array di layers al map constructor
• passare dei controlli da attivare sulla mappa
• usare le stringhe per specificare le proiezioni

Un grande miglioramento a livello della qualità del codice dovrebbe essere portato dalla “continuous integration” (vedi Travis CI), che dovrebbe verificare che i vari esempi funzionino sempre correttamente sollevando le opportune eccezioni in caso di errori.

E’ possibile vedere OpenLayers 3 “in action” dalla pagina degli esempi attiva su GitHub.

Fonte: OpenLayers Blog

***************************************************

Il tema degli OpenGeoData è importante e pensiamo che meriti hic et nunc un’attenzione speciale.

E’ indispensabile la crescita di una consapevolezza diffusa del loro valore, così come è necessario porre l’attenzione sulle modalità di implementazione del modello e verificarne l’impatto in termini di valore aggiunto; per professionisti, aziende, decisori e cittadini.

Vogliamo creare un gruppo di lavoro aperto a tutti e che si appoggerà anche su quanto di buono e utile è stato fatto in analogia per il tema più generale degli OpenData.

Tre i temi principali che vorremmo trasformare in azione:

• Formazione – iniziative formative a medio, lungo termine riguardanti la formazione su specifiche questioni di fondo (metadati, INSPIRE, standard, soluzioni tecnologiche, ecc.)
• Informazione – iniziative di tipo divulgativo (filmati didattici e di promozione), così come webinar di taglio informativo su argomenti di approfondimento
• Buone prassi – segnalazione e report di iniziative e progetti riguardanti geoportali e portali open data, standard, apertura e liberazione di dati (ma non solo) che possono essere prese a modello

Pensiamo sia necessario il contributo di molti, sia in termini di contenuti che di modalità di azione

Per questa ragione abbiamo pensato di creare uno spazio in cui ognuno potrà proporre, condividere, commentare e valutare in modo costruttivo idee utili sul tema.

Abbiamo aperto una community su ideascale (geodatiliberi.ideascale.com), non vi resta che aprire un account e cominciare a proporre e interagire con gli altri. Troverete le tre categorie di cui sopra nelle quali inserire le idee e proposte, in modo tale da rendere il tutto più organico.

Perché OpenGeoData non sia soltanto un obbligo normativo, una moda o un sfogo per il “geogeek”.

***************************************************

E’ anche attivo un hashtag Twitter, precisamente #ChièGiancarlo: per chi fosse incuriosito dal nome strano è possibile trovare la spiegazione in un articolo di Andrea Borruso.

Ho scoperto che ne esiste anche un altro che si chiama OSM Reporter che permetet di vedere i contributi dei vari utenti di una certa zona per i livelli Building e Highway.

Fonte: Linfinity Geo Blog