Da Postgresql 8.3 e Postgis 1.3.3 a Posgresql 8.4.11 e Postgis1.5.1 su Debian stable

Con questo post volevo tenere traccia della procedura di aggiornamento e migrazione dati da Postgresql 8.3 e Postgis 1.3.3 a Posgresql 8.4.11 e Postgis1.5.1.

Ho seguito questa utilissima pagina wiki

Sul nostro server “girano” attualmente Postgresql 8.3 e Postgis 1.3.3.

1- Facciamo dapprima il backup dei database presenti (il comando va lanciato per ogni db presente nel cluster).

$ PGUSER=postgres pg_dump -Fc nome_db > /percorso/alla/dir/di/dump/nome_db.dmp

NB: pg_dump con l’opzione -Fc crea un archivio compresso (un tar compresso con gzip, ovvero un tar.gz).

Nel caso si trattasse di db non spaziale e’ sufficiente dare:

$ PGUSER=postgres pg_dump -c nome_db > /percorso/alla/dir/di/dump/nome_db.sql

2- Stoppiamo Postgresql-8.3 (come root):

# /etc/init.d/postgresql stop 8.3

3- Installiamo Postgresql-8.4 e Postgis-1.5

# aptitude install postgresql-8.4 postgresql-8.4-postgis

A questo punto (non ricordo purtroppo tutte le fasi che ho percorso) al comando di stop de nuovo postgresql-8-4 compariva un errore. Ho provato a reinstallarlo ma a questo punto ottengo:

# Error: move_conffile: required configuration file /var/lib/postgresql/8.4/main/postgresql.conf does not exists.

Decido allora di reinstallare tutto ma succede il fattaccio. Non si riesce piu’ a lanciare postgresql-8-3. Il messaggio d’errore diceva che non esiste piu’ la directory “/var/lib/postgresql/8.3/main” panic…..praticamente mi e’ sparito tutto il cluster di postgresql-8.3, fumato!

Ok, pero’ i backup li ho e decido di fare un purge profondo prima di ripartire. Cerco tutti i pacchetti relativi a Postgresql.

# dpkg -l | grep postg

e rimuovo tutto con:

# aptitude purge postgresql-8.3 postgresq-8.4 postgresql-client-8.3 postgresql-client-8.4 postgresql-client-common postgresql-common postgresql

Rimuovo anche tutte le directory di sistema:

# rm -r /etc/postgresql/

# rm -r /etc/postgresql-common/

# rm -r /var/lib/postgresql/

poi togliamo manualmente l’utente “postgres” dal file “/etc/passwd” (mediante “# nano /etc/passwd” e modificando il file eliminado la riga di interesse).

Quindi reinstallo tutto con:

# aptitude install postgresql-8.4 postgresql-8.4-postgis (che si tira dietro anche tutte le dipendenze del caso)

A questo punto possiamo recuperare i dump fatti. Per fare questo ci viene in aiuto uno script in perl che si installa con postgis-1.5 (new_postgis_restore.pl).

Prima si devono ricreare i database vuoti (con lo stesso nome di quello di partenza). Essendo tutti db spaziali creiamo dapprima un template spaziale che chiamiamo “template_gis” e lo useremo poi per creare ogni db.

Come utente postgres creiamo anche gli utenti dei db stessi:

$ su

# su postgres

(come utente postgres) # psql template1; (si entra in un db qualsiasi per creare gli utenti)

=# CREATE USER nome_utente WITH PASSWORD ‘secret’ CREATEDB CREATEUSER;

Creo il nuovo database che diventaera’ il template (sempre come utente postgres):

=# CREATE DATABASE template_gis template=template0;

Usciamo dal db (<CTRL>d) e (sempre come utente postgres) importiamo in esso le funzioni spaziali:

# psql -f /usr/share/postgresql/8.4/contrib/postgis-1.5/postgis.sql -d template_gis

poi

# psql -d template_gis -f /usr/share/postgresql/8.4/contrib/postgis-1.5/spatial_ref_sys.sql

A questo punto rientriamo in template1:

# psql template1;

e facciamo in modo che il nuovo db sia un template usabile in futuro:

# UPDATE pg_database SET datistemplate=’t’ WHERE datname=’template_gis’;

ok, ora possiamo creare tutti i nostri db in base a questo template.

# CREATE DATABASE nome_db template=template_gis OWNER nome_utente; (questo va fattoper ogni db)

Quindi popoliamo i db con lo script perl citato prima (come utente normale):

$ /usr/share/postgresql/8.4/utils/new_postgis_restore.pl  /percorso/alla/dir/di/dump/nome_db.dmp | psql nome_db

Vedremo scorrere sul terminale una serie di istruzioni (il db si sta popolando). Fatto.

Alla fine (nel mio caso) ricordarsi di modificare i file “/etc/postgresql/8.4/main/postgresql.conf” e “/etc/postgresql/8.4/main/pg_hba.conf”.

Per il primo decommentare la riga relativa a “listen_addresses” e inserire l’asterisco al posto di “localhost” come riportato:

#——————————————————————————
# CONNECTIONS AND AUTHENTICATION
#——————————————————————————

# – Connection Settings –

listen_addresses = ‘*’                  # what IP address(es) to listen on;

………………

Per il secondo (nella parte finale del file):

# Database administrative login by UNIX sockets
local   all         postgres                          ident

# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD

# “local” is for Unix domain socket connections only
local   all         all                               trust
# IPv4 local connections:
host    all         all         127.0.0.1/32          trust
host    all         all         0.0.0.0/0             trust
# IPv6 local connections:
host    all         all         ::1/128               trust

altrimenti non sono consentiti connessioni da altri client (nel primo file) e l’esecuzione di pg_dumpall (nel secondo file)


postgresql | qualche tips, qualche tricks

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

Postgresql | Postgis | modificare i valori dei campi di una vista

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.

array_to_string in Postgresql ovvero il problema della “battaglia navale”

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

 

openlite | migrazione tra database in pochi click

Il papà di SpatiaLite, Alessandro Furieri, ha lanciato un altro ottimo tool: OpenLite. Si tratta di uno strumento leggerissimo e semplice per migrare database (interi o in parte) tra SpatiaLite, PostGIS e MySQL.

E’ disponibile in forma sorgente oppure binaria per Windows ed è accompagnato da una semplice ma esaustiva guida che si trova alla stessa pagina del progetto.

Ho provato ad installarlo dai sorgenti su Ubuntu 10.10. Ecco una sisntesi dei passaggi e delle prove fatte:

– scaricare i sorgenti da qui;

– scompattare tutto in una directory di lavoro; nel mio caso in “/home/sit/src/openlite-0.0.1

– ci sono dipendenze da soddisfare: libspatialite e wxWidgets. Le installiamo via sudo apt-get install nome_pacchetti o via synaptic

– da riga di comando si accede alla directory interessata:

cd /home/sit/src/openlite-0.0.1

– lanciare in sequenza i tre canonici comandi:

  ./configure

  make

  sudo make install-strip

– a questo punto il programma è installato. Lo lanciamo da riga di comando con:

sit@dell1530:~$ openlite

– si presenta così:

OpenLite - come si presenta

la semplicità dello strumento si nota subito


– è necessario stabilire prima di tutto una connessione ad un db SQLite. Se ne esiste già uno colleghiamoci cliccando sul pulsante in alto a sx “Connecting an existing SQLite DB” e cerchiamo il DB interessato. In alternativa possiamo creare un DB nuovo cliccando sul secondo pulsante da sx “Creating a New (empty) SQLite DB”.

– in seconda battuta connettiamoci ad un atro DB. Nel mio caso ho provato con un DB PostGIS (PostgreSQL). Cliccare sull’icona con freccia azzurra e contenitore magenta “Connecting to PostgreSQL/PostGIS DBMS”. La prima volta che si tenta di connettersi ad un DB PostgreSQL viene chiedo di individuare la libreria necessaria. Nel nostro caso si tratta di “/usr/lib/libpq.so.5.2“. Questa impostazione viene salvata permanentemente ed ogni connessione successiva a DB PostgreSQ/PostGIS cercherà questa libreria. Nel caso si indicasse la libreria sbagliata viene restituito il messaggio “No PostgreSQL Client Library available … sorry
Connection impossible”. Per “sbloccare” la situazione ed impostare il percorso corretto alla libreria ci sono due alternative:

– alternativa 1 – brutale ma efficade:

– andare nella home directory
– lanciare il comando: ls -la
– dovremmo trovare un file nascosto chiamatto “.OpenLite” (è il file in cui vengono salvate le impostazioni permanenti)
– cancellare il file e ripartire.

– alternativa 2 – piu’ soft (ma non testata):

– andare nella home directory e aprire il file nascosto .OpenLite con: $ nano .OpenLite

– modificare la riga “PostgisLibraryName=libpq.so.5.2” indicando la libreria corretta.

– rilanciare openlite e ripartire.

Una volta individuata la libreria compare un popup per l’inserimento del percorso al DB e delle credenziali di accesso.

connessione a PostgreSQL

Connessione a DB PostgreSQL/PostGIS

Nella parte dx del pannello vengono elencate tutte le tabelle presenti del DB PostgreSQL. Selezionare con click sx la tabella che si vuole trasferire al DB SQLite e poi click dx. Compare un menù contenstuale: scegliere la voce “Select for data transfer”. Poi click dx sullo schema che contiene la tabella in questione (nel nostro caso “public“) altrimenti non è possibile avviare il tarsferimento. Fatto questo verrà abilitato un nuovo pulsante “Start data transfer” che si trova a sx del pulsante “About…”.

– Click sul pulsante indicato.

– Fatto: in questo modo avviene il trasferimento della tabella in questione al DB SQLite che comparirà dopo qualche secondo (a seconda delle dimensioni) nella parte sx del pannello.

La tabella "areacirc" è stata trasferita con successo

django | somma di campi

Supponiamo di avere una tabella contente i valori dei consumi energetici di un particolare dispositivo.

In particolare abbiamo inserito un campo (somma) che sarà popolato con il risultato ottenuto dalla somma di altri 4 campi. In questo modo ad ogni inserimento (Admin) di dati relativi ai primi 4 campi (rientranti nella somma) e dopo avere cliccato il punsante “Salva” o “Salva e continua le modifiche” il campo “somma” apparirà popolato con il valore somma.

Ecco un esempio di strutturazione della class nel file models.py.

class ConsumiIlluminazione(models.Model):
 """Tabella consumi illuminazione"""

 utente = models.ForeignKey(UtenteIlluminazione)
 campo1 = models.IntegerField(null=True, blank=True)
 campo2 = models.IntegerField(null=True, blank=True)
 campo3 = models.IntegerField(null=True, blank=True)
 campo4 = models.IntegerField(null=True, blank=True)
 somma = models.IntegerField(null=True, blank=True)
 def calcoloTotale(self):
  self.somma = self.campo1 + self.campo2 + self.campo3 + self.campo4
 def save(self):
  self.calcoloTotale()
  super(ConsumiIlluminazione, self).save()
 def __unicode__(self):
  return "%s" % (self.utente)
 class Meta:
  ordering = ["utente"]
  verbose_name_plural = "Consumi illuminazione"

geodjango | primo approccio

GeoDjango è un add-on per Django che consente di gestire e manipolare dati geografici all’interno di un progetto django.

Questo post riassume i passi iniziali per implementare una class geografica in una applicazione….spero di espandere il post non appena avro’ fatto qualche test ed esperienza ulteriore. Andiamo per step:

1. Creazione del db geografico (nel mio caso si tratta di un db Postgis).

Se ancora non esiste creiamo un template per i db gis (sarà molto comodo anche in futuro):

– autenticarsi come utente postgres ed entrae in un template (esempio il “template1”):

postgres@debian:/home/sit$ psql template1;

–  creare un nuovo db che chiameremo template_gis sul modello del template0;

postgres=# CREATE DATABASE template_gis template=template0;

– uscire da psql e creare il linguaggio per il db appena creato:

postgres@debian:/home/sit$ createlang plpgsql template_gis

– poi:

postgres@debian:/home/sit$ psql -f /usr/share/postgresql/8.4/contrib/postgis-1.5/postgis.sql -d template_gis

– popoliamo la tabella spatial_ref_sys:

postgres@debian:/home/sit$ psql -d template_gis -f /usr/share/postgresql/8.4/contrib/postgis-1.5/spatial_ref_sys.sql

– entrare nuovamente in un template e indicare che template_gis è un template:

postgres=# UPDATE pg_database set datistemplate=’t’ WHERE datname=’template_gis’;

– a questo punto possiamo creare il nostro db per django usando il template_gis appena creato:

postgres=# CREATE DATABASE energia_django template=template_gis OWNER sit;

– ci spostiamo all’interno del database appena creato:

postgres=# \connect energia_django

– poi è necessario dare i GRANT di SELECT sulla spatial_erf_sys e ALL sulla geometry_columns:

postgres=# GRANT SELECT on spatial_ref_sys to sit;

postgres=# grant ALL on geometry_columns to sit;

2. Configurazione del progetto django (geodjango)

Andiamo all’interno del nostro progetto django (il progetto sia chiama “energia” e una prima applicazione si chiama “manager”)

– Configurare il file settings.py modificando le impostazioni del database come segue:

DATABASES = {
    'default': {
         'ENGINE': 'django.contrib.gis.db.backends.postgis',
         'NAME': 'energia_django',
         'USER': 'sit',
     }
}

Aggiungere:

django.contrib.gis tra le INSTALLED_APPS

3. Preparazione dei dati geografici

Partiamo da dati in formato SHP (nel nostro caso si tratta di uno SHP di punti chiamato “quadri.shp”.

– creare una directory chiamata “data” all’interno della nostra applicazione:

$ mkdir manager/data

e salviamo al suo interno gli SHP relativi:

– con ogrinfo ispezioniamo lo SHP:

$ ogrinfo -so quadro.shp quadro

ottenendo una lista di dati relativi allo SHP (tra cui il numero di feature, SRS, nomi dei campi). Questo è molto importante per creare la class (nel file models.py) che andrà ad “accogliere” i dati. Definiamo quindi la class nel nostro models.py dell’applicazione.

class QuadroIlluminazione(models.Model):
 kp = models.IntegerField()
 numnuovo = models.CharField(max_length=5)
 via = models.CharField(max_length=30)
 codanagr = models.IntegerField()
 norma = models.CharField(max_length=2)
 regolato = models.CharField(max_length=2)
 contenel = models.CharField(max_length=15)
 contpote = models.CharField(max_length=20)
 elettronic = models.CharField(max_length=2)
 ncliente = models.CharField(max_length=10)
 gmrotation = models.FloatField()
 geom = models.MultiPointField(srid=3003)
 objects = models.GeoManager()
 class Meta:
 verbose_name_plural = "Quadri illuminazione pubblica"

 # Returns the string representation of the model.
 def __unicode__(self):
 return self.numnuovo

NB: attenzione all’indentazione; in questo post puo’ non essere corretta; vedere la guida di python per una corretta scrittura del codice)

Abbiamo definito la nuova tabella che conterrà i dati geografici con gli stessi attributi trovati nello SHP. Gli unici due campi che vengono aggiunti sono “geom” e “objects“.

– Controlliamo che tutto sia a posto prima di generare il DB con:

$ python manage.py sqlall manager

l’output è simile a questo (la parte finale):

……………..

CREATE INDEX “manager_contrattoaperturagasnaturale_utente_id” ON “manager_contrattoaperturagasnaturale” (“utente_id”);
CREATE INDEX “manager_contrattofornituragasnaturale_utente_id” ON “manager_contrattofornituragasnaturale” (“utente_id”);
SELECT AddGeometryColumn(‘manager_quadroilluminazione’, ‘geom’, 3003, ‘MULTIPOINT’, 2);
ALTER TABLE “manager_quadroilluminazione” ALTER “geom” SET NOT NULL;
CREATE INDEX “manager_quadroilluminazione_geom_id” ON “manager_quadroilluminazione” USING GIST ( “geom” GIST_GEOMETRY_OPS );COMMIT;

– a questo punto sincronizziamo il DB con:

$ python manage.py syncdb

compariranno una serie di messaggi (con la richiesta di creazione del superutente). alla fine avremo il nostro db pronto.

4. Ridefinizione del models.py

Il models.py deve essere modificato inserendo classe e dizionario. Una funzione ci viene in aiuto per automatizzare il processo:

$ python manage.py ogrinspect manager/data/quadro.shp QuadroIlluminazione –srid=3003 –mapping –multi

Questo comando produce in output la definizione della class e del dizionario necessario per il nostro layer geografico. Tale output puo’ essere copiato/incollato nel nostro models.py

5. Caricamento dei dati del database

Per il caricamento dei dati è necessario creare un modulino python per l’import. Per farlo creare un file chiamato “load.py” e salvarlo all’interno della nostra applicazione. Copiare al suo interno il seguente codice:

import os
from django.contrib.gis.utils import LayerMapping
from models import QuadroIlluminazione

quadroilluminazione_mapping = {
 'kp' : 'KP',
 'numnuovo' : 'NumNuovo',
 'via' : 'Via',
 'codanagr' : 'CodAnagr',
 'norma' : 'Norma',
 'regolato' : 'Regolato',
 'contenel' : 'ContEnel',
 'contpote' : 'ContPote',
 'elettronic' : 'Elettronic',
 'ncliente' : 'Ncliente',
 'gmrotation' : 'GMRotation',
 'geom' : 'MULTIPOINT',

}

quadroilluminazione_shp = os.path.abspath(os.path.join(os.path.dirname(__file__), 'data/quadro.shp'))

def run(verbose=True):
 lm = LayerMapping(QuadroIlluminazione, quadroilluminazione_shp, quadroilluminazione_mapping, transform=True, encoding='iso-8859-1')
 lm.save(strict=True, verbose=verbose)

– Ora invochiamo la shell python per importare i dati mediante il modulo appena creato

$ python manage.py shell

Al prompt di python impartiamo i seguenti comandi (prima richiamiamo il modulo e poi la funzione di “load”):

>>> from manager import load
>>> load.run()

Seguirà una serie di messaggi di import (uno per ogni feature).

6. Caricamento del layer geografico

All’interno del file “admin.py” inserire le seguenti stringhe di codice:

from django.contrib.gis import admin
from manager.models import *
........
admin.site.register(QuadroIlluminazione, admin.GeoModelAdmin)

…to be continued as soon as possible

da PostGIS a Spatialite

Avevo necessità di esportare un DB PostGIS (PostgreSQL con estensione spaziale) in spatialite.

Cercando in rete ho trovato questa pagina: le librerie GDAL/OGR sono in grado di fare la conversione richiesta. In particolare il terzo esempio riportato alla pagina indicata fa proprio al caso nostro.

$ ogr2ogr –config PG_LIST_ALL_TABLES YES –config PG_SKIP_VIEWS NO -f “SQLite” nome_db.sqlite -progress PG:”dbname=’nome_db_postgis’ active_schema=public schemas=public host=’nome_host’ port=’5432′ user=’nome_utente’ password=’pwd_segreta’ ” -lco LAUNDER=yes -dsco SPATIALITE=yes -lco SPATIAL_INDEX=no

Ma provando a caricare il DB in QGIS si ottiene un errore:

“nome del layer” (GEOMETRY non è un layer valido e non può essere caricato)

Ho chiesto il lista gfoss.it e il papà di spatialite, Alessandro Furieri, mi ha gentilmente controllato l’output di ogr2ogr. La sua illuminante risposta e conclusione è riportata qui. Ma provo a riassumere i passaggi che, con le sue indicazioni, ho seguito per ripulire le sporcizie che erano rimaste.

Il database che viene creato presenta alcune incongruenze (alcune dovute ad errori preesistenti del DB Postgis come il settaggio dello SRID che non deve essere uguale a -1 ma deve essere esplicitamente dichiarato). Poi errori di interpretazione delle colonne geometriche nel passaggio da postgis a spatialite.

In sostanza, una volta creato il DB spatialite ho seguito questi passaggi (indicati da Sandro):

$ spatialite nome_db.sqlite

– si presenta il prompt di spatialite: a questo punto impostare alcune semplici configurazioni per l’output dei comandi:

spatialite> .nullvalue NULL

spatialite> .headers on

spatialite> .mode column

In questo modo otteniamo che vengano visualizzati come NULL in valori senza valore (bel gioco di parole :-)), che si vedano gli headers delle tabelle quando si lanciano query di select e che i valori vengano visualizzati secondo una impostazione tabellare.

A questo punto bisogna forzare lo SRID (nel nostro caso si tratta del codice EPSG=3003, Gauss Boaga Fuso Ovest) nella tabella geometry_columns:

spatialite> update geometry_columns SET srid = 3003;

Poi sistemiamo il type geometrico aggiornando alcuni valori sghembi che erano rimasti; in particolare si tratta di alcune tabelle con dati poligonali in cui il tipo geometrico era rimasto con valore GEOMETRY.

spatialite> update geometry_columns SET type=’POLYGON’ WHERE type = ‘GEOMETRY’;

– Infine aggiorniamo correttamente lo SRID su tutte le geometrie creando i trigger necessari al buon funzionamento di spatialite.

spatialite> UPDATE acqua SET GEOMETRY = SetSrid(GEOMETRY, 3003);

Questo va fatto tabella per tabella (nel caso riportato la tabella “acqua”).

A questo punto il caricamento con QGIS va liscio!

PostreSQL | trigger

Un trigger definisce una funzione che agisce prima o dopo un’altra azione su una tabella.

In sostanza un trigger richiama una determinata funzione (che deve essere creata a priori) che esegue operazioni sui valori di una tabella.

Nel caso particolare di questo esempio disponiamo di una tabella chiamata “valori” che contiene 5 colonne:

valore1, valore2, valore3, valore4 e somma (tutti di tipo integer).

I valori delle prime 4 colonne vengono inserite dall’utente; vogliamo fare in modo che la quinta colonna (somma) venga popolata dalla funzione richiamata dal trigger una volta che i primi 4 valori sono inseriti. Procediamo:

– definiamo la funzione:

nome_db=> CREATE OR REPLACE FUNCTION somma_valori() RETURNS trigger AS $somma_valori$ DECLARE new_somma integer;
BEGIN IF (TG_OP=’INSERT’) THEN UPDATE valori SET somma=valore1+valore2+valore3+valore4; END IF; RETURN NEW; END; $somma_valori$ language plpgsql;

– definiamo ora il trigger che richiama la funzione ad ogni INSERT che avviene nella tabella;

nome_db=> CREATE TRIGGER tr_somma_valori AFTER INSERT ON valori FOR EACH ROW EXECUTE PROCEDURE somma_valori();

In questo modo ogni volta che vengono inseriti i primi 4 valori vedremo popolarsi automagicamente anche il quinto.

Postgresql | replace

Ho importato un file CSV in Postgresql in cui i testi erano racchiusi tra doppio apice (“).

Il risultato si traduce in campi (quelli testuali) tutti belli incapsulati in doppie apici che, a dirla tutta, non sono il massimo…soprattuto se si devono fare SELECT o UPDATE via psql (client a riga di comando comodissimo e potente). Ho tentato allora di approfondire cercando una soluzione (in Postgresql) che permettesse di fare un bel FIND AND REPLACE (come siamo soliti fare con openoffice/libreoffice e/o qualsiasi altro editor di testo).

Alla fine ho scovato la funzione REPLACE di Postgresql che ha la seguente sintassi:

replace(string text, from text,to text)

che riportata in concreto diventa:

nome_db =# UPDATE nome_tabella SET nome_campo=replace(nome_campo, ‘valore_vecchio’,’valore_nuovo’);

Vediamo nel caso pratico del mio db. Si tratta di una tabella contente dati relativi a ditte. Facendo una SELECT sul campo “denominazione” prima della modifica con REPLACE si otteneva:

nome_db =# SELECT denominazione FROM ditte WHERE numero=2;

denominazione
—————–
“NOME DITTA A CASO s.n.c.”
(1 riga)

Aggiorniamo il campo denominazione togliendo i doppi apici:

nome_db =# UPDATE ditte SET denominazione=replace(denominazione,'”‘,”);

e alla fine la query di SELECT precedente torna il valore “pulito”:

nome_db =# SELECT denominazione FROM ditte WHERE numero=2;

denominazione
—————–
NOME DITTA A CASO s.n.c.
(1 riga)

Altro esempio: supponiamo di avere un campo che memorizza il percorso di salvataggio di una immagine. Il campo si chiama “foto” e dobiamo aggiornare l’indirizzo IP del server sul quale risiedono le immagini: si passa da server con IP “100.0.4.231” a IP”192.168.4.50″.
Se interroghiamo il DB prima dell’aggiornamento otteniamo:

nome_db =# SELECT foto FROM ditte WHERE numero=2;

foto
—————–
http://100.0.4.231/percorso_al_file_immagine/002.jpg
(1 riga)

Modifichiamo allora solo la parte di campo relativa all’indirizzo IP:

nome_db =# UPDATE ditte SET foto=replace(foto,’100.0.4.231,’192.168.4.50′) WHERE numero=;

UPDATE 1

ed il risultato della SELECT sarà:

nome_db =# SELECT foto FROM ditte WHERE numero=2;

foto
—————–
http://192.168.4.50/percorso_al_file_immagine/002.jpg
(1 riga)