GRASS GIS fund raising per Vienna Code Sprint 2014

Con molto piacere pubblico questa richiesta fondi per il prossimo GRASS GIS Code Sprint di Vienna
 
 
“Dear GRASS GIS Users,
 
In the occasion of the upcoming Vienna Code Sprint 2014 [1], the GRASS GIS Project Steering Committee decided to officially join this code sprint, considering the great opportunity for joint activities. More than 60+ developers from the most important OSGeo project communities will join the event.
While the GRASS developers are donating their valuable time, the community of enthusiast users may contribute with donations, even symbolic, that will be used to cover out-of-pocket expenses of the participants.
Companies can also decide to sponsor specific tasks! Please don’t hesitate to contact us for further details.
As usual, all of the work done in the community sprint will be directly contributed back to the GRASS project for the benefit of everyone who uses it. The scope is to publish a first release candidate of the stable GRASS GIS 6.4.4 version as well as a tech preview release of GRASS GIS 7. For further information don’t hesitate to contact Markus Neteler (neteler@osgeo.org).
 
For your convenience, here our easy-to-use Paypal button:
 
For our alternative bank transfer option, please contact Martin Landa (landa.martin
@gmail.com)”
 
Thanks for your support!
The GRASS Developers Team
 
 
 
 
About GRASS GIS
The Geographic Resources Analysis Support System (http://grass.osgeo.org/), commonly referred to as GRASS GIS, is an Open Source Geographic Information System providing powerful raster, vector and geospatial processing capabilities in a single integrated software suite. GRASS GIS includes tools for spatial modeling, visualization of raster and vector data, management and analysis of geospatial data, and the processing of satellite and aerial  imagery. It also provides the capability to produce sophisticated presentation graphics and hardcopy maps. GRASS GIS has been translated into about twenty languages and supports a huge array of data formats. It can be used either as a stand-alone application or as backend for other software packages such as QGIS and R geostatistics. It is distributed freely under the terms of the GNU General Public License (GPL). GRASS GIS is a founding member of the Open Source Geospatial Foundation (OSGeo).
Annunci

GRASS, QGIS | individuare collina e pianura di un territorio

Un collega mi ha chiesto di indicargli le percentuali di territorio (comunale) pianeggiante e collinare.

Avevo a disposizione un DEM con risoluzione 5m (realizzato con GRASS a partire dalle curve di livello della CTRN) ed il vettoriale del limite amministrativo.Tuttavia il DEM (chiamato dem_5m) ricopre un’area pressochè rettangolare ben più ampia del limite del comune ed avevo la necessità di “clipparlo” sul boundary di interesse. Ho agito per passi successivi utilizzando GRASS dall’interno di QGIS.

L’immagine sottostante illustra la situazione di partenza (dem e confine):

dtm e confine

dtm a 5 m e confine comunale

Ecco i passi seguiti:

– conversione del vettoriale del confine comunale in raster:

$ v.to.rast input=confine_comune out=confine_comune (comando lanciato dalla shell del plugin qgis grass)

– impostazione della regione di lavoro sul raster appena creato:

$ g.region rast=confine_comune res=5

– creazione di una MASK dal confine per clippare il dem su di esso in un secondo momento:

$ r.mask input=confine_comune

– clip del dem per delimitarlo al territorio comunale (con r.mapcalc); si ottiene un raster che chiameremo “dem_comune”:

$ r.mapcalc “dem_comune=dtm_5m – confine_comune”

– calcolo del territorio considerato collinare (da una stima si è deciso di considerare tale il territorio con quota > 120 m s.l.m. in quanto rappresenta la quota media del piede di collina dell’area di lavoro):

$ r.mapcalc “collina=dem_comune>120”

– e calcolo della pianura con il territorio che rimane a complemento:

$ r.mapcalc “pianura=dem_comune<=120”

Il risultato è il seguente:

i raster "collina" e "pianura" caricati con trasparenza al 50%

i raster “collina” e “pianura” caricati con trasparenza al 50%

Il passaggio succesivo consiste nel trasformare i raster in vettori mediante il modulo “r.to.vect“. Il calcolo della superficie e, di conseguenza, l’incidenza percentuale delle due porizioni di territorio sul totale vengono tralasciati (basta consultare le aree con lo strumento di interrogazione di QGIS o lanciare il modulo “v.report” in GRASS).

TileMill | prima installazione su Debian

In questo breve post volevo tenere traccia delle operazioni eseguite per installare TileMill su Debian. Sul sito si trovano i pacchetti per Ubuntu, Mac OS X e Windows…..Io uso Debian in genere (anche i due timidi serverini che gestisco) e volevo capire se era fattibile: si!

Ho seguito passo-passo le istruzioni riportate nella pagina “Building from source” e ne riassumo i passi salienti:

– controllare di avere i python development headers, libbz2, libicu, boost, icu, proj4 ed altre svariate librerie di immagini (synaptic aiuta molto);

– installare boost da sorgente (la versione pacchettizzata per Debian non è aggiornata) seguendo questi passi:

(piccolo inciso: in genere – ma questa è una mia prassi – le compilazioni le faccio all’interno di una directory chiamata “src” e per ogni pacchetto creo una subdirectory ad hoc).

creare una directory per la compilazione:

$ mkdir boost

spostarsi nella dir creata:

$ cd boost

scaricare il sorgente con:

$ wget http://voxel.dl.sourceforge.net/project/boost/boost/1.51.0/boost_1_51_0.tar.bz2

decomprimere il tar:

$ tar xjvf boost_1_51_0.tar.bz2

spostarsi nella dir ottenuta dalla decompressione:

$ cd boost_1_51_0

lanciare il comando

$ ./bootstrap.sh

poi in sequenza:

$ ./b2 stage toolset=gcc –with-thread –with-filesystem –with-python –with-regex -sHAVE_ICU=1 -sICU_PATH=/usr/ –with-program_options –with-system link=shared

$ ./b2 install toolset=gcc –with-thread –with-filesystem –with-python –with-regex -sHAVE_ICU=1 -sICU_PATH=/usr/ –with-program_options –with-system link=shared

infine autenticarsi come root ed impartire:

# ldconfig

Poi installare anche boost >= 1.47, icu, proj4, libpng, libjpeg, libtiff, libxml2, libltdl, e freetype (a meno di averle già)

– Passiamo ora all’installazione di Mapnik (motore di rendering per TileMill). Come prima creiamo una dir per la compilazione:

$ mkdir mapnik

ci spostiamo nella dir

$ cd mapnik

e scarichiamo il sorgente con:

$ wget https://github.com/downloads/mapnik/mapnik/mapnik-v2.1.0.tar.bz2

decomprimiamo:

$ tar xf mapnik-v2.1.0.tar.bz2

ci spostiamo nella nuova directory:

$ cd mapnik-v2.1.0

e lanciamo il configure:

$ ./configure (durante il configure sono stato avvisato della mancanza di alcune librerie – che mi erano sfuggite – le ho quindi installate con synaptic e poi ho reimpartito il configure)

poi il make

$ make

ed infine il make install (come root):

# make install

– E’ la volta di Node.js: compiliamo anche questo (come prima creiamo la dir di lavoro):

$ mkdir nodejs

ci spostiamo della dir nuova:

$ cd nodejs

scarichiamo il sorgente:

$ wget http://nodejs.org/dist/v${VERSION}/node-v${VERSION}.tar.gz (nel mio caso ho scaricato la versione v0.8.14 quindi la stringa “v${VERSION}” diventa “v0.8.14”)

decomprimiamo:

$ tar xf node-v0.8.14.tar.gz

ci spostiamo nella dir:

$ cd node-v0.8.14

e lanciamo configure, make e make install

$ ./configure && make

e come root:

# make install

Prima di passare all’installazione di TileMill installare un’altra dipendenza chiamata “libwebkit-dev” che si può tranquillamente installare con “apt-get install libwebkit-dev”

Ed ora passiamo a TileMill:

$ mkdir tilemill

ci spostiamo nella dir:

$ cd tilemill

scarichiamo il sorgente:

$ git clone https://github.com/mapbox/tilemill.git

poi si entra nella dir ottenuta:

$ cd tilemill

ed infine si installa tutto mediante “npm”

# npm install

<inizio NB>:La prima volta che ho lanciato “npm install” il comando è terminato con degli errori riferiti a nodejs. La causa era una versione troppo recente di nodejs avendo inizialmente installato la versione v0.9.1. Installando la v0.8.14 dopo avere rimosso la v0.9.1 tutto è andato a buon fine. La rimozione di nodejs si può fare così (fonte il mitico stackoverflow):

– lanciare il comando “which node” che dovrebbe ritornare qualcosa come “/usr/local/bin/node”

– poi ci spostiamo in /usr/local/bin/node”

– e lanciamo come root:

# rm -r bin/node bin/node-waf include/node lib/node lib/pkgconfig/nodejs.pc share/man/man1/node.1

Poi possiamo ritornare a scaricare la nuova versione di nodejs ed a ricompilare. <fine /NB>

Una volta che tutto è compilato lanciare il comando:

$ ./index.js

compare l’interfaccia di TileMill. Analogo risultato si ottiene mediante un browser puntando su “http://localhost:20009&#8221;.

Ed ecco un paio di screenshot:

Tile Mill versione desktop

Tile Mill versione web

il mio primo “hello world” con TileMill

Il Repertorio Nazionale dei Dati Territoriali

Il Repertorio Nazionale dei Dati Territoriali

Oggi inserisco un post con il link al Repertorio Nazionale dei Dati Territoriali (RNDT). Attualmente questo strumento sta muovendo i primi passi, ma il desiderio è che entri a fare parte della “cassetta degli attrezzi” di ogni geomatico e, in prospettiva, di ogni cittadino italiano. Non sono solo, ma insieme a:”

QGIS web client | hyperlink

Una delle cose “cool” (come dicono gli americani) di un web gis è la possibilità di consultare gli attributi di un oggetto e magari essere reindirizzati ad altro link o file o pagina web per approfondire o avere maggiori informazioni sull’attributo selezionato.
Ad oggi QGIS web client offre due modi per consultare gli attributi: mediante il “fumetto” o “tooltip” o cliccando sull’oggetto dopo avere attivato il pulsante di consultazione attributi e “leggendo” i dati nel frame di destra che compare.
Se però vogliamo creare un hyperlink cliccabile non possiamo farlo con il tooltip in quanto si sposta allo spostarsi del mouse. A questo riguardo Andreas Neumann sta lavorando per fare in modo che il fumetto sia in pieno stile Openlayers. Qui si trova l’issue in merito.
Ma chiedendo in lista qgis-user è arrivato un provvidissimo suggerimento di Bernhard Ströbl (che ringrazio vivamente). Bernahrd ha suggerito di creare una VIEW (in database PostgreSQL/PostGIS) contenente un campo “link” formattato in pieno stile html. Ho provato e funziona! Riporto di seguito un esempio testato.

pc=# CREATE OR REPLACE VIEW prp_view AS SELECT “Denominazi” AS denominazione, tipo, ‘<a href=”http://ip_server/qgis-web-client/projects/deliberepdir/&#8217; || file_approvazione1 || ‘”‘ || ‘onclick=”window.open(this.href)”>consulta prima approvazione</a>’::TEXT AS link1, ‘<a href=”http://ip_server/qgis-web-client/projects/deliberepdir/&#8217; || file_approvazione2 || ‘”‘ || ‘onclick=”window.open(this.href)”>consulta seconda approvazione</a>’::TEXT AS link2, ‘<a href=”http://ip_server/qgis-web-client/projects/deliberepdir/&#8217; || file_approvazione3 || ‘”‘ || ‘onclick=”window.open(this.href)”>consulta terza approvazione</a>’::TEXT AS link3, ‘<a href=”http://ip_server/qgis-web-client/projects/deliberepdir/&#8217; || file_approvazione4 || ‘”‘ || ‘onclick=”window.open(this.href)”>consulta quarta approvazione</a>’::TEXT AS link4, ‘<a href=”http://ip_server/qgis-web-client/projects/deliberepdir/&#8217; || file_approvazione5 || ‘”‘ || ‘onclick=”window.open(this.href)”>consulta quinta approvazione</a>’::TEXT AS link5, ‘<a href=”http://ip_server/qgis-web-client/projects/deliberepdir/&#8217; || file_approvazione6 || ‘”‘ || ‘onclick=”window.open(this.href)”>consulta sesta approvazione</a>’::TEXT AS link6, the_geom, gid FROM sua;

In questo modo cliccando sulla voce relativa (“prima approvazione”, “seconda approvazione” e così via) che compare nel frame di destra si apre il file PDF in questione.

QGIS web client | search

Questo post tratta nuovamente Qgis web client: in particolare come viene gestita la ricerca delle feature.

Seguendo la doc disponibile in rete (e all’interno del pacchetto) al punto 6 si parla dello script python per la gestione della ricerca. Tutto sembra ok. Tuttavia la doc illustra come creare una tabella per la ricerca; ma una tabella puo’ diventare “statica” nel momento in cui i dati del database (nel nostro caso PostgreSQL/PostGIS) vengono aggiornati. In questo caso una view diventa l’ideale in quanto “dinamica” anche se i tempi di ricerca possono risultare superiori rispetto ad una tabella.

Calando il tutto nel concreto del nostro applicativo facciamo alcune considerazioni. Dispongo di un DB con molti strati informativi. Nel progetto “.qgs” in questione ci sono tre layer sui quali vorrei eseguire la ricerca: uno relativo agli edifici, uno relativo alle strade ed uno relativo alle particelle catastali. Il primo step consiste nella creazione di una view per la ricerca delle strade. Ecco come viene definita:

#= CREATE OR REPLACE VIEW search_particella AS SELECT ‘Foglio’ || “Foglio” || ‘,’ || ‘Mappale’ || “Mappale” AS searchstring, ‘Foglio’||”Foglio”||’, ‘||’Mappale’||”Mappale”::TEXT AS displaytext, ’03_particella’::TEXT AS search_category, the_geom, ‘MULTIPOLYGON’::TEXT AS geometry_type, to_tsvector(“Foglio”||’, ‘||”Mappale”::TEXT) AS searchstring_tsvector FROM particella;

Una seconda view è stata creata per la ricerca sugli edifici:

#= CREATE OR REPLACE VIEW search_schede_a AS SELECT codfoto AS searchstring, codfoto::TEXT AS displaytext, ’01_schede_a’::TEXT AS search_category, the_geom, ‘MULTIPOLYGON’::TEXT AS geometry_type, to_tsvector(codfoto::TEXT) AS searchstring_tsvector FROM schede_a;

Ed infine per le strade:

#= CREATE OR REPLACE VIEW search_strade AS SELECT nome AS searchstring, nome::TEXT AS displaytext, ’02_strade’::TEXT AS search_category, the_geom, ‘MULTILINESTRING’::TEXT AS geometry_type, to_tsvector(nome::TEXT) AS searchstring_tsvector FROM view_grafo_union_nome;

Altra considerazione importante: potendo gestire e pubblicare piu’ progetti (.qgs) differenti diventa essenziale fare in modo che ad ogni progetto possa essere abbinata una certa configurazione per la ricerca. Questo è possibile personalizando il file “search.wsgi” che si trova in “…/qgis-web-client/wsgi”. Basta rinominarlo in modo che richiami il progetto abbinato (es: “search_stradario.wsgi” per una progetto che pubblica lo stradario) e modificando la riga 18 secondo le proprie necessità. Esempio:

“…….
searchtables = [‘search_strade‘]; # enter your default searchtable(s) here # aggiungere qui ‘a mano’ i nomi delle tabella di ricerca
searchtablesstring = ”;
…”

Come si puo’ vedere abbiamo indicato qui il nome della tabella (nel nostro caso una VIEW) da usare per effettuare la ricerca. Se volessimo utilizzare piu’ tabelle (o VIEW) basta aggiungerle separandole con una virgola. Nel nostro caso potrebbe diventare:

“…….
searchtables = [‘search_strade‘, ‘search_particella‘]; # enter your default searchtable(s) here # aggiungere qui ‘a mano’ i nomi delle tabella di ricerca
searchtablesstring = ”;
…”

Non dimenticare poi che bisogna modificare anche il corrispondente file “GlobalOptions.js” relativo. Nel mio caso ho creato un file per ognuno dei progetti. Per esempio per il progetto dello stradario ho creato un “GlobalOptionsStradario.js” (ed un “getSearchGeom_stradario.js”) all’interno del quale alla righe 14 e 15 ho indicato il path ai file da utilizzare per la search.

“….

var searchBoxQueryURL = “/qgis-web-client/wsgi/search_stradario.wsgi?query=”; // “/wsgi/search.wsgi?query=”;
var searchBoxGetGeomURL = “/qgis-web-client/wsgi/getSearchGeom_stradario.wsgi”; // “/wsgi/getSearchGeom.wsgi”;

…..”

Allego snapshot che mostra la ricerca di un mappale; digitando semplicemente il numero del foglio (21) e ponendo una virgola subito dopo compariranno i mappali già filtrati per foglio. Cliccando su quello di interesse l’area geografica verrà portata alla sua boundingbox.

ricerca in qgis web client

QGIS web client | tooltip

Qgis web client è un framework webgis che consente di pubblicare un progetto Qgis (file con estensione .qgs) as is.

Tra le funzionalità presenti troviamo la possibilità di visualizzare come tooltip (una specie di “fumetto” dinamico che aggiorna i dati a seconda dell’oggetto su cui “insiste” il mouse) i dati delle feature.

Tuttavia attualmente non è possibile impostare quali attributi visualizzare; è necessario creare un nuovo campo chiamato proprio “tooltip” e popolarlo con i dati che si vogliono vedere. Nel mio esempio faccio riferimento a dati di alcuni edifici (memorizzati in tabella Postgis). Dopo avere creato il campo suddetto lo popoliamo:

=# UPDATE schede_a SET tooltip=’scheda: ‘ || codfoto || ‘ , tipologia: ‘ || tipologia_edilizia || ‘ , destinazione: ‘ || destusopre || E’\r\n’ || ‘volume: ‘ || volume_ft || ‘ , ‘ || ‘altezza: ‘ || altezza_media || ‘ , epoca: ‘ || epoca_costruzione || E’\r\n’ || ‘<img src=’ || ‘”‘ ||  immagine ||  ‘”‘ || ‘>’;

Analizziamo la stringa.

schede_a è il nome della tabella;

– poi si esegue un UPDATE sul campo “tooltip” popolandolo con note descrittive (le parti fra ‘apici singole’ unite (con il doppio pipe “||“) ai valori dei campi indicati (codfoto, tipologia_edilizia, destusopre,…..).

– la stringa E’\r\n consente di andare a capo. Questo è molto utile se i dati da visualizzare sono molti evitando di avere un “fumetto” troppo esteso in larghezza e di difficile lettura;

– l’ultima parte ‘<img src=’ || ‘”‘ ||  immagine ||  ‘”‘ || ‘>’ (in realtà un pezzo di condice html) consente di caricare e visualizzare una foto dell’edificio stesso; il campo “immagine” contiene il path (sul server di archiviazione) all’immagine da aprire.

Allego piccolo snapshot:

tooltip con visualizzazione dati di un edificio e relativa immagine

Una nota che potrebbe tornare utile: così facendo (creare un campo tootlip come “aggregazione” di piu’ campi) succede che nel tempo e’ necessario aggiornare di volta in volta i valori. Per evitare di doverlo fare manualmente si potrebbe creare un trigger che ad ogni INSERT o UPDATE dei record aggiorni di conseguenza tooltip. Altrimenti si potrebbe creare una VIEW che pesca tutti i valori della tabella edifici (escluso tooltip) aggiungendo il campo tooltip stesso in maniera “dinamica”. Ecco riportato il comando SQL per la creazione della VIEW che è stata poi caricata nel progetto QGIS.

#= SELECT schede_a.gid, schede_a.”KP”, schede_a.codfoto, schede_a.immagine, schede_a.codviaana4, schede_a.via1, schede_a.numciv1, schede_a.codviaana1, schede_a.via2, schede_a.numciv2, schede_a.codviaana2, schede_a.via3, schede_a.numciv3, schede_a.codviaana3, schede_a.via4, schede_a.numciv4, schede_a.destusopre, schede_a.utilizzazione, schede_a.epoca_costruzione, schede_a.altezza_media, schede_a.condizioni_fisiche, schede_a.tipologia_edilizia, schede_a.qual_stor_amb, schede_a.note, schede_a.fonte, schede_a.rilevatore, schede_a.dens_allog_utiliz, schede_a.dens_allog_nonutiliz, schede_a.tipo_mod, schede_a.data_mod, schede_a.link, schede_a.num_provv_orig, schede_a.num_provv_def, schede_a.volume_ft, schede_a.alloggi_occupati, schede_a.alloggi_nonoccupati, schede_a.superf_coperta, schede_a.alloggi_totali, schede_a.tipo_provv_orig, schede_a.tipo_provv_def, schede_a.the_geom, schede_a.anno, schede_a.”time”, schede_a.forever, ((((((((((((((((((‘scheda: ‘::text || schede_a.codfoto::text) || ‘ , tipologia: ‘::text) || schede_a.tipologia_edilizia::text) || ‘ , destinazione: ‘::text) || schede_a.destusopre::text) || ‘
‘::text) || ‘volume: ‘::text) || schede_a.volume_ft) || ‘ , ‘::text) || ‘altezza: ‘::text) || schede_a.altezza_media) || ‘ , epoca: ‘::text) || schede_a.epoca_costruzione::text) || ‘
‘::text) || ‘<img src=’::text) || ‘::text AS tooltip
FROM schede_a;