db-ing & geodb-ing

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)

django | modificare le tabelle

Una volta creato il progetto e l’applicazione con django succede di dover apportare delle modifiche alla struttura del database (per esempio aggiunta di campi alle tabelle,..).

Per farlo sono necessari 4 passi:

– eseguire un backup del db con:

$ python manage.py dumpdata manager > db.json

dove manager è il nome dell’applicazione (db) e db.json è un backup di tutto il db (JSON sta per JavaScript Object Annotation: si tratta di un formato di interscambio per dati)

– si apportano le modifiche alla tabella (model); ad esempio inserendo un nuovo campo agendo sul file models.py

– si resetta il database: in questo modo vengono ricreate le tabelle con il nuovo modello (rispondere “yes” alla domanda di conferma di reset):

$ python manage.py reset manager

– ri ricaricano i dati prelevandoli dal backup fatto in precedenza:

$ python manage.py loaddata db.json

Fatto!

django! si, django!

In questo post tento di riassumere (nella maniera piu’ semplice possibile) i passi che ho seguito per creare il primo progetto con django. Da non sviluppatore e abbastanza ignorante nel campo dei linguaggi di programmazione se dovessi definire django con un aggettivo direi: disarmante!

Si ispira al principio DRY (Don’t Repeat Yourself) e la migliore definizione di django che ho trovato è quella fornita da Marco Beri nel suo ottimo libro “Sviluppare applicazioni web con django”: “Django è un ottimo tavolo da lavoro, con tanto di strumenti, per costruire siti dinamici e applicazioni web“. E io aggiungo: le “gambe” del tavolo sono costituite da Python!

Utilizzando Debian troviamo django già pacchettizzato. Purtroppo la versione disponibile non è la piu’ recente; ma basta scaricare i sorgenti dal sito http://www.djangoproject.com/download/ e seguire i 3 (anzi 4) semplici passi indicati:

– si scarica;

– si decomprime il tar.gz;

– ci si sposta nella directory ottenuta dalla decompressione;

– si “suda” per installare il pacchetto: fatto!

E qui comincia il bello. Andiamo per fasi (step):

– si crea una directory di lavoro (la possiamo creare nella nostra home; poi vedremo come fare per renderla visibile al server web).

$ mkdir django_work

– ci spostiamo nella directory creata:

$ cd django_work

– richiamiamo il modulo per la creazione del “progetto” (con django si crea prima un “progetto” e poi “n” applicazioni. C’è molta documentazione in rete che riguarda la strutturazione del framewok):

$ django-admin startproject energia

Questo comando genera nella directory corrente una sottodirectory che ha il nome del progetto indicato (nel nostro caso “energia”) che contiene alcuni file: __init__.py, manage.py, settings.py, e urls.py

NB: con l’installazione di django è stato installato anche un server web (diciamo “provvisorio”) utilissimo per fare i test durante la creazione e implementazione del progetto. Questo server si avvia mediante il comando:

$ python manage.py runserver

Se tutto è ok compare un messaggio simile a questo:

Validating models…

0 errors found….. ecc

Quit the server with CTRL-C.

– Modificare il file settings.py e indicare i parametri alla voce “DATABASES“:

‘ENGINE’:  ‘postgresql_psycopg2″ (se si usa database Posgresql)

‘NAME’:  ‘energia’ (il db si puo’ creare dopo; l’importante è dare questo nome :-))

‘USER’:  ‘sit’ (il proprietario del db creato)

‘HOST’: ‘localhost’

‘PORT’: ” (lasciare in bianco per assumere la porta configurata di default)

– Creare il nuovo database (con lo stesso nome indicato del file “settings.py“). PS: in questo post si assume di lavorare con DB Postgresql; per altre configurazioni (sqlite, mysql,…) vedere la ricca documentazione che si puo’ trovare in rete.

$ su

# su postgres

# psql

# CREATE DATABASE energia OWNER sit;

– lanciare il webserver (quello ausiliario fornito da django con il solo scopo di testare lo sviluppo dell’applicazione) posizionandosi all’interno della directory di lavoro.

$ ./manage.py runserver oppure

$ python manage.py runserver

Deve comparire un messaggio di “0 errors“.

– Puntare il browser alla pagina http://localhost:8000/

dovremmo ottenere una pagina con scritto “IT WORKED…..”

– Creare l’applicazione che chiameremo “manager“:

$ ./manager.py startapp manager

In questo modo viene creata la directory “manager”.

– Definire le tabelle del DB mediante il file “models.py“: le tabelle sono definite come classi python (vedi il tutorial on line)

– L’applicazione nuova chiamata “manager” deve essere attivata modificando il file “…../django_work/energia/settings.py” ed inserendo la voce ‘energia.manager’ nella sezione “INSTALLED_APPS“

– Per applicare il modello appena definito cioé costruire la struttura del database lanciare il comando:

$ ./manage.py syncdb

Compare una sequenza di messaggi che indicano l’avvenuta creazione di alcune tabelle (comprese quelle di autenticazione) in quanto previste tra le “INSTALLED_APPS” del file “settings.py” (‘django.contrib.auth‘). Installando l’auth system viene chiesto se si vuole creare un superuser. Rispondere “yes“: viene proposto l’utente attivo. Dare” yes” e immettere un indirizzo e-mail e una password (l’email non è indispensabile).

– A questo punto si puo’ procedere al popolamento della/e tabella/e del db. Il tutorial propone di usare la shell di django ma si puo’ fare benissimo con vari client (io ho usato phppgadmin per Postgresql).

– Creazione delle “view“: si tratta delle viste ossia come devono essere presentati i dati. Prima di farlo definiamo gli URl delle varie pagine editando il file “…/django_work/energia/urls.py“.

Questi pattern associano le espressioni regolari ad un modulo python.

Le view vengono definite nel file “…/django_work/energia/manager/views.py” (sono tipiche dell'”applicazione”). Nelle view definite si fa riferimento a determinati template (file HTML).

– Definire la variabile ‘TEMPLATES_DIRS‘ all’interno del file “settings.py“

Esempio: ABSOLUTE_PATH + ‘/home/sit/django_work/energia/manager/templates’

– Creare una directory “templates” all’interno di “manager” e procedere alla creazione dei template (base.html, index.html,…). Per una descrizione più dettagliata sui template si rimanda al tutorial on-line.

Supposto che tutto sia ok si puo’ passare alla pubblicazione vera e propria del nostro lavoro. Ricordiamoci che fino ad ora abbiamo lavorato “in casa” usando il server web ausiliario gentilmente offerto da django. Ma se dobbiamo “uscire” nel mondo dobbiamo usare un “vero” server web. Qui facciamo riferimento ad Apache.

– Nel file “settings.py” nella sezione “DATABASES” verificare che la voce ‘HOST‘ sia impostata a ‘localhost’.

– Modificare il file di configurazione di Apache che si trova in (debian :-)) “/etc/apache2/apache2.conf” aggiungendo:

<Location “/energia/”>

SetHandler python-program

PythonHandler django.core.handlers.modpython

SetEnv DJANGO_SETTINGS_MODULE energia.settings

PythonPath “[‘/home/sit/django_wotk/’,’/home/sit/django_work/energia/’] + sys.path”

PythonOption django.root /energia

PythonDebug On

</Location>

<Location “/media”>

SetHandler None

</Location>

Alias /media /home/sit/src/Django-1.2.1/django/contrib/main/admin/media

Quest’ultimo alias è necessario per caricare i file CSS, JS (modificare i template HTML inserendo “/energia/” a monte di ogni HREF).

NB: ricordarsi di riavviare il server web dopo ogni modifica:

# /etc/init.d/apache2 restart

Spero sia tutto corretto. Commenti benvenuti.

script per backup periodici di database postgresql/postgis

Una delle cose belle di Linux e’ che ti spinge a curiosare nel suo “mondo”; si scoprono cose davvero fantastiche per quanto semplici.

Per esempio: avevo necessita’ di eseguire un backup di alcuni database potgresql/postgis in maniera continua (su HD removibile HP RDX 320 GB)

Ho creato uno script per fare tutto cio’; in un secondo momento ho modificato il CRONTAB della macchina per fare in modo che questo script venga eseguito ad una certa ora del giorno.

Partiamo dall’inizio:

– con l’editor “nano” creiamo il file “backup.sh” nella directory “/usr/bin/”

– cd /usr/bin

– nano backup.sh

e lo compiliamo nel modo seguente:

#!/bin/bash

export PGPASSWORD=”mia_password_del_db” && pg_dump -h localhost -U user -c -d -R -v nome_database -n nome_schema > /percorso/dove/salvare/il/file.sql

L’istruzione “export PGPASSWORD=”mia_password_del_db” permette di dichiarare la password stessa senza doverla inserire ogni volta che lo script viene lanciato (questo renderebbe inutile un backup notturno in quanto il prompt si aspetterebbe l’immissione della pwd a mano).

Chiudiamo nano e salviamo il file. Rendiamolo eseguibile (da root):
# chmod +x /usr/bin/backup.sh

Modifichiamo il crontab per eseguirlo ad una certa ora del giorno:

@ crontab -e

e inseriamo le seguent righe:

00 04 * * * /usr/bin/backup.sh

In questo modo il backup viene lanciato ogni giorno alle 4 di mattina.

pgrouting | calcolo percorso minimo tra due punti

Prima di tutto e’ necessario creare un database Postgresql ed aggiungerci l’estensione spaziale Postgis.

come utente postgres si entra in un database esistente o in un template:

# psql template1;

– Creiamo il database e impostiamo la proprietà all’utente (nel nostro caso “sit”):

template1=# CREATE DATABASE routing OWNER sit template template_gis;

il template_gis e’ stato creato a priori (database con estensioni spaziali postgis incorporate; questo per evitare ogni volta di dover aggiungere le tabelle “geometry_column” e “spatial_ref_sys”);

– Ci colleghiamo al database appena creato:

template1=# /connect routing;

e diamo i permessi necessari all’utente “sit” sulla tabella spaziali:

routing=# GRANT ALL ON geometry_columns to sit;
routing=# GRANT SELECT ON spatial_ref_sys to sit;

– Aggiungiamo le funzioni di routing (dopo essere usciti dal database ed esserci autenticati come utente “postgres”):

# psql -d routing -f /usr/share/postlbs/routing_core.sql

# psql -d routing -f /usr/share/postlbs/routing_wrappers.sql

# psql -d routing -f /usr/share/postlbs/routing_topology.sql

– Reperiamo i dati: nel mio caso ho reperito il planet italiano dal sito http://download.geofabrik.de/osm/europe/. Ho scaricato gli SHP. Dopo aver fatto un clip dei dati sul confine regionale di interesse (Veneto) medianti i preziosissimi ftools di qgis ho ottenuto il grafo stradale del territorio veneto.

– Importiamo i dati del database mediante il modulo shp2pgsql. Ecco la sintassi del comando (con SRID settato a 4326, i dati sono in lat-long WGS84).

$ shp2pgsql -S -s 4326 /home/sit/geodatabase/shp/stradario_regione/stradario_regione_seg.shp stradario_regione routing > /home/sit/sql/stradario_regione.sql

$ psql -h localhost -U postgres -d routing -f /home/sit/sql/stradario_regione.sql

Per i passi successivi ho seguito questo ottimo tutorial ):

– Aggiungiamo 3 colonne alla tabella: una per memorizzare gli ID dei nodi iniziali, una per gli ID dei nodi finali e la’ltra per la lunghezza:

routing=> ALTER TABLE stradario_regione ADD COLUMN source integer;

routing=> ALTER TABLE stradario_regione ADD COLUMN target integer;

routing=> ALTER TABLE stradario_regione ADD COLUMN length double precision;

– Creiamo la topologia e aggiungiamo il valore della lunghezza al campo appena creato:

routing=> SELECT assign_vertex_id(‘stradario_regione’, 0.0001, ‘the_geom’, ‘gid’);

routing=> UPDATE stradario_regione SET length = length(the_geom);

– Creiamo gli indici per le colonne “source”, “target” e “the_geom”;

routing=> CREATE INDEX source_idx ON stradario_regione(source);

routing=> CREATE INDEX target_idx ON stradario_regione(target);

routing=> CREATE INDEX geom_idx ON stradario_regione USING GIST(the_geom GIST_GEOMETRY_OPS);

– Impostiamo la query di routing e salviamo il tutto in una nuova tabella chiamata “dijkstra_resust” (prima di tutto cancelliamo una eventuale tabella omonima precedentemente creata):

routing=> DROP TABLE IF EXISTS dijsktra_result;

routing=> CREATE TABLE dijsktra_result(gid int4) with oids;

routing=> SELECT AddGeometryColumn(‘dijsktra_result’, ‘the_geom’, ‘4326’, ‘MULTILINESTRING’, 2);

routing=> INSERT INTO dijsktra_result(the_geom) SELECT the_geom FROM dijkstra_sp(‘stradario_regione’, 73441, 13547);

Questa query trova il percorso minimo tra due vertici (con ID pari a 73441 e 133547).

In prima battuta, nel mio caso, ho ottenuto un messaggio d’errore per violazione di un CONSTRAINT:

ERROR: new row for relation “dijkstra_result” violates check constraint “enforce_geotype_the_geom”

Ho cancellato questo constraint (via pgadmin3) e re-impartito la query ottenendo la nuova tabella dijkstra popolata. Il risultato si può visualzzare in qgis.

pgrouting | compilazione in debian Lenny

Ho provato ad installare l’estensione di postgresql-postgis per il routing chiamata pgRouting. Si tratta di una estensione che consente di effettuare analisi di reti.

Ho tentato la compilazione (in Debian Lenny)  in quanto non esiste come pacchetto precompilato per debian. Questo perche’ la compilazione “canonica” dei sorgenti mi ritornava un errore in sede di “make”. Ho notato (alla fine di tutta la storia) che la creazione dei .deb e la loro installazione può risultare propedeutica alla compilazione canonica (se il lettore ha notizie certe che possono confermare o demolire questa ipotesi posti un commento al post; sarei molto felice di approfondire la questione). La creazione dei .deb che vediamo tra poco consente di installare solo la parte “core” delle librerie. Questo a causa della della mancanza delle librerie GAUL nei repos ufficiali (necessarie per il problema del TSP – Travel Sale Person) e delle CGAL (necessarie per le driving distance) rilasciate sotto licenza QPL, quindi non libere.

Per avere TSP e driving distance e’ pertanto necessario installare dai sorgenti, la cui compilazione va a buon fine (o almeno per me e’ stato cosi’) solo dopo l’installazione del “core” pacchettizzato debian.

Creazione dei pacchetti .deb delle core library (senza funzioni TSP e DD)

Prima di tutto ho scaricato i sorgenti da qui.

Seguendo le istruzioni riportati nel sito ho seguito i seguenti passi:

– diamo un controllo ai requirements: cmake ed i compilatori C e C++ li dovremmo trovare già installati nella nostra distro; mancano invece le librerie Boost Graph Library (BGL), le Genetic Algorithm Utility Library (GAUL, per il problema del “commesso viaggiatore”), e le librerie computazionali Geometry Algorithms Library (CGAL, per il driving);

– per installare le BGL ho usato apt-get (sono già nei repo di Lenny): # apt-get install libboost-graph-dev

– anche le CGAL si trovano: installate via synaptic;

– le GAUL invece le ho scaricate dal sito: una volta fatto, scompattare il sorgente e impartire i comandi riportati nella pagina di istruzioni indicata sopra. I comandi sono:

$ ./configure –disable-slang

$ make

# make install

Seguendo le istruzioni riportate su questa pagina (nascosta, in quanto non c’e’ link del sito che la punti) ho compilato le librerie a partire dall’SVN:

– creare una directory in cui scaricare i sorgenti (nel mio caso $ mkdir compila_pgrouting);

– spostarsi nella directory appena creata e lanciare: $ svn checkout http://pgrouting.postlbs.org/svn/pgrouting/trunk pgrouting

– spostarsi nella directory pgrouting: $ cd pgrouting e diventare root

– creare i paccheti con: # dpkg-buildpackage -b -rfakeroot -uc -us

– risalire di una posizione : # cd ..

– installare i pacchetti con: # dpkg -i *.deb

A questo punto bisogna aggiungere le funzioni di routing al database (che deve essere gia’ un database spaziale). NB: il database ci chiama routing nel nostro caso.

psql -d routing -f /usr/share/postlbs/routing_core.sql
psql -d routing -f /usr/share/postlbs/routing_core_wrappers.sql

L’installazione copia due file con le istruzioni SQL. (routing_core.sql e routing_core_wrappers.sql). Seguendo i tutorial si notera’ che ad un certo punto, dopo avere importato i dati del database, e’ necessario creare la topologia dei dati. Per fare questo viene indicata una funzione “add_vertex_id” secondo questa sintassi:

nome_db=> SELECT assign_vertex_id(‘stradario_regione’, 0.0001, ‘the_geom’, ‘gid’)

dove:

– stradario_regione= nome tabella che contiene i dati;

– 0.0001= tolleranza di snap per la ricerca di nodi non collegati agli archi (espressa in unita’ di misua dei dati; nel mio caso avendo EPSG=4326 sono decimillesimi di grado);

– the_geom=colonna geometrica della tabella interessata;

– gid= colonna con gli id degli oggetti (solitamente la colonna “gid”).

In prima battuta, lanciando la query ho ottenuto questo messaggio:

ERROR:  function assign_vertex_id(unknown, numeric, unknown, unknown) does not exist

Infatti, navigando all’interno del database, nella sezione “Function” dello schema “public” non si trova una funzione chaimata “add_vertex_id”. Scrivendo il lista pgrouting mi e’ stato indicato da Anton Patrushev (che ringrazio infinitamente) che le regole per la pulizia topologica sono state spostate in un file di struzioni SQL chiamato “routing_topology.sql”. Ma purtroppo questo file non viene copiato in “usr/share/postlibs/” come gli altri due files indicati sopra (forse un bug?). Tuttavia questo file si trova nei sorgenti scaricati da SVN. Quindi ho copiato il file in “/usr”share/postlibs/” e lanciato l’istruzione (come utente postgres):

psql -d routing -f /usr/share/postlbs/routing_topology.sql

e magicamente la funzione “add_vertex_id” si trova tra le “Function” del database.

A questo punto ho re-impartito la query (dopo essere entrato nel db come utente “sit”) per la creazione della topologia:

SELECT assign_vertex_id(‘stradario_regione’,0.0001, ‘the_geom’, ‘gid’);

e questo e’ l’output del comando:

NOTICE:  CREATE TABLE will create implicit sequence “vertices_tmp_id_seq” for serial column “vertices_tmp.id”
CONTEXT:  SQL statement “CREATE TABLE vertices_tmp (id serial)”
PL/pgSQL function “assign_vertex_id” line 14 at EXECUTE statement
assign_vertex_id
——————
OK
(1 row)

Aprendo i dati in qgis e interrogando un qualsiasi arco del grafo si nota che i campi “sorce” e “target” sono popolati con gli ID dei nodi iniziale e finale dell’arco stesso.

Compilazione integrale dei sorgenti

La compilazione integrale dei sorgenti (per avere le funzioni di TSP e driving distance) avviene come da manuale: ho seguito anche questa ottima guida.

– spostarsi nella directory ottenuta dalla scompattazione dei sorgenti di pgrouting, quindi:

– $ cmake -DWITH_TSP=ON -DWITH_DD=ON .

– $ make

– # make install

[ 16%] Built target routing_tsp
[ 50%] Built target routing_dd
[100%] Built target routing
Install the project…
— Install configuration: “”
— Installing: /usr/lib/postgresql/8.3/lib/librouting.so
— Installing: /usr/share/postlbs/routing_core.sql
— Installing: /usr/share/postlbs/routing_core_wrappers.sql
— Installing: /usr/share/postlbs/routing_topology.sql
— Installing: /usr/lib/postgresql/8.3/lib/librouting_tsp.so
— Installing: /usr/share/postlbs/routing_tsp.sql
— Installing: /usr/share/postlbs/routing_tsp_wrappers.sql
— Installing: /usr/lib/postgresql/8.3/lib/librouting_dd.so
— Installing: /usr/share/postlbs/routing_dd.sql
— Installing: /usr/share/postlbs/routing_dd_wrappers.sql

– Quindi ho aggiunto le funzioni TSP e DD al database “routing” creato in precedenza:

– (come utente postgres):

# psql -d routing -f /usr/share/postlbs/routing_tsp.sql (crea 1 funzione)

# psql -d routing -f /usr/share/postlbs/routing_tsp_wrappers.sql (crea 5 funzioni)

# psql -d routing -f /usr/share/postlbs/routing_dd.sql (crea 2 funzioni)

# psql -d routing -f /usr/share/postlbs/routing_dd_wrappers.sql (crea 1 funzione)

# ./configure --disable-slang

Postgis | calcolare la lunghezza totale di uno strato lineare

Postgis offre 1000 strumenti per l’analisi spaziale. Una di queste, semplice quanto efficace, e’ la possibilita’ di calcolare la lunghezza totale degli oggetti memorizzati in una tabella di tipo LINESTRING.

Per esempio possiamo porci questa domanda : qual e’ la lunghezza totale delle strade, espressa in Km?
Procediamo:

– connettersi al database con psql:

$ psql -h nome_host -U nome_utente nome_database;

– una volta entrati (dopo aver digitato la password) impartire la seguente istruzione SQL:

nome_database=> SELECT sum(length(the_geom))/1000 AS km_roads FROM nome_tabella;

Nel mio caso ho ottenuto:

km_roads
——————
187.869370073215

che rappresenta la lunghezza totale espressa in Km.

Nel caso si volesse recuperare la lunghezza delle strade distinte per categoria (o meglio “classificazione”):

nome_database=> SELECT classifica,sum(length(the_geom))/1000 AS km_roads FROM grafo_new GROUP BY classifica;

classifica  |     km_roads
————-+——————-
| 0.278103249728031
provinciale |  7.57308599148574
statale     |  12.8419180713568
comunale    |   155.13306294845
autostrada  |  1.00396374819259
vicinale    |  11.0392360640017
(6 rows)

In questo modo si ottiene la lunghezza distinta per classificazione di strade