postgresql | qualche tips, qualche tricks
Pubblicato da flaviorigolon in db-ing & geodb-ing il 13 gennaio 2012
Posto alcuni comandi pgsql che ho avuto modo di usare di recente dovendo maneggiare i formati date di Postgresql. Li metto cosi’ in ordine sparso e premetto che fanno riferimento ad un database usato per la gestione dei consumi energetici di impianti di illuminazione; pertanto alcuni commenti (personali) fanno riferimento a questo tipo di lavoro. Tuttavia vanno benissimo per qualsiasi altro db.
Sia data una tabella “tbl01″ che contiene un campo “anno” come stringa, “data01″, “data02″, “data03″, ”data04″ campi in formato date, “consumo_anno” come integer :
# comando SELECT per recuperare il valore del campo “anno” sul quale faremo le nostre operazioni:
mydb=# SELECT anno FROM tbl01 WHERE id=4;
anno
——
2010
(1 row)
Come si puo’ vedere si tratta di un campo varchar di 4 caratteri.
# comando SELECT che converte in numero (attualmente in formato testo) il campo “anno” della tabella “tbl01″:
mydb=# SELECT to_number(anno, ’9999′) FROM tbl01 WHERE id=4;
to_number
———–
2010
(1 row)
# comando SELECT per convertire in numero il campo “anno” e togliere 1:
mydb=# SELECT to_number(anno, ’9999′)-1 FROM tbl01;
?column?
———-
2009
2009
2008
2009
(4 rows)
# comando per convertire in data nel formato YYYYMMDD il valore del campo “anno”:
mydb=# SELECT to_date(anno,’YYYYMMDD’) FROM tbl01 WHERE id=4;
to_date
————
2010-01-01
(1 row)
# calcolo del 31 dicembre dell’anno precedente a quello in oggetto (con riferimento al campo “anno”):
mydb=# SELECT to_date(anno,’YYYYMMDD’)-1 FROM tbl01;
?column?
————
2009-12-31
2009-12-31
2008-12-31
2009-12-31
(4 rows)
# comando per calcolare la differenza tra una data chiamata “data1″ (inizio anno) e il 31 dicembre dell’anno precedente (giorni in eccesso inizio anno): siano data0=2008-12-29, data1=2009-01-12, data2=2009-12-31, data3=2009-12-31.
mydb=# SELECT data1-(to_date(anno,’YYYYMMDD’)-1) FROM tbl01 WHERE id=4;
?column?
———-
12
(1 row)
# comando per calcolare la differenza tra il 31 dicembre dell’anno precedente e la prima data “data0″ (giorni in difetto inizio anno):
mydb=# SELECT (to_date(anno,’YYYYMMDD’)-1)-data0 FROM tbl01 WHERE id=4;
?column?
———-
2
(1 row)
# comando per calcolare la differenza tra “data3″ e il 31 dicembre dell’anno in corso (giorni in eccesso fine anno):
mydb=# SELECT data3-(to_date(anno,’YYYYMMDD’)+364) FROM tbl01 WHERE id=4;
?column?
———-
0
(1 row)
# comando per calcolare la differenza tra il 31 dicembre dell’anno in corso e la “data2″ (giorni in difetto fine anno):
mydb=# SELECT (to_date(anno,’YYYYMMDD’)+364)-data2 FROM tbl01 WHERE id=4;
?column?
———-
0
(1 row)
===========================================================================
Supponiamo di avere due tabelle in relazione 1 a molti (tabella “a” e tabella “b”) con campo di collegamento (“id” della tabella “a” si collega a a_id della tabella “b”). Se vogliamo recuperare valori da entrambe le tabelle:
mydb=# SELECT a.campo1, b.campo2 FROM a,b WHERE a.id=b.a_id AND campo3=valore ORDER BY id;
===========================================================================
Quella che segue e’ una query su una tabella cosi’ strutturata:
| id | integer |
| utente_id | integer |
| data_lettura0 | date |
| energia_attiva_kwh_fase0_l0 | numeric(10,2) |
| energia_attiva_kwh_fase1_l0 | numeric(10,2) |
| energia_attiva_kwh_fase2_l0 | numeric(10,2) |
| energia_attiva_kwh_fase3_l0 | numeric(10,2) |
| totale_energia_attiva_kwh_l0 | numeric(12,2) |
| data_lettura1 | date |
| energia_attiva_kwh_fase0_l1 | numeric(10,2) |
| energia_attiva_kwh_fase1_l1 | numeric(10,2) |
| energia_attiva_kwh_fase2_l1 | numeric(10,2) |
| energia_attiva_kwh_fase3_l1 | numeric(10,2) |
| totale_energia_attiva_kwh_l1 | numeric(12,2) |
| data_lettura2 | date |
| energia_attiva_kwh_fase0_l2 | numeric(10,2) |
| energia_attiva_kwh_fase1_l2 | numeric(10,2) |
| energia_attiva_kwh_fase2_l2 | numeric(10,2) |
| energia_attiva_kwh_fase3_l2 | numeric(10,2) |
| totale_energia_attiva_kwh_l2 | numeric(12,2) |
| data_lettura3 | date |
| energia_attiva_kwh_fase0_l3 | numeric(10,2) |
| energia_attiva_kwh_fase1_l3 | numeric(10,2) |
| energia_attiva_kwh_fase2_l3 | numeric(10,2) |
| energia_attiva_kwh_fase3_l3 | numeric(10,2) |
| totale_energia_attiva_kwh_l3 | numeric(12,2) |
| anno | character varying(4) |
| inizio_anno | date |
| fine_anno | date |
| consumo_anno | integer |
# query per aggiornare la tabella delle letture (in un db che contiene le letture dei consumi di contatori elettrici) calcolando il consumo_anno nel caso in cui data_lettura0!=data_lettura1 per l’anno=’2009′:
energia_django=> UPDATE manager_letturailluminazione SET consumo_anno=(totale_energia_attiva_kwh_l3-totale_energia_attiva_kwh_l1)+((totale_energia_attiva_kwh_l1-totale_energia_attiva_kwh_l0)/(data_lettura1-data_lettura0)*(data_lettura1-(to_date(anno,’YYYYMMDD’)-1)))-((totale_energia_attiva_kwh_l1-totale_energia_attiva_kwh_l0)/(data_lettura1-data_lettura0)*(data_lettura3-(to_date(anno,’YYYYMMDD’)+364))) WHERE anno=’2009′ AND data_lettura0!=data_lettura1;
| id | integer |
GFOSS-DAY 2011 | Foggia
Pubblicato da flaviorigolon in blogging il 23 novembre 2011
Oggi 24 novembre 2011 inizia il quarto GFOSS-DAY. Dopo gli appuntamenti di Pontedera, Bolzano e Foligno è la volta di una sede pugliese.
Il programma è ricchissimo e denso di temi e da oggi è anche attivo, grazie all’università, il canale streaming a questo indirizzo: http://www.media.unifg.it/gfoss/
accorrete numerosi!
docky e la barra nera
Pubblicato da flaviorigolon in linuxing il 3 novembre 2011
Ho provato ad installare docky.
L’installazione avviene tramite apt o synaptic:
# apt-get install docky
Unico inconveniente iniziale è la presenza di una fastidiosissima fascia nera a lato (o sotto, a seconda del punto in cui abbiamo agganciato docky). Di questo veniamo anche avvisati da un messaggio che recita più o meno così “…enable composting…“. Per ovviare al problema è necessario un Compositing window manager. Per abilitarlo in Metacity agire come segue:
- lanciamo gconf-editor:
$ gconf-editor
Sul frame di sinistra ci posizioniamo su “apps > metacity > general“; poi, sulla destra, spuntiamo il checkbox in corrispondenza della voce “compositing_manager“.
Fatto: la barra nera dovrebbe scomparire.
Postgresql | Postgis | modificare i valori dei campi di una vista
Pubblicato da flaviorigolon in db-ing & geodb-ing, mapping il 31 ottobre 2011
Lavorando con Postgresql|Postgis mi capita spesso di avere delle tavole come viste “View” ottenute dal join di una tabella geomerica e di una tabella non-geometrica. Esempio: la tabella geometrica contiene poligoni (edifici) con un campo chiave (es= scheda); la tabella alfanumerica contiene tutti i dati relativi a quegli edifici + un campo chiave “scheda” come la prima.
Questo perché, in un lavoro svolto, un utente si occupava di gestire la parte geometrica (mediante QGIS) mentre un altro utente caricava i dati alfanumerici relativi ad un rilievo di edifici mediante interfaccia web (via PHP).
In un secondo momento quindi è stata creata una join fra le due tabelle in modo da generare tavole tematiche sulle condizioni e sull’uso di quegli edifici.
Ecco la View creata (siano “schede” e “schede_nogeom” rispettivamente la tabella geometrica e non-geometrica)
=> CREATE VIEW schede_cartogr AS SELECT scheda_nogeom.grado, scheda_nogeom.altezza, scheda_nogeom.volume, scheda_nogeom.piani, scheda_nogeom.note, scheda_nogeom.stcontetto, scheda_nogeom.punttetto, scheda_nogeom.stconprosp, scheda_nogeom.puntprosp, scheda_nogeom.stconserr, scheda_nogeom.puntserr, scheda_nogeom.stconsolai, scheda_nogeom.puntsolai, scheda_nogeom.stconmurat, scheda_nogeom.stcompl, scheda_nogeom.puntcompl, scheda_nogeom.d_uso_pint, scheda_nogeom.d_uso_pt, scheda_nogeom.d_uso_p1, scheda_nogeom.d_uso_p2, scheda_nogeom.d_uso_p3, scheda_nogeom.d_uso_p4, scheda_nogeom.d_uso_p5, scheda_nogeom.d_uso_compl, scheda_nogeom.d_uso_progetto, scheda_nogeom.d_uso_comp_grafica, scheda_nogeom.essenze_arboree, scheda_nogeom.emerg_arch, scheda_nogeom.h_pint, scheda_nogeom.h_pt, scheda_nogeom.h_p1, scheda_nogeom.h_p2, scheda_nogeom.h_p3, scheda_nogeom.h_p4, scheda_nogeom.h_p5, scheda_nogeom.vol_pint, scheda_nogeom.vol_pt, scheda_nogeom.vol_p1, scheda_nogeom.vol_p2, scheda_nogeom.vol_p3, scheda_nogeom.vol_p4, scheda_nogeom.vol_p5, scheda.area_gis, scheda_nogeom.foto1, scheda_nogeom.estratto_cartografico, scheda_nogeom.vol_residenza, scheda_nogeom.vol_comm_dir, scheda_nogeom.vol_artigianale, scheda_nogeom.vol_pubblico, scheda_nogeom.vol_misto, scheda_nogeom.puntmurat, scheda_nogeom.d_uso_vigente, scheda.gid, scheda.the_geom, scheda.scheda FROM scheda JOIN scheda_nogeom ON scheda.scheda::text = scheda_nogeom.scheda::text;
- Caricando questa vista in QGIS riusciamo quindi a consultare geometrie e tutti i valori colelgati. Ma se ad un certo punto voglio modificare un valore o alcuni valori della tabella? Abilitando l’editing sul layer “schede_cartogr” vediamo che possiamo modificare i valori ma al momento del salvataggio veniamo avvisati che non è possibile. Ci viene allora in aiuto la creazione di un RULE con istruzione “DO INSTEAD” in Postgresql . In sostanza si tratta di una regola che consente di modificare la (o le) tabelle origine agendo sulla vista.
In generale la sintassi è la seguente:
>= CREATE RULE nome_rule_da_creare AS ON UPDATE TO nome_della_view DO INSTEAD UPDATE nome_tabella_origine SET nome_campo=NEW.nome_campo WHERE campo_chiave=NEW.campo_chiave;
Ecco la definizione del RULE che ho usato:
=>CREATE RULE update_grado_schede_cartogr AS ON UPDATE TO schede_cartogr DO INSTEAD UPDATE scheda_nogeom SET grado=NEW.grado WHERE scheda=NEW.scheda;
D’ora in avanti possiamo modificare da QGIS il valore del campo “grado“; verrà aggiornato di conseguenza il valore della tabella originale.
Debian | creare scorciatoie da tastiera in Gnome
Pubblicato da flaviorigolon in linuxing il 31 ottobre 2011
Per impostare scorciatoie da tastiera personalizzate in gnome (su Debian) ho trovato questa splendida spiegazione. La riassumo brevemente.
- da terminale lanciamo gconf-editor:
$ gconf-editor
- nella finestra che compare ci spostiamo sulla voce “apps > metacity > keybinding_commands“
- sul pannello di destra compare un elenco di “command_nn“; selezioniamo il “command_1“
- doppio clic su “command_1” e impostiamo il percorso al programma che vogliamo eseguire: nel mio caso vorrei lanciare Iceweasel quindi inserisco “/usr/bin/iceweasel“
- ci spostiamo poi (nel pannello di sinistra) sulla voce “global_keybindings” , scegliamo il “command_1” scorrendo l’elenco che si presenta a destra; doppio clic su “command_1” e inseriamo la combinazione di tasti che vogliamo dare per il comando in questione: nel mio caso “<Control><Alt>i“.
- fatto: da ora in avanti schiacciando contemporaneamente CTRL+ALT+i si avvierà il browser web.
importare dati da tabella QGIS a LibreOffice
Pubblicato da flaviorigolon in linuxing, mapping il 27 ottobre 2011
Se durante una sessione di lavoro con QGIS vogliamo eseguire un “copia/incolla” di dati da una tabella ad un foglio di calcolo LibreOffice puo’ succedere che i dati “incollati” presentino alcuni problemi. In particolare i dati numerici decimali (aree di oggetti poligonali per esempio) vengono mantenuti come “testo” e non numero con tutte le conseguenze negative del caso: se vogliamo fare una somma di valori ottenimao un errore.
Come fare per ovviare a tutto cio’?
Andiamo per punti:
- dalla sessione QGIS apriamo la tabella attributi del layer interessato, selezioniamo tutte o parte delle righe che ci interessano e clicchiamo sul pulsante “copia le righe selezionate nel blocco appunti” che si trova in basso a sinistra della tabella.
- apriamo una sessione di LibreOffice Calc e andiamo su “modifica > incolla” oppure “CTRL+V“;
- ci si presenta la finestra di impostazione dei dati di import che si chiama “Importazione testo” (lo vediamo scritto in alto sulla barra della finestra di popup stessa);
- su “Tipo di carattere” lasciamo “Unicode” come da default e poi scegliamo il simbolo di delimitazione (dovrebbe andare bene la “tabulazione” come proposto); a questo punto ci troviamo i nostri dati nel foglio di calcolo;
- Se schiacciamo contemporaneqmente “CTRL+F8” vedremo alcuni valori diventare blu. Sono i valori numerici. Il resto rimane nero (il testo). In verde eventuali valori calcolati da altri campi (ma essendo dati appena importati non avremo alcun campo di colore verde).
- Nel mio caso ho una colonna che riporta l’area di elementi poligonali e, ahimè, i suoi valori non diventano blu ma rimangono neri. Significa che sono dati importati come testo. Se infatti selezioniamo le celle interessate, tasdo dx e “Formatta celle…” vedremo che il tipo di dato è impostato su “testo”.
- Modifichiamo questa impostazione impostando su “categoria=numero” e “formato=standard”; in questo modo, tornando sul foglio di calcolo e selezionando una delle celle interessate vedremo che il valore indicato nella “riga di digitazione” presenta un’apostrofo “‘“all’inizio. Questo significa che la cella dovrebbe contenere numeri ma il valore inserito è un testo. Nel mio caso trovo: ’1011.15.
- Il problema sta nel fatto che il nostro separatore dei decimali è la virgola “,” mentre i dati incollati hanno importato come separatore il punto “.”.
- Basta fare un “trova e sostituisci” (CTRL+ALT+F) sulle celle interessate e sostituire il punto con una virgola.
- A questo punto vedremo automagicamente comparire i nostri valori in blu (ergo sono diventati numeri a tutti gli effetti).
Dennis Ritchie se n’è andato
Pubblicato da flaviorigolon in blogging il 13 ottobre 2011
ciao Dennis…e grazie!
GFOSS-DAY 2011
Pubblicato da flaviorigolon in blogging, mapping il 26 settembre 2011
Si terrà a Foggia il quarto GFOSS-DAY. Dopo le edizioni di Pontedera, Bolzano e Foligno quest’anno si sposta in Puglia. L’evento interesserà le giornate del 24 e 25 novembre e sarà caratterizzato da un nutrito calendario di eventi.
Per maggiori dettagli e specifiche teniamo d’occhio il sito dell’associazione http://gfoss.it in particolare la pagina http://gfoss.it/drupal/gfossday2011
array_to_string in Postgresql ovvero il problema della “battaglia navale”
Pubblicato da flaviorigolon in db-ing & geodb-ing, mapping il 27 agosto 2011
Premetto come per ogni post su questo blog che quanto scrivo è frutto di tentativi e ricerche per risolvere un problema pratico che di volta in volta mi si presenta. Non è detto quindi che sia il modo migliore ed il più elegante; ogni feedback e/o consiglio è pertanto graditissimo.
Parto dall’inizio: dispongo di un grafo stradale (stradario comunale) archiviato in db Postgresql con estensione spaziale Postgis. La tabella contenente gli archi stradali si chiama “grafo_new”; in essa ogni arco di strada è spezzato all’intersezione con altri tratti. Questo comporta che una strada denomimata “Via Roma” sia composta da tanti archi. Inoltre il db contiene una griglia regolare di passo quadrato che identifica i quadranti del territorio comunale. Il problema da risolvere è: “Come faccio ad ottenere un elenco delle strade (in ordine alfabetico) che indichi anche il quadrante o i quadrantiall’interno dei quali la strada ricade”. Mi ricorda moltissimo il funzionamento della battaglia navale quando per colpire una nave avversaria di indicavano le coordinate: A7: acqua; B5: colpito; B6: colpito e affondato.
Un po’ come fa l’ottimo servizio maposmatic (http://www.maposmatic.org)
Ecco i passaggi che ho seguito:
1. creazione di una view in postgres che aggrega tutti i tratti di via con lo stesso nome:
#= CREATE VIEW view_grafo_union AS SELECT nome, ele_desc, ele_tipo, gid, ST_Multi(ST_Union(f.the_geom)) AS the_geom FROM grafo_new AS f GROUP BY nome ORDER BY nome;
2.creazione di una seconda view di intersezione spaziale tra il grafo e la griglia di quadranti:
#= CREATE VIEW view_grafo_union_quadrante AS SELECT ST_Intersection(r.the-geom, m.the_geom) AS intersection_geom, m.codice, r.nome FROM view_grafo_union AS r, quadrante_stradario AS m WHERE ST_Intersects(r.the_geom, m.the_geom);
3. Creazione di una query “array_to_string” che fornisca l’elenco di tutti i quadranti di instersezione per ogni tratto di strada:
#= SELECT DISTINCT a.nome, array_to_string(array(SELECT codice FROM view_grafo_union_quadrante AS b WHERE b.nome = a.nome),’,') FROM view_grafo_union_quadrante AS a ORDER BY nome;
Per salvare il risultato dell’ultima query su un file basta impartire prima della query il seguente comando:
#= \o /percorso/al/file/di/output.csv
Il CSV potrà poi essere aperto e gestito con Calc o altro editor di testo.
To be continued con snapshot e altri dettagli….
please make (y)our actions reflect (y)our words
Pubblicato da flaviorigolon in blogging il 14 giugno 2011
Ringraziando Andrea Borruso per averlo segnalato:…………please make your actions reflect your words
……senza parole














