Archivio

Posts Tagged ‘GeoServer’

GeoWave “estende spazialmente” i “big data”?


Sembra che si inizi a pensare di utilizzare sul serio la componente spaziale dell’informazione anche nel mondo dei “big data”: un articolo interessante riporta i piani di un progetto ambiziono di GeoWave.

I pezzi salienti  dell’articolo sono i seguenti:

  • Geowave intends to do for “big data” databases (initially Apache Accumulo) what PostGIS does for SQL databases (PostgreSQL). GeoWave is open source software (licensed under Apache 2.0) that adds support for geographic objects, multi-dimensional indexing and geospatial operators to Apache Accumulo.
  • Apache Accumulo is a distributed database that is based on Google’s BigTable design and is built on top of Apache Hadoop and other Apache projects.
  • GeoWave includes a GeoServer plugin to enable geospatial data in Accumulo to be shared and visualized via GeoServer OGC standard web services. It provides plugins to connect the popular geospatial toolset GeoTools and the point cloud library PDAL to an Accumulo based data store. The PDAL plugin makes it possible to interact with point cloud data in Accumulo through the PDAL library.
  • The GeoWave project Work plans to extend the same geospatial capabilities to other distributed key-value stores in addtition to Accumulo. The next data store will be HBase. It also will support other geospatial frameworks in addition to GeoTools/GeoServer. Mapnik is the next geospatial framework targeted for GeoWave support. GeoWave says it is very interested in GeoGig and support for this geospatial data versioning library is currently on their backlog. GeoGig takes the concepts used in distributed version control such as Git and applies them to versioned spatial data.

Sicuramente un progetto da tenere in osservazione …..

Numeri civici Open Data in Italia (hashtag #IndirizzatiItalia!): un po’ di dettaglio tecnico

24 settembre 2014 3 commenti

Nel post relativo all’annuncio  di Numeri Civici Open Data in Italia (hashtag #IndirizzatiItalia!) non mi sono dilungato nei dettagli tecnici per non appesantire: ora, per chi interessato, fornisco qui alcune informazioni.

Nel documento è possibile trovare, per ogni livello informativo:

  • i riferimenti relativi al nome dell’Ente che lo mette a disposizione in modalità open data
  • la sua url di pubblicazione
  • la sua url di download
  • il riferimento della licenza d’uso del dato
  • la url di download al dato trasformato in formato ESRI shapefile (senza alterazione della struttura dati), con sistema di riferimento WGS84

I dati sono anche resi consultabili, da un punto di vista geografico, usando il software open source QGIS, in due modalità:

Una breve nota tecnica: è necessario, per la consultazione di livelli informativi del Geoportale Nazionale, che, qualora si operi su una rete locale, si verifichi la corretta configurazione del  proxy, e, per rendere operativo lo sfondo OpenStreetMap, che, nel QGIS utilizzato, sia presente ed attivo il plugin OpenLayers. I progetti QGIS sono stati realizzati con la versione 2.0.1 (Dufour).

Per una consultazione web ho invece realizzato un piccolo esempio in web mapping basato su HTML, Javascript e Leaflet.

DettaglioMappa

L’applicazione permette di:

  • localizzare l’area di interesse per indirizzo o nome della località
  • attivare / disattivare i layer di interesse (il dettaglio dell’indirizzo <via> <civico> è fornito solo alle scale di maggior dettaglio)
  • interrogare interattivamente il livello informativo “Civici Geoportale Nazionale – (WFS)”

Visto che nell’applicazione di web mapping non era possibile elencare i più di 100 livelli informativi, questi sono stati raggruppati per Regione e/o Ente realizzando per ognuno di essi un singolo catalogo raster TMS usando come soluzione TileMill.

Per rendere più veloce la produzione dei vari cataloghi i dati, dopo essere stati trasformati in formato ESRI Shapefile e riportati in WGS84 (EPSG 4326), sono stati caricati in POSTGIS.

Sono anche disponibili due livelli informativi tratti dai geoservizi OGC offerti dal Geoportale Nazionale, il servizio WMS dei civici aggiornamento 2012 e il corrispettivo servizio WFS che permette l’interrogazione interattiva dei singoli numeri civici (funzionalità disponibile solo alle scale di maggior dettaglio onde evitare, da un lato, di richiedere un numero di features eccessivo al server del Geoportale Nazionale, e dall’altro di appesantire la fase di rendering sul browser).

Ovviamente sono disponibili diversi livelli informativi di sfondo (baselayer).

La modalità di pubblicazione in web mapping adottata, sebbene funzionale, ha il vantaggio di essere semplice e non richiede particolari necessità infrastrututrali, è sufficente un web server e un po’ di spazio disco. Al tempo stesso ha, indubbiamente dei limiti, il primo tra tutti è che la sua “semplicità” porta a perdere il livello di dettaglio dei dati raccolti, rendendoli disponibili solo in forma aggregata e come cataloghi raster TMS.

Una soluzione più “enterprise” richiede una disponibilità di un minimo di infrastruttura che al momento non ho adottato non disponendone. Non per questo non ho individuato una possibile soluzione che permetta, da un lato, di mantenere il dettaglio del dato  e al tempo stesso permetta di garantire sia buone prestazioni in consultazione sia l’interoperabilità.

Tale soluzione è basata su una pila tecnologica completamente open source (quindi facilmente replicabile da chi interessato …), che comprende:

Questa rappresenta “una” scelta, non l’unica adottabile nel panorama del mondo gis open source come pure nell’ambito del mondo gis bastao su soluzioni proprietarie.

Implementativamente e per ragioni di praticità, ho utilizzato OpenGeoSuite 4.0.2 (usando una installazione di default, senza alcun parametro di ottimizzazione …), su un quadcore Intel con 8Gbyte di RAM e Windows 7 Enterprise: ovviamente questa non è da considerarsi una configurazione adatta per un ipotetico ambiente di produzione.

Mentre la scelta di POSTGIS come data base spaziale direi che è quasi “inequivocabile”, la scelta di GeoServer è stata indirizzata dal fatto che, oltre ad essere un ottimo gis server, ha una caratteristica che, nel caso specifico dei dati che si dovevano trattare, tornava molto utile, vale a dire la capacità di implementare un point clustering server side per facilitare la consultazione di layer con un gran numero di punti che, altrimenti, dovrebbero essere renderizzati sul client, con prestazioni non accettabili.

Il tutto, come valore aggiunto, realizzato usando modalità standard, vale a dire uno stile SLD, ed esponendo il layer in interoperabilità secondo i consueti standard OGC (WMS e WFS).

NOTA: l’esempio di stile SLD fornito dal tutorial Buondless non permette di interrogare i singoli punti e quindi ho dovuto leggermente modificarlo e lo rendo liberamente scaricabile.

Volendo approfondire questa funzionalità ho quindi adottato questa soluzione.

Ecco un video in cui, usando GeoExplorer (integrato in OpenGeoSuite …), è possibile consultare tutti i 149 layer messi a disposizione

 mentre ecco un video in cui, alcuni dei layer dei civici puntuali sono consultati come layer WMS da un client QGIS

dimostrando quindi come, se ce ne fosse ancora bisogno, grazie all’adozione di servizi GIS esposti secondo standard di interoperabilità e con architetture in grado di scalare opportunamente sia possibile offrire dati geografici a diversi fruitori, sia gis desktop (commerciali e non), sia web browser (usando librerie open source quali OpenLayers, Leaflet, ecc .. , ma anche usando soluzioni commerciali), sia mobile, ma a questo punto diventa un puro esercizio informatico che non ha grande valore aggiunto quindi mi fermo qui.

GeoServer: per saperne di più …. Advanced Training


Un sito che illustra nel dettaglio alcuni aspetti di approfondimento di GeoServer 2.2.

Ecco alcuni esempi di particolare interesse:

Davvero un utile riferimento per chi vuole muovere i primi passi “professionali” in GeoServer per apprezzarne appieno le potenzialità.

Categorie:Open Source Tag:

OpenGeo investe nella comunità QGIS


Sul blog di OpenGeo oggi è apparso un post che annuncia l’interesse di OpenGeo nell’investire in QGIS desktop.

La notizia ha una certa rilevanza visto che OpenGeo sinora si è storicamente concentrata sulle componenti server enterprise: la sua OpenGeo Suite che si basa infatti sulla OpenGeo Architecture  costituita da PostGIS, GeoServer, GeoWebCache, OpenLayers e GeoExt.

In questo scenario mancava una soluzione GIS Desktop matura che permettesse di completare la suite e la scelta sembra essere caduta su QGIS che sicuramente è il tool GIS Desktop open source più ampiamente diffuso ed utilizzato, con una nutrita e quanto mai vivace comunità e che si appresta a rilasciare la release 2.0.

Questa notizia potrebbe rivelarsi una svolta importante nel panorama delle soluzioni GIS open source visto che nell’offerta di OpenGeo si va a completare un tassello sinora non integrato.

Le potenzialità sono molte e tutte decisamente interessanti:

  • integrazione di QGIS nella OpenGeoSuite diventando uno strumento non solo per fare gis desktop ma anche un modo per fare configurazione della suite stessa: gli utenti della suite potranno quindi prossimamente creare, analizzare, pubblicare e consumare dati e servizi geospaziali
  • integrazione di QGIS con GeoGit, la soluzione per il versionamento dell’informazione spaziale su sui OpenGeo sta lavorando. Gli utenti desktop saranno in grado di lavorare su dati geospaziali in ambienti distribuiti o parzialmente disconnessi. Il client GeoGit in QGIS permetterà non solo agli utenti di gestire i loro repository e quindi le proprie versioni, ma anche di avere a disposizione l’intero contesto di QGIS, rendendo GeoGit un altro data source dentro QGIS, esattamente come ogni altro database o servizio OGC

Si prospettano quindi orizzonti interessanti per il GIS open source: attendiamo impazienti e fiduciosi!

Fonte: OpenGeo Blog

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:

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

GMLGeoserver

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

Rendering Transformation in GeoServer: calcolo dinamico di interpolated surface e di contour map


Partendo da un post sul blog di OpenGeo ho voluto approfondire un po’ la potenzialità che GeoServer offre sia in termini di:

  • rendering transformation
  • chaining di processi
  • utilizzo di processi WPS all’interno di stili SLD

Ho provato a replicare l’esempio del calcolo delle isoterme partendo da dei dati “inventati” che simulano la presenza di centraline meteo sul territorio piemontese: non ho infatti trovato in rete dati analoghi georeferenziati e disponibili. Per chi volesse replicare ecco i dati che ho utilizzato.

Ho quindi creato per prima cosa un layer in GeoServer delle Centraline Meteo la cui visualizzazione corrisponde ad una getMap WMS con la seguente struttura

http://localhost:8080/geoserver/MyWorkspace/wms?service=WMS&version=1.1.0&request=GetMap&layers=MyWorkspace:CentralineMeteo&styles=&bbox=318287.0,4880823.0,515945.0,5142603.0&width=386&height=512&srs=EPSG:32632&format=application/openlayers

CentralineMeteo

La creazione delle isoterme la si può ottenere concatenando (chaining), due processi WPS messi a disposizione da GeoServer e precisamente, Barnes Surface Process e Contour Process, usando il meccanismo delle rendering transformation definite come stile SLD. L’output del primo processo (il calcolo della superficie, che è sostanzialmente quello delle fasce di temperatura), costituisce l’input del secondo processo (che è il calcolo delle isoterme).

Vediamo quindi dapprima il solo calcolo delle fasce di temperatura la cui visualizzazzione viene ottenuta con la medesima getMap vista in precedenza con in più l’utilizzo di un opportuno stile SLD al cui interno viene utilizzato il processo WPS Barnes Surface valorizzando opportunamente i parametri necessari.

La nuova getMap WMS sarà quindi di questo tipo (in evidenza l’utilizzo dello stile):

http://localhost:8080/geoserver/MyWorkspace/wms?service=WMS&version=1.1.0&request=GetMap&layers=MyWorkspace:CentralineMeteo&styles=FasceTemperatura&bbox=318287.0,4880823.0,515945.0,5142603.0&width=386&height=512&srs=EPSG:32632&format=application/openlayers

BarnesSurface

Ecco invece la definizione dello stile SLD utilizzato

<?xml version=”1.0″ encoding=”ISO-8859-1″?>
<StyledLayerDescriptor version=”1.0.0″
xsi:schemaLocation=”http://www.opengis.net/sld StyledLayerDescriptor.xsd”
xmlns=”http://www.opengis.net/sld&#8221;
xmlns:ogc=”http://www.opengis.net/ogc&#8221;
xmlns:xlink=”http://www.w3.org/1999/xlink&#8221;
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”&gt;
<NamedLayer>
<Name>Barnes surface</Name>
<UserStyle>
<Title>Barnes Surface</Title>
<Abstract>A style that produces a Barnes surface using a rendering transformation</Abstract>
<FeatureTypeStyle>
<Transformation>
<ogc:Function name=”gs:BarnesSurface”>
<ogc:Function name=”parameter”>
<ogc:Literal>data</ogc:Literal>
</ogc:Function>
<ogc:Function name=”parameter”>
<ogc:Literal>valueAttr</ogc:Literal>
<ogc:Literal>Temperatur</ogc:Literal>
</ogc:Function>
<ogc:Function name=”parameter”>
<ogc:Literal>scale</ogc:Literal>
<ogc:Literal>1000</ogc:Literal>
</ogc:Function>
<ogc:Function name=”parameter”>
<ogc:Literal>convergence</ogc:Literal>
<ogc:Literal>0.3</ogc:Literal>
</ogc:Function>
<ogc:Function name=”parameter”>
<ogc:Literal>passes</ogc:Literal>
<ogc:Literal>100</ogc:Literal>
</ogc:Function>
<ogc:Function name=”parameter”>
<ogc:Literal>minObservations</ogc:Literal>
<ogc:Literal>2</ogc:Literal>
</ogc:Function>
<ogc:Function name=”parameter”>
<ogc:Literal>maxObservationDistance</ogc:Literal>
<ogc:Literal>0</ogc:Literal>
</ogc:Function>
<ogc:Function name=”parameter”>
<ogc:Literal>pixelsPerCell</ogc:Literal>
<ogc:Literal>25</ogc:Literal>
</ogc:Function>
<ogc:Function name=”parameter”>
<ogc:Literal>queryBuffer</ogc:Literal>
<ogc:Literal>2000</ogc:Literal>
</ogc:Function>
<ogc:Function name=”parameter”>
<ogc:Literal>outputBBOX</ogc:Literal>
<ogc:Function name=”env”>
<ogc:Literal>wms_bbox</ogc:Literal>
</ogc:Function>
</ogc:Function>
<ogc:Function name=”parameter”>
<ogc:Literal>outputWidth</ogc:Literal>
<ogc:Function name=”env”>
<ogc:Literal>wms_width</ogc:Literal>
</ogc:Function>
</ogc:Function>
<ogc:Function name=”parameter”>
<ogc:Literal>outputHeight</ogc:Literal>
<ogc:Function name=”env”>
<ogc:Literal>wms_height</ogc:Literal>
</ogc:Function>
</ogc:Function>
</ogc:Function>
</Transformation>
<Rule>
<RasterSymbolizer>
<!– specify geometry attribute of input to pass validation –>
<Geometry><ogc:PropertyName>the_geom</ogc:PropertyName></Geometry>
<Opacity>0.8</Opacity>
<ColorMap type=”ramp” >
<ColorMapEntry color=”#FFFF00″ quantity=”-990″ label=”nodata” opacity=”0″/>
<ColorMapEntry color=”#2E4AC9″ quantity=”-6″ label=”nodata”/>
<ColorMapEntry color=”#41A0FC” quantity=”-5″ label=”values” />
<ColorMapEntry color=”#58CCFB” quantity=”-4″ label=”values” />
<ColorMapEntry color=”#76F9FC” quantity=”-3″ label=”values” />
<ColorMapEntry color=”#6AC597″ quantity=”-2″ label=”values” />
<ColorMapEntry color=”#479364″ quantity=”-1″ label=”values” />
<ColorMapEntry color=”#2E6000″ quantity=”0″ label=”values” />
<ColorMapEntry color=”#579102″ quantity=”1″ label=”values” />
<ColorMapEntry color=”#9AF20C” quantity=”2″ label=”values” />
<ColorMapEntry color=”#B7F318″ quantity=”3″ label=”values” />
<ColorMapEntry color=”#DBF525″ quantity=”4″ label=”values” />
<ColorMapEntry color=”#FAF833″ quantity=”5″ label=”values” />
<ColorMapEntry color=”#F9C933″ quantity=”6″ label=”values” />
<ColorMapEntry color=”#F19C33″ quantity=”7″ label=”values” />
<ColorMapEntry color=”#ED7233″ quantity=”8″ label=”values” />
<ColorMapEntry color=”#EA3F33″ quantity=”9″ label=”values” />
<ColorMapEntry color=”#BB3026″ quantity=”10″ label=”values” />
</ColorMap>
</RasterSymbolizer>
</Rule>
</FeatureTypeStyle>
</UserStyle>
</NamedLayer>
</StyledLayerDescriptor>

Occorre osservare che, mentre è piuttosto semplice l’applicazione del processo, è  molto più delicato il processo che porta alla corretta definizione e valorizzazione dei parametri che ne governano il risultato e la sua rappresentazione. Non è infatti chiarissima la documentazione riportata in GeoServer a tale scopo e per raggiungere un qualche risultato apprezzabile sono dovuto ricorrrere al supporto della GeoServer user list di cui vi lascio il riferimento per i dettagli.

Per la creazione delle isoterme la visualizzazzione viene ottenuta sempre con la stessa getMap vista in precedenza con l’utilizzo di un nuovo stile SLD al cui interno sono concatenati il processo di WPS Barnes Surface visto in precedenza che fornisce in input il proprio risulttao al processo WPS Contours.

La nuova getMap WMS sarà quindi di questo tipo (in evidenza l’utilizzo dello stile):

http://localhost:8080/geoserver/MyWorkspace/wms?service=WMS&version=1.1.0&request=GetMap&layers=MyWorkspace:CentralineMeteo&styles=FasceTemperatura-Isoterme&bbox=318287.0,4880823.0,515945.0,5142603.0&width=386&height=512&srs=EPSG:32632&format=application/openlayers

Isoterme

Ecco invece la definizione dello stile SLD utilizzato

<?xml version=”1.0″ encoding=”ISO-8859-1″?>
<StyledLayerDescriptor version=”1.0.0″
xsi:schemaLocation=”http://www.opengis.net/sld StyledLayerDescriptor.xsd”
xmlns=”http://www.opengis.net/sld&#8221;
xmlns:ogc=”http://www.opengis.net/ogc&#8221;
xmlns:xlink=”http://www.w3.org/1999/xlink&#8221;
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”&gt;
<NamedLayer>
<Name>BarnesContours</Name>
<UserStyle>
<Title>Barnes Surface Contours</Title>
<Abstract>Extracts contours from a computed surface</Abstract>
<FeatureTypeStyle>
<Transformation>
<ogc:Function name=”gs:Contour”>
<ogc:Function name=”parameter”>
<ogc:Literal>data</ogc:Literal>
<ogc:Function name=”gs:BarnesSurface”>
<ogc:Function name=”parameter”>
<ogc:Literal>data</ogc:Literal>
</ogc:Function>
<ogc:Function name=”parameter”>
<ogc:Literal>valueAttr</ogc:Literal>
<ogc:Literal>Temperatur</ogc:Literal>
</ogc:Function>
<ogc:Function name=”parameter”>
<ogc:Literal>scale</ogc:Literal>
<ogc:Literal>10000</ogc:Literal>
</ogc:Function>
<ogc:Function name=”parameter”>
<ogc:Literal>convergence</ogc:Literal>
<ogc:Literal>0.5</ogc:Literal>
</ogc:Function>
<ogc:Function name=”parameter”>
<ogc:Literal>passes</ogc:Literal>
<ogc:Literal>3</ogc:Literal>
</ogc:Function>
<ogc:Function name=”parameter”>
<ogc:Literal>minObservations</ogc:Literal>
<ogc:Literal>1</ogc:Literal>
</ogc:Function>
<ogc:Function name=”parameter”>
<ogc:Literal>maxObservationDistance</ogc:Literal>
<ogc:Literal>70000</ogc:Literal>
</ogc:Function>
<ogc:Function name=”parameter”>
<ogc:Literal>pixelsPerCell</ogc:Literal>
<ogc:Literal>10</ogc:Literal>
</ogc:Function>
<ogc:Function name=”parameter”>
<ogc:Literal>outputBBOX</ogc:Literal>
<ogc:Function name=”env”>
<ogc:Literal>wms_bbox</ogc:Literal>
</ogc:Function>
</ogc:Function>
<ogc:Function name=”parameter”>
<ogc:Literal>outputWidth</ogc:Literal>
<ogc:Function name=”env”>
<ogc:Literal>wms_width</ogc:Literal>
</ogc:Function>
</ogc:Function>
<ogc:Function name=”parameter”>
<ogc:Literal>outputHeight</ogc:Literal>
<ogc:Function name=”env”>
<ogc:Literal>wms_height</ogc:Literal>
</ogc:Function>
</ogc:Function>
<ogc:Function name=”parameter”>
<ogc:Literal>queryBuffer</ogc:Literal>
<ogc:Literal>10000</ogc:Literal>
</ogc:Function>
</ogc:Function>
</ogc:Function>
<ogc:Function name=”parameter”>
<ogc:Literal>levels</ogc:Literal>
<ogc:Literal>-6</ogc:Literal>
<ogc:Literal>-5</ogc:Literal>
<ogc:Literal>-4</ogc:Literal>
<ogc:Literal>-3</ogc:Literal>
<ogc:Literal>-2</ogc:Literal>
<ogc:Literal>-1</ogc:Literal>
<ogc:Literal>0</ogc:Literal>
<ogc:Literal>1</ogc:Literal>
<ogc:Literal>2</ogc:Literal>
<ogc:Literal>3</ogc:Literal>
<ogc:Literal>4</ogc:Literal>
<ogc:Literal>5</ogc:Literal>
<ogc:Literal>6</ogc:Literal>
<ogc:Literal>7</ogc:Literal>
<ogc:Literal>8</ogc:Literal>
<ogc:Literal>9</ogc:Literal>
<ogc:Literal>10</ogc:Literal>
</ogc:Function>
<ogc:Function name=”parameter”>
<ogc:Literal>simplify</ogc:Literal>
<ogc:Literal>true</ogc:Literal>
</ogc:Function>
</ogc:Function>
</Transformation>
<Rule>
<Name>rule1</Name>
<Title>Isotherm</Title>
<ogc:Filter>
<ogc:PropertyIsEqualTo>
<ogc:Function name=”IEEERemainder”>
<ogc:Function name=”int2ddouble”>
<ogc:PropertyName>value</ogc:PropertyName>
</ogc:Function>
<ogc:Function name=”parseDouble”>
<ogc:Literal>1.0</ogc:Literal>
</ogc:Function>
</ogc:Function>
<ogc:Literal>0</ogc:Literal>
</ogc:PropertyIsEqualTo>
</ogc:Filter>
<LineSymbolizer>
<Stroke>
<CssParameter name=”stroke”>#000000</CssParameter>
<CssParameter name=”stroke-width”>1</CssParameter>
</Stroke>
</LineSymbolizer>
<TextSymbolizer>
<Label>
<ogc:Function name=”round”>
<ogc:PropertyName>value</ogc:PropertyName>
</ogc:Function>
</Label>
<Font>
<CssParameter name=”font-family”>Arial</CssParameter>
<CssParameter name=”font-style”>Normal</CssParameter>
<CssParameter name=”font-size”>12</CssParameter>
</Font>
<LabelPlacement>
<LinePlacement/>
</LabelPlacement>
<Halo>
<Radius>
<ogc:Literal>2</ogc:Literal>
</Radius>
<Fill>
<CssParameter name=”fill”>#FFFFFF</CssParameter>
<CssParameter name=”fill-opacity”>0.6</CssParameter>
</Fill>
</Halo>
<Fill>
<CssParameter name=”fill”>#000000</CssParameter>
</Fill>
<Priority>2000</Priority>
<VendorOption name=”followLine”>true</VendorOption>
<VendorOption name=”repeat”>100</VendorOption>
<VendorOption name=”maxDisplacement”>50</VendorOption>
<VendorOption name=”maxAngleDelta”>30</VendorOption>
</TextSymbolizer>
</Rule>
</FeatureTypeStyle>
</UserStyle>
</NamedLayer>
</StyledLayerDescriptor>

Ecco infine la visualizzazione contemporanea dei tre layers

AllTogheter

Come si vede la mappa è sempre ottenuta grazie ad una chiamata http su un protocollo OGC standard quale il WMS ampiamente adottato nel mondo GIS e questo permette di rendere indipendente il “servzio di business” dal suo fruitore, tant’è che la medesima mappa la si può fruire da un client GIS Desktop quale QGIS come mostra l’immagine successiva.

GeoServer-QGIS

come pure un’applicazione gis mobile in grado di “consumare” WMS: ho provato con Locus Free  installato su un Samsung Galaxy e via wi-fi non ho avuto problemi ad agganciare il mio GeoServer installato localmente sul mio pc e a visualizzare le mie isoterme anche da questo tipo di fruitore.

Al tempo stesso questo approccio permette di nascondere completamente la complessità del processo (anzi, nel caso specidico “dei” processi visto che sono due e concatenati …..), sottostanti mentre ne permette la fruizone secondo meccanismi noti e standard (chiamata wms via http ….), che qualunque fruitore GIS sa già utilizzare.

Concludo con un paio di punti:

  • quanto ho provato è una sorta di proof of concepts ed è ben lungi dall’essere un’algoritmo definitivo: non sono state fatte ad esempio considerazioni sui dati che probabilmente andrebbero fatte, quali ad  esempio la valutazione della quota altimetrica a cui si trova la stazione meteo (sfruttando un DEM?): i dati al momento sono stati considerati “piatti” tutti allo stesso livello
  • ho untilizzato GeoServer 2.2.3 su un pc Windows 7, 4 CPU, 8 Gbyte di RAM

 

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.

 

Where Camp EU 2013: alcune note

20 gennaio 2013 1 commento

Dal 18 al 19 Gennaio 2013 si è tenuto a Roma Where Camp 2013 presso Porta Futuro: riporto alune note della mia partecipazione che non saranno esaustive di tutti gli interventi ciò dovuto al fatto che il mio inglese è … diciamo …. un po “fuori allenamento”.

I partecipanti non erano moltissimi, orientivamemte tra i 30 e i 40: diciamo che Gennaio forse non è il periodo migliore per questi incontri e comunque la crisi si fa un po sentire per tutti. Ovviamente più nutrita la pattuglia italiana ma comunque discreta anche la presenza straniera

L’evento si è aperto con una presentazione di di Mark Killiffe sull’utilizzo di OSM in ambito umanitario in Africa, per mappare in zone degradate la presenza ad esempio di toilette: può sembrare a prima vista una cosa banale ed inutile ma occorre considerare che 3.41 milioni di persone all’anno muoiono per scarsa igiene dell’acqua. Non basta tuttavia mappare i punti ma occorre coinvolgere la popolazione per mantenere “vivo” il dato (situazioni di degrado e contaminazione, nuove toilette legate all’aumento delle popolazione, ecc ….).

Il dato deve essere pubblico e open e da qui l’uso di OSM: è stata realizzata una piattaforma open source denominata Taarifa

Altra presentazione è stata su CartoDB (Sandro Santilli). E’ stato fatto un esempio di utilizzo usando query spaziali su POSTGIS (una delle caratteristiche principali del prodotto), dopo aver caricato su POSTGIS i dati open data degli hotspots wi-fi: ad esempio i punti che ricadono nei dintorni di Porta Futuro, o quelli che ricadono dentro le aree verdi, ecc .. ), con anche tematizzazioni sui risultati ottenuti, esmepio tematizzare diversamemnte gli hotspots trovati sulla base della loro tipologie o le aree verdi sulla base del numero di hotspots che vi ricadono dentro.

Tutto quanto è stato fatto facendo dei filtri spaziali sul layer POSTGIS: molto potente da questo punto di vista anche se serve comunque una buona dose di conoscenza tecnica (le query spaziali non sono proprio alla portata di un utente entry-level ….) da parte di chi usa il back end.

Altra cosa interessante è che è open source (licenza BSD), e quindi ognuno se lo può installare sui propri server.

Francesco Stompanato ha presentato una soluzione mobile per raccolta dati in ambito World Food Programme (WFP): dopo alcuni approfondimenti la scelta è caduta su Open Data Kit.

E’ stata poi la volta di Paolo Corti fare una presentazione di GeoNode. Il prodotto di basa su Django, GeoServer e POSTGIS come tecnologie di base. Ad oggi permette di fare upload di shapefile (occorre caricare i singoli file, altre soluzioni “concorrenti” permettono di caricare lo zip dello shapefile che forse è più comodo ….), e GeoTiff in futuro sono previsti altri formati. L’upload dello shapefile crea un layer POSTGIS e successivamente si possono caricare i metadati (ad oggi mi sembra di aver capito che si basa su GeoNetwork ma forse è in corso un’attività per usare pyCSW ….).

Il backoffice per fare authoring della mappa si basa su GeoExplorer di OpenGeo: è possibile fare anche editing dei dati via web.

E’ previsto il supporto di WMS esterni.

Il prodotto è open source e si può quindi scaricare da GitHub.: tra qualche mese dovrebbe essere rilasciata una nuova versione

E’ stata poi la volta di Michael Gould dell’ESRI Educational Community (da qualche anno in ESRI ma con un passato nel mondo GIS Open ….), che ha parlato a braccio di ciò che è ESRI, coma lavora, come si relaziona con il mondo Open Source ecc … Molte delle cose riportate erano notizie che chi segue un po’ i vari post sulle rete forse conosceva già (GeoPortal come prodotto open source, le estensioni di ArcGIS Dekstop per fare editing su OSM, ArcGIS Desktop Home Edition a soli 100 $ annnui, le recenti acquisizioni di GeoIQ e di Geoloqui, ecc … ), ma sentirli riassunti dalla viva voce di un autorevole esponente ESRI è stato comunque interessante. La notizia più “curiosa” è stata quella che ESRI paga i propri dipendenti su base oraria “anche quando sono fuori ufficio” (sostanzialmente si fidano della professionalità dei dipendenti ….): un modo un po inusuale di lavorare anche se immagino comunque per obiettivi.

Bert Spaan di Waag Society ha tenuto invece un intervemto su CitySDK Mobility, un progetto che ha visto coinvolti diversi partners europei (Amsterdam, Roma, Helsinky, Lamia, Lisbona, Istanbul, Manchester e Barcellona), in un contesto di smart city per la partecipazione e la mobilità.

L’obiettivo è quello di pubblicare dati per la mobilità come open data e fornire delle API specifiche per il loro utilizzo (trasporto e traffico).  Tutti i dati possiedono una proprietà (location), e sono strutturati ed esposti in modo multiplo (excel, csv, shapefile, drf, ecc …). La localizzazione è si importante ma è un attributo (comune), a tutti gli “oggetti” e il progetto mette enfasi sugli oggetti, ognuno dei quali ovviamente avrà attributi descrittivi diversi

Il concetto di “mobilità” è, nel contesto del progetto, parecchio allargato perchè tratta le informazioni sui mezzi pubblici, le mappe, gli orari. il meteo, le informazioni in tempo reale sul traffico, sino ad arriavre ad includere le informazioni crowdsourced.

Il progetto utilizza OSM sfruttando i livelli informativi di interesse: strade, ferrovie, fermate autobus, metro, ecc ..  e supporta standard quali GTFS.

Altre presentazioni:

  • Topologia in PostGIS 2.0 (Sandro Santilli): introduzione alla topologia in POSTGIS 2.0 con un po di storia, cos’è la topologia, il modello concettuale
  • R: software per statistica molto potente e con una integrazione anche con le parti spaziali e di mappa
  • OSGeo Live (Luca Delucchi)

La prima giornata si è poi chiusa con un ampio dibattito a ruota libera su OSM e il suo futuro: qualità del dato, rinnovamento e differenziazione del sito (utente finale, mappatori, sviluppatori, ecc .. hanno esigenze diverse e ad oggi c’è un solo sitoe tutti si atterra lì), modelli di business (fare o meno una sorta di OMS Premium con dati di maggiore qualità/ certificazione? Chi lo fa?), ecc …

Il secondo giorno (con un po di defezioni ….) si è aperto con GeoAvalanche (Francesco Bartoli), una soluzione open source (GNU GPL v3), per raccogliere informazioni georiferite sulle valanghe. La soluzione è basata su una personalizzazione di Ushahidi e ha una componente server basata su GeoServer.

Si è proseguito con una anticipazione di quello che sarà GRASS 7 (Luca Delucchi). Lo sviluppo è iniziato nel 2008 con un gruppo di core developeers di 7-8 persone.

Dovrebbe essere rilasciato nel 2013 anche se non esiste ancora una data e una schedulazione, e comunque scaricabile e disponibile per test su Linux, Windows e MacOS

Drasticamente restrutturato: eliminato codice non utilizzato, miglioramenti e bug fixing, new features. Ecco un breve elenco di alcune caratteristiche:

  • eliminato Tcl/Tk GUI e sostituito ocn wxPython GUI
  • migliorata la parte sui dati vettoriali
  • migliorata la parte di scripting Python
  • librerie 3D raster
  • SQLite è il sistema di default come libreria db (no supporto parti spaziali per ora solo alfanumerici)
  • POSTGIS connection diretta per editing
  • supporto temporal GIS
  • supporto WPS: è possibile esporre processi in GRASS  così che questi possano essere agganciati da motori WPS (es, PyWPS)
  • GUI; map swipe
  • GUI: animation
  • Python: semplifica la programmazione e l’uso dei comandi
  • GUI: semplifica la user experience e l’uso dello strumento

L’ultimo intervento a cui ho assistito prima di lasciare il camp è stato quello di Laurence Penny che ha illustrato l’evoluzione delle mappe stradali / turistiche sin dai primordi passando per gli antichi romani, il medioevo, e pian piano sino ai giorni nostri. E’ stato possibile vedere anche alcuni esempi reali con guide turistiche di fine ‘700  o ‘800 scoprendo così che cose che ad oggi affascinano quali Street View o i navigatori per auto in realtà erano concetti e “implementazioni” già fatte più di 100 anni fa ovviamente su scala ridotta e con “tecnologie” completamente diverse.

Ecco un po di foto dell’evento: primo giorno e secondo giorno.

Aggiornamento (21/01/2013): corretti alcuni riferimenti ai nomi dei relatori su segnazione di Paolo Corti (grazie!) del quale vi segnalo anche il commento al post per ulteriori dettagli su GeoNode

GeoNews: ridurre le dimensioni del GeoJSON, Nokia HERE Maps, Linee guida per l’interoperabilità semantica attraverso i linked open data, ESRI acquista Geoloqui, tracciati record degli stradari e indirizzari, WhereCamp EU 2013 a Roma, GeoServer CSS module


Una breve raccolta eterogena di notizie raccolte sulla rete:

  • istruzioni su come ridurre le dimensioni del GeoJSON al fine di migliorare le prestazioni degli applicativi che sfruttano questo formato  di particolare interesse ad esmepio nel campo delle soluzioni su mobile. Cambiano le tecnologie, i protocolli ma i principi di base sono sempre gli stessi: ridurre il numero di vertici e la complessità delel geometrie allo stretto necessario e ridurre anche i dati associati ….
  • Nokia ha annunciato HERE Maps una soluzione di mapping free alternativo per IOS. E sembra essere la prima di una serie di novità che vanno da Firefox OS, il 3D e una piattaforma  di sviluppo per il mapping su Android
  • Pubblicate le Linee guida per l’interoperabilità semantica attraverso i linked open data. Il nuovo documento recepisce i commenti e i suggerimenti pervenuti nel periodo di consultazione pubblica, compresi quelli della Commissione Europea. Il testo fornisce i riferimenti necessari per le amministrazioni che intendono adottare meccanismi di interoperabilità semantica basati sul modello Linked Open Data
  • ESRI ha annunciato l’acquisto di Geoloqi una piattaforma  leader nei servizi di geocoding. Visto che già oggi ESRI offre servizi di geocoing in cloud, da questo acquisto c’è da aspettarsi  quindi evoluzioni nel breve – medio termine da parte del gigante di Redlands che sempre si più sembra spostarsi e posizionarsi nel mercato dei servizi di business (a tendere anche consumer magari non dirattamente ma alleandosi con qualche grosso attore di mercato ….)?
  • GEOforUS rende disponibili i link ai tracciati record degli stradari e indirizzari costruiti per il censimento della popolazione, abitazioni e edifici. Per quanto, come correttamente indicato che qusti possano poi essere modificati in quello che sarà la versione definitiva del progetto Anagrafe Nazionale Strade e Numeri Civici (ANSC)
  • Where CAMP EU 2013 si terrà a Roma dal 18 al 19 Gennaio 2013 presso  Porta Futuro, Via Galvani 108, 00153, Roma
  • OpenGeo ha annunciato un nuovo modulo per GeoServer per gestire gli sti dei layers usando i CSS

Fonti: Thematic Mapping Blog, GEOforUS, SlashGeo, OpenGeo

GFOSS 2012 e OSMit 2012: un breve resoconto

18 novembre 2012 2 commenti

Ecco un breve resoconto della tre giorni torinese di GFOSS 2012 e OSMit 2012 a cui ho avuto modo di partecipare.

Molti partecipanti (oltre 170 iscritti ….), interventi interessanti, un buon “fervore” sulle tecnologie GIS open source.

Nel mondo del GIS desktop direi che praticamente tutte le presentazioni hanno fatto riferimento a QGIS con la quasi totale assenza di altri attori (ricordo forse una presentazione che citava gvSIG, nessuna menzione di soluzioni alternative quali Udig o altri ancora. Anche l’utilizzo di GRASS, pur presente in diverse presentazioni, avviene spesso mediato da QGIS): viene quindi confermata la tendenza che vede QGIS una sorta di must de facto in questo campo.

Per il tier rappresentato dal livello data base questo è ampiamente coperto da POSTGIS. Rientra logicamente in questa categoria SQLite anche se gioca un ruolo leggermente diverso e per il quale di prefigura un possibile nuovo utilizzo.

A livello di soluzioni server enterprise la presenza più significativa è invece stata quella di GeoServer, anche se in una presentazione è stato citato QGIS Server come soluzione adottata.

Sul fronte mobile mi sarei aspettato una maggior numero di interventi di natura tecnica (soluzioni, framework , ecc … ), mentre ricordo solo un paio di interventi, uno di Alessandro Furieri, di inquadramento generale e più orientato agli standard OGC da usare su soluzioni mobile, e uno di Andrea Antonello (molto interessante), sull’evoluzione del mobile negli anni e della piattaforma mobile con accenno a GeoPaparazzi. Lo stesso QGIS per Android è stato dichiarato segnare un po’ il passo.

Completamente assenti invece presentazioni o accenni alle soluzioni cloud che invece si stanno affacciando anche sul mondo GIS: non le usa ancora nessuno in Italia? Possibile?

Anche se non sono riuscito a seguire tutte le presentazioni provo a riassumere e riportare alcune delle cose più interessanti, ovviamente a mio personale giudizio.

Uno dei primi interventi è stato quello relativo a QGIS di Paolo Cavallini che ha illustrato oltre alle caratteristiche già note del prodotto, quelle che saranno le prossime news e anche delle anticipazioni su caratteristiche funzionali future. A livello di news abbiamo:

  • possibilità di usare scale di colore sia per dati vettoriali sia per dati raster
  • una ristrutturazione della modalità di trattare i dati raster
  • ricampionamento dei raster
  • potenziamento della console Python
  • integrazione di Atlas per fare serie di mappa
  • miglioramento del  supporto standard OGC

Per il futuro invece:

  • ristrutturazione simbologie
  • completamento etichette
  • ristrutturazione sito e documentazione
  • miglioramento integrazione SEXTANTE
  • 3D Globe
  • accesso ad ORACLE nativo
  • WFST per QGIS Server
  • supporto multithread

E’ confermato un rallentamento sulla parte QGIS per Android.

Anche la presentazione di Andrea Aime su GeoServer ha illustrato quelle che saranno le future evoluzioni del prodotto e precisamente:

  • introduzione di linguaggi di scripting quali Python, Ruby, ecc .. per il  WPS
  • la possibilità di usare un solo geoserver per servizi diverse organizzazioni, enti, divisioni aziendali
  • supporto png 8 con canale alpha: immagini più piccole ma di qualità, come con il formato png24
  • supporto time ed elevation
  • rendering transformation: calcolo isolinee o heat maps fatte al volo durante il rendering
  • miglioramenti integrazione con GeoWebCache
  • supporto del WFS 2.0 (standard INSPIRE)  e supporto paginazione
  • supporto XSLT
  • chiamate asincrone su WPS

Si sta già lavorando sulla release 2.2.3 in cui si avranno:

  • Aggancio per autenticazione: LDAP o base dati e supporto diversi sistemi di autenticazione (CAS)
  • Configurazione di GeoServer  su database
  • GoeWebCache: possibilità di clustering
  • Catalogue server in geoserver

Nel futuro ci sono ipotesi di:

  • Supporto WCS 2.0
  • Supporto NoSQL DB

A livello di presentazioni di natura tecnologica interessante quella di Francesco Izzi del CNR su GeoPlatform, progetto nato nel 2010 e disponibile su github costituito da un client basato su GWT e uno strato di servizi Java. Al momento è alla versione 1.5.

Alessandro Furieri nel corso della sua presentazione ha annunciato che per l’implementazione del nuovo standard OGC GeoPackage (GPKG) la scelta è caduta su SpatiaLite e questa è sicuramente la notizia tecnologia di maggior interesse in prospettiva (il nuovo standard dovrebbe uscire nella sua versione definitiva a fine 2012 / inizio 2013)

A livello di presentazioni relativi a progetti sicuramente da citare è stato l’intervento di ISTAT a cura di Francesco Di Pede dal titolo “Censimento 2011: dal dato areale al dato puntuale. Numeri civici, edifici e popolazionein cui è stata messa enfasi sull’Anagrafe Nazionale delle Strade e Numeri Civici di sui tanto si sta parlando sul web in questo periodo. Sono stati presentati interessanti esempi di casi d’uso reali di questi  e altri dati georiferiti in possesso dell’ISTAT (vie, edifici, civici, ecc …). Purtroppo continua a  non essere chiarissimo quali, quanti e in quale modalità i dataset saranno resi disponibili, quindi se open data o meno.

Altra presentazione di progetto interessante è stata quella di Corrado D’Alessandro dal titolo Settimo Torinese con l’open source ottimizza la conoscenza del territorio. Il progetto è stato realizzato completamente con tecnologie open source e precisamente:

  • Postgis 2.0
  • QGIS Server 1.8
  • OpenLayers in QGIS client
  • GeoExt 3
  • PHP

La palma del miglior progetto presentato però mi sentirei di darla a quella de “Il portale delle reti tecnologiche di Regione Lombardia: un esempio di tecnologia aperta per la condivisione di informazioni e dati sulle reti tecnologiche” (rif. http://www.ors.regione.lombardia.it/cm/home.html  e http://195.254.250.104/gisclient/intro.php?topic=generic ), non tanto per la parte tecnologica, quanto per la completezza delle informazioni che sono rese disponibili dal progetto e consiglio chi interessato di provare a dargli un’occhiata.

Molto interessante anche il lavoro di ARPA Piemonte su “Acquisizione di misure nivologiche manuali georiferite tramite social media”, con un interessante utilizzo di Ushahidi, replicabile anche in altri contesti.

Nella giornata dedicata ad OSMIt le presentazioni più interessanti sono state quelle relative a:

  • Geographike che utilizza OSM per fare business con una replica della base dati di OSM per l’Italia aggiornata giornalmente (modalità documentata sul wiki di OSM). Le tecnologie usate sono POSTGIS come data base, Mapnik integrato con MapProxy per la distribuzione delle tiles: la documentazione tecnica è stato dichiarato che sarà resa pubblica.
  • Controllo dell’ortografia dei nomi delle strade realizzato da Daniele Forsi e disponibile via web www.forsi.it/osm/