mapping

QGIS | conditional labeling

QGIS si rivela (almeno per le mie necessita’) uno strumento sempre piu’ potente e versatile. A riguardo lascio un breve post su come impostare una etichettatura condizionale. Per spiegarsi: come fare per visualizzare le etichette (label) solamente di determinati oggetti di un layer (nel mio caso PostGIS)? Per questo devo ringraziare la lista qgis-users ed in particolare Andreas Neumann, Giuseppe Sucameli, Nathan Woodrow, Martin Dobias e Mayeul Kauffmann per avere sollevato la questione ed averne indicato la soluzione.

Nel mio caso specifico volevo “etichettare” soltanto alcune zone territoriali omogenee di PRG: in particolare le zone A, B, C, e D tralasciando quelle a servizi ed agricole (E ed F). Nella tabella attributi del layer vettoriale poligonale si trova un campo chiamato “AmbitoIdZona” che contiene le informazioni necessarie.

– Apriamo lo strumento “Layer Labeling Options” cliccando sull’icona relativa o tramite la finestra delle proprieta’ del layer interessato.

– Spuntiamo il tick “Etichetta questo vettore” e clicchiamo sul pulsante “Modifica espressione” (quello con il simbolo dell’espressione);

– Nel frame in basso scriviamo l’espressione:

CASE WHEN “AmbitoIdZona” IN (‘A’,’B’,’C’,’D’) THEN “AmbitoIdZona” || ‘;’ || “NumeroZona” END

Nota: nell’espressione l’etichetta comprende il valore di due campi “AmbitoIdZona” e “NumeroZona”. Il punto e virgola ‘;’ indica di andare a capo. Questa impostazione si configura nella sezione “Formattazione” ed in particolare valorizzando il campo “A capo con il carattere” nel quale si indica un carattere a piacere (nel mio caso il ‘;’ appunto).

 

Aggiornamento: come impostare etichette di colore diverso a seconda del valore contenuto nel campo da etichettare o in altro campo

Facciamo un esempio concreto: ho un layer poligonale che riporta gli ambiti di alcuni strumenti urbanistica attuativi. Uno dei tanti attributi si chiama “Stato” che puo’ contenere i due valori: ‘vigente’ o ‘decaduto’. Vogliamo fare in modo che l’etichetta riporti il nome dello strumento urbanistico (dato che risiede nel campo “Nome”) e sia di colore rosso se lo “Stato”=’decaduto’ e di colore verde se “Stato”=’vigente’.

Andiamo sulle proprietà del layer e ci posizioniamo sulla scheda “Etichette” quindi su “Testo”. Definiamo un colore di default (nel nostro caso il verde con RGB=0,255,0 e poi clicchiamo sull’icona riportata a destra “Sovrascrittura definita dai dati (espressione)”. Compare la finestra di configurazione dell’espressione e digitiamo quanto segue:

CASE WHEN nome_campo=’valore’ THEN color_rgb(255,0,0) END

che tradotto riportando i nostri dati diventa:

CASE WHEN “Stato”=’decaduto’ THEN color_rgb(255,0,0) END

In questo modo vedremo le etichette (il testo dell’etichetta) rosse nel caso in cui il campo “Stato” ha valore=’decaduto’ e verdi negli altri casi

 

 

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).

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;

QGIS | time manager

Ho provato un altro plugin di QGIS: time-manager.

E’ un plugin che consente di creare mappe “animate” in base a dati “temporizzati”. Nel mio test specifico ho provato a creare un’animazione che rappresenti l’evoluzione storica dell’edificato.

Avevo a disposizione lo SHP degli edifici contenente anche i dati relativi all’epoca di costruzione. Non si tratta di valori annui ma di range abbastanza dilazionati. Ma è risultato comunque molto utile e di impatto.

Ecco una gif animata (creata con GIMP) che ne è scaturita: appena riesco argomento meglio :-). E’ necessario cliccare sull’immagine per visualizzare l’animazione.

evoluzione storica dell’edificato elaborata con il plugin “time-manager” di QGIS (cliccare sull’immagine per visualizzare l’animazione)

Ma vediamo come è stata realizzata questa immagine.

Lo SHP di partenza contiene i poligoni degli edifici con alcuni attributi collegati tra i quali un campo “epoca_costruzione” che assume i seguenti valori:

– ante 1900;

– 1901-1935;

– 1936-1955;

– 1956-1982;

– 1983-1994;

– 1995-2012.

Ho applicato una vestizione “categorized” su questo campo costruendo una pseudo rampa colore che va dal giallo “timido” al rosso acceso.

Assieme allo SHP degli edifici, con la stessa suddivisione di epoca, avevo a disposizione anche le aree di circolazione; anche per queste ho tematizzato la vestizione in base all’epoca di costruzione.

Ho aggiunto altri due campi alla tabella degli attributi: un campo chiamato “time” di tipo stringa ed un campo chiamato “forever” anch’esso di tipo stringa (il tutto mediante il plugin “table-manager”).

Poichè il time-manager necessita di un campo che contenga dati temporali da fare scorrere nella “barra del tempo” del plugin stesso ho popolato il campo “time” a seconda dell’epoca di costruzione traducendo range di alcuni anni in dati annuali fittizi (utili al plugin per renderizzare). In particolare ho seguito questo schema:

epoca  ante 1900 corrisponde a time=2007-01-01

epoca 1901-1935 corrisponde a time=2008-01-01

epoca 1936-1955 corrisponde a time=2009-01-01

epoca 1956-1982 corrisponde a time=2010-01-01

epoca 1983-1994 corrisponde a time=2011-01-01

epoca 1995-2012 corrisponde a time=2012-01-01

Mentre il campo “forever” è stato popolato in maniera uguale per tutti con valore “2014-01-01“. Questo valore torna utile per indicare il momento finale del rendering.

finestra di lavoro in QGIS con evidenziati gli attributi dello SHP edifici

A questo punto si passa alla configurazione del time-manager. Cliccando su “Settings” si apre la finestra di impostazioni nella quale selezionare i layer da utilizzare nel rendering. Quando si seleziona un layer viene chiesto di indicare quale campo considerare per la variabile tempo (nel nostro caso “time”) e quale campo considerare per avere una deadline; nel mio caso avevo creato il campo “forever”. Una volta impostato la finestra di configurazione appare così:

Finestra di configurazione del time-manager

Impostato tutto. “Accendere” il plugin cliccando sul pulsante a sinistra del tasto “Settings” (il pulsante diventa verde). Quindi cliccare sul tasto “play” in basso a sinistra e vedremo scorrere l’animazione sul map canvas. Volendo salvare i fotogrammi basta cliccare sul tasto “Export Video“; ci verrà chiesto di indicare il percorso (directory) in cui salvare tutte le immagini.

Queste possono essere “montate” mediante il tool mencoder. Nel mio caso ho impartito il seguente comando (dopo essermi spostato nella directory contenente i frame da elaborare):

$ mencoder mf://*.PNG -mf fps=1 -o evoluzione_storica.avi -ovc lavc -lavcopts vcodec=mpeg4

ottenendo dopo qualche secondo il video in formato .avi.

Non potendo caricare sul blog (non ho il pacchetto che consente l’upload di video :-)) ho creato una GIF animata con GIMP.

La procedura è molto semplice. Una volta avviato GIMP andare su File -> Apri come livelli e selezionare tutti i fotogrammi in ordine di numerazione. Quindi salvare in formato GIF (nelle ultime versioni di GIMP non si esegue un “salva” ma un “esporta” in quanto il “salva” riguarda solo il formato nativo di GIMP). Al momento del salvataggio viene chiesto anche il tempo di permaneza di ogni fotogramma (impostato a 3000 millisecondi) e spuntare l’opzione “Come animazione“.

Ed infine un’altra animazione realizzata in base all’evoluzione storica degli ultimi 10 anni circa (dal 2001 al 2011).

legenda evoluzione edificato

postgis | ST_Reverse()

Un piccolo e breve post su una funzione di Postgis molto utile per invertire l’ordine di digitalizzazione dei vertici di un oggetto. Nel caso specifico si fa riferimento ad oggetti lineari. La funzione è (brevemente) documentata qui. Ed ecco un esempio pratico per invertire il senso di 3 linee identificate mediante il loro gid:

#= UPDATE nome_tabella_linee SET the_geom = ST_Reverse(the_geom) WHERE gid IN (8,128,46);

I valori dei “gid” indicati sono puramente esemplificativi.