A partire da un layer multipolygon contenente edifici di una porzione di territorio (circa 1300 entità) avevo la necessità ci creare un nuovo layer (tabella) contenente i poligoni ottenuti dalla fusione di elementi adiacenti. La situazione di partenza è quella rappresentata in fig. 1.

fig. 1

Utilizzando le funzioni di Postgis ho ottenuto il risultato mediante la seguente istruzione (viene creata una nuova tabella):

# CREATE TABLE nuova_tabella AS SELECT(ST_Dump(ST_Union(ST_Buffer(the_geom, 0.01)))).geom AS the_geom FROM tabella_origine;

Il risultato è quello di fig. 2

fig. 2

Se volessimo aggregare i poligoni anche in base al valore di un determinato attributo il comando diventa:

# CREATE TABLE nuova_tabella AS SELECT nome_campo, (ST_Dump(ST_Union(ST_Buffer(the_geom, 0.01)))).geom AS the_geom FROM tabella_origine GROUP BY nome_campo;

Riporto le operazioni effettuate per migrare alcuni database da Postgresq-8.4 con estensione spaziale Postgis-1.5 a Postgresql-9.5 con Postgis-2.2.

Eseguire un dump dei dati con:

$ PGUSER=postgres pg_dump -Fc nome_db > nome_db.dmp

Questa operazione va fatta per ogni db presente nel cluster; si ottengono i relativi dump in formato compresso (.dmp) da utilizzare poi per l’importazione della nuova architettura.

Stoppare Postgresql-8.4 con (da root):

# /etc/init.d/postgresql stop 8.4

Installare la versione 9.5 di Postgresql e la versione 2.2 di Postgis (e dipendenze collegate) con:

# apt-get install postgresql-9.5 postgis postgis-2.2

A questo punto si potrebbe droppare il cluster della versione 8.4 con “pg_dropcluster –stop 8.4 main“. Nel mio caso ho invece preferito rimuovere Postgresql-8.4 e Postgis 1.5 con “apt-get purge postgresql-8.4*”

Creare gli utenti dei db (nel nostro caso abbiamo ricreato gli utenti che avevamo prima di effettuare la migrazione):

$ su

# su postgres

Entrare in un db (es: template1):

# psql template1

e creare gli utenti necessari:

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

(nel nostro caso l’utente creato avra’ la facolta’ di creare database e utenti)

Creare un template apposito per i db spaziali che chiameremo “template_gis”:

#= CREATE DATABASE template_gis template=template0;

Uscire dal database template1 e (sempre come utente postgres) importare le funzioni spaziali nel database appena creato:

# psql -d template_gis -f /usr/share/postgresql/9.5/contrib/postgis2.2/postgis.sql

# psql -d template_gis -f /usr/share/postgresql/9.5/contrib/postgis2.2/spatial_ref_sys.sql

# psql -d template_gis -f /usr/share/postgresql/9.5/contrib/postgis2.2/rtpostgis.sql

In questo modo abbiamo popolato il template_gis con tutti i sistemi di riferimento spaziali e tutte le funzioni dedicate alla manipolazione di dati vettoriali (“postgis.sql”  e raster “rtpostgis.sql”)

Ritornare all’interno del database template1:

# psql template1

e facciamo in mdo che il database template_gis sia un template:

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

Creare i database (uno alla volta)

#= CREATE DATABASE nome_db template=template_gis OWNER nome_utente;

Uscire dal template1 e popolare i nuovi database con l’aiuto dello script “postgis_restore.pl”:

$ /usr/share/postgresql/9.5/contrib/postgis-2.2/postgis_restore.sql nome_db.dmp | psql nome_db

Ho provato a replicare in locale l’ottimo servizio offerto da maposmatic.org (un’applicazione per generare porzioni di mappa stampabili come file PDF, PNG, SVG,…. comprendente l’elenco dei nomi delle vie indicizzate in una griglia).

Ho seguito le istruzioni di installazione riportate nel pacchetto ocitysmap alle quali pero’ ho dovuto apportare alcune modifiche (la guida fa riferimento ad una installazione eseguita su ubuntu 14.04, mentre io ho provato su Debian testing ad oggi – ottobre 2016).

Per comodità operativa (potrebbe non essere il metodo migliore) e per dare chiarezza di lettura ai passaggi da eseguire ho strutturato l’ambiente di lavoro in questo modo:

– posizionandosi nella home dell’utente ho creato una directory in cui salvare i sorgenti chiamata “src”

$ mkdir src

– sempre all’interno della home ho creato un’altra directory chiamata “osm_data” al cui interno salveremo i dati scaricati dal server OSM e che saranno importati successivamente nel db PostGIS

$ mkdir osm_data

Ed ecco il procedimento globale:

1 Installazione di PostgreSQL e PostGIS

# apt-get install postgresql postgresql-contrib postgresql-9.4-postgis-2.2 (PostgreSQL 9.4.5)

2 Creazione di un nuovo utente di PostgreSQL

diventare root:

$ su

diventare superuser postgres:

# su postgres

Creare il nuovo utente di PostgreSQL:

# createuser -P -S -D -R maposmatic

(chiamiamo “maposmatic” il nuovo utente; inserire la password due volte per conferma)

3 Creazione del database

# createdb -E UTF8 -O mapomsatic db_maposmatic

4 Abilitazione di PostGIS sul database

4.a Abilitare il linguaggio plpgsql sul database creato db_maposmatic (utente postgres)

# createlang plpgsql db_maposmatic

4.b Installazione del supporto PostGIS nel database

# psql -f /usr/share/postgresql/9.4/contrib/postgis-2.2/postgis.sql -d db_maposmatic

4.c Opzionalmente inseriamo anche i commenti

# psql -f /usr/share/postgresql/9.4/contrib/postgis-2.2/postgis_comments.sql -d db_maposmatic

4.d Aggiunta della lista dei sistemi di riferimento spaziale

# psql -f /usr/share/postgresql/9.4/contrib/postgis-2.2/spatial_ref_sys.sql -d db_maposmatic

4.e Cambiare il proprietario delle tabelle

# echo “ALTER TABLE geometry_columns OWNER TO maposmatic; ALTER TABLE spatial_ref_sys OWNER TO maposmatic;” | psql -d db_maposmatic

4.f Aggiungere l’estensione hstore

# echo “CREATE EXTENSION hstore;” | psql -d db_maposmatic

5 Installazione di osm2pgsql

osm2pgsql e’ lo strumento che consente di importare i dati OSM direttamente in un database PostGIS. La guida suggerisce di scaricare la versione da SVN in quanto quello pacchettizato Debian/Ubuntu non e’ abbastanza recente. Ho tentato comunque l’installazione via apt-get ed in realta’ tutto e’ andato bene, quindi:

# apt-get install osm2pgsql

6. Download dei dati dal server OSM

Il download dei dati si puo’ effettuare mediante il servizio offerto da geofabrik.de, per esempio cercando la zona di nostro interesse

In alternativa (nel caso volessimo un’area di dimensioni ridotte e/o comunque ben delimitate da una bounding box (bbox)) possiamo utilizzare il servzio offerto da overpass.osm.rambler.ru. In questo caso utilizziamo wget per scaricare una certa area geografica:

$ wget http://overpass.osm.rambler.ru/cgi/xapi_meta?*%5Bbbox=long_inf,lat_inf,long_sup,lat_sup%5D

tradotto con dati reali potrebbe essere:

$ wget http://overpass.osm.rambler.ru/cgi/xapi_meta?*%5Bbbox=11.3640,45.4650,11.4660,45.5780%5D

Si ottiene un file denominato “xapi_meta?*[bbox=11.4740,45.4150,11.5160,45.4650]” che potremo rinominare in “dati_osm.osm” (per esempio mediante il comando “mv”).

7 Importazione dei dati OSM all’interno del database PostGIS

L’importazione avviene mediante il seguente comando:

$ osm2pgsql -s -c -d db_maposmatic -m -U maposmatic -W -H localhost -k dati_osm.osm

A seconda della dimensione del file .osm il processo puo’ durare qualche secondo, minuto o ora (l’importazione di tutto il nord-est d’Italia, circa 750 MB, e’ durata circa 1 ora e mezza) e dipende molto dalle caratteristiche hardware del computer.

8 Installazione di Mapnik

8.a Installare python-mapnik

Via synaptic o apt-get o compilarlo da sorgente mediante “python setup.py install”

8.b Installazione dipendenze

# apt-get build-dep python-mapnik

e installare altre librerie necessarie (in particolare e’ opportuno installare le librerie libboost piu’ recenti. Ad momento della stesura del presente articolo su Debian Testing si trovano le libboost-1.61):

# apt-get install libboost1.61-dev libboost-date-time1.61-dev libboost-filesystem1.61-dev libboost-iostreams1.61-dev libboost-program-options1.61-dev libboost-python1.61-dev libboost-regex1.61-dev libboost-serialization1.61-dev libboost-system1.61-dev libboost-thread1.61-dev libharfbuzz-dev

8.c Download Mapnik

Download dell’ultima versione di Mapnik dal repository git (dopo esseresi posizionati nella directory /home/nome_utente/src/):

$ cd src

Lanciare il download:

$ git clone git://github.com/mapnik/mapnik.git

Spostarsi nella directory creata durante il download “mapnik”:

$ cd mapnik

8.d Compilazione ed installazione

Prima di eseguire il config assicurarsi di fare un update dei submodule di mapnik:

$ git submodule update –init

$ git submodule update –init deps/mapbox/variant

Eseguire il config:

$ python scons/scons.py configure INPUT_PLUGINS=all OPTIMIZATION=3 SYSTEM_FONTS=/usr/share/fonts/ PYCAIRO=true XMLPARSER=libxml2

Compilare:

$ python scons/scons.py

Installare (dopo essersi loggati come root):

# python scons/scon.py install

8.e Controllo dell’installazione

Lanciare un interprete python ed invocare “import mapnik”:

$ python

dovremmo ottenere una cosa del tipo:

Python 2.7.12+ (default, Sep  1 2016, 20:27:38)
[GCC 6.2.0 20160927] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
>>>

quindi importiamo il modulo mapnik appena compilato:

>>> import mapnik
>>>

Se tutto e’ ok dovremmo ottenere il prompt in attesa di comandi; in tal caso significa che mapnik e’ stato compilato  ed installato correttamente.

9. Installazione di Mapnik-OSM

Mapnik-OSM e’ un set di file che indicano a Mapnik come renderizzare le mappe di OpenStreetMap.

9.a Download

Dopo essersi posizionati nella directory /home/nome_utente/src/ scarichiamo il sorgente mediante svn (nel caso svn non fosse presente installarlo via “apt-get install subversion”)

$ svn co http://svn.openstreetmap.org/applications/rendering/mapnik mapnik2-osm

Questo creera’ una nuova directory in /home/nome_utente/src chiamata “mapnik2-osm”

9.b Installazione dei dati statici generali

In aggiunta ai dati OSM sono necessari altri dati statici (world boundaries, ecc…)

$ cd mapnik2-osm

Invochiamo da shell il comando get-coastlines.sh che scarichera’ una serie di SHP delle linee di costa ed altri dati.

$ sh ./get-coastlines.sh

9.c Abilitazione degli unifont

Per un render corretto dei caratteri Coreano, Cinese o Giapponese si deve usare il font unifont. Per abilitarlo (da root):

# apt-get install ttf-unifont

E’ consigliato eseguire anche un reconfigure del locales:

# dpkg-reconfigure locales

9.d Configurazione

La configurazione avviene invocando lo script in python chiamato “generate_xml.py” che si trova in /home/nome_utente/src/mapnik2-osm/; spostarsi quindi nella directory interessata:

$ cd /home/sit/src/mapnik2-osm/

e lanciare il comando

$ python ./generate_xml.py –dbname db_maposmatic –host ‘localhost’ –user maposmatic –port 5432 –password ‘password_utente_maposmatic’

In risposta dovremmo ottenere un messaggio simile a questo:

Include files written successfully! Pass the osm.xml file as an argument if you want to serialize a new version or test reading the XML

10 Installazione di OCitySMap

10.a Recuperare i sorgenti

Posizionarsi sempre nella directory /home/sit/src/

$ git clone git://git.savannah.nongnu.org/maposmatic/ocitysmap.git

10.b Installazione delle dipendenze

# apt-get install python-psycopg2 python-gdal python-gtk2 python-cairo python-shapely

10.c Modifica di alcuni file di configurazione di OCitySMap

Editare il file /home/nome_utente/src/ocitysmap/ocitysmap/maplib/map_canvas.py alle righe 176 e 177. In particolare modificare la riga 176 nel modo seguente:

r.symbols.append(mapnik.PolygonSymbolizer())

e la riga 177 nel modo seguente:

r.symbols.append(mapnik.LineSymbolizer())

altrimenti durante il processo compariranno degli errori sull’impossibilita’ di eseguire alcuni render.

11 File di configurazione di OcitySMap

copiare il file /home/nome_utente/src/ocitysmap/ocitysmap.conf.dist nella home directory dell’utente e rinominarlo in “.ocitysmap.conf”. Da notare il punto davanti al nome del file: indica che il file e’ nascosto. Editarlo poi inserendo i dati corretti del database da utilizzare. Ecco il file .ocitysmap.conf usato in questa guida:

[datasource]
host=localhost
user=maposmatic
password=password
dbname=db_maposmatic
# Optional database port, defaults to 5432
# port=5432

[rendering]
# List of available stylesheets, each needs to be described by an eponymous
# configuration section in this file.
available_stylesheets: stylesheet_osm1, stylesheet_osm2

# The default Mapnik stylesheet.
[stylesheet_osm1]
name: Default
description: The default OSM style
path: /home/sit/src/mapnik2-osm/osm.xml

# Another stylesheet
[stylesheet_osm2]
name: AnotherOne
description: Another OSM Stylesheet
path: /home/sit/src/ocitysmap/stylesheet/maposmatic-printable/osm.xml

12 Lanciare OCitySMap

Spostarsi nella directory /home/nome_utente/src/ocitysmap/ e lanciare il comando per l’esecuzione del render:

$ ./render.py -t “titole della mappa” -f pdf -p nome_file_generato –osmid=-44831

nel caso si conoscesse l’osmid della relazione (in questo caso identifica un confine comunale) che intendiamo usare. Per ricavare l’osmid consultare l’ottimo servizio fornito da nominatim

lanciando il comando ./render.py –help si ottiene un elenco dettagliato dei comandi opzionali del modulo.

Se invece si volesse effettuare il render di una determinata area geografica e’ possibile indicarla con i valori del bbox, per esempio:

$ ./render.py -t “titolo della mappa” -f pdf -p nome_file_generato -b lat_inf,long_inf lat_sup,long_sup

dove lat_inf e long_inf sono rispettivamente la latitudine e la longitudine dell’estremo inferiore sinistro (o ovest) e lat_sup e long_sup sono rispettivamente la latitudine e longitudine dell’estremo superiore destro (o est). Tradotto don dati reali:

$ ./render.py -t “titolo della mappa” -f pdf -p nome_file_generato -b 45.3330,11.3280 45.4400,11.4595

Verranno generati due file: “nome_file_generato.pdf” contenente la mappa ed un file “nome_file_generato.csv” con l’elengo indicizzato della strade e dei luoghi di interesse trovati.

Quando si sviluppano applicazioni con django si ha a disposizione un server web “temporaneo” che si avvia con il comando:

$ python manage.py runserver

ed e’ raggiungibile all’indirizzo:

http://lcoalshot:8000

Se vogliamo accedervi da remoto bisogna lanciare prima il comando (sulla macchina client):

$ ssh -L 8888:127.0.0.1:8000 nome_utente@indirizzo_ip_server

per esempio:

$ ssh -L 8888:127.0.0.1:8000 sit@192.168.168.1

A questo punto possiamo collegarci mediante il browser puntando a:

http://localhost:8888

PS: E’ necessario avere avviato in precedenza il servizio con:

$ python manage.py runserver

sulla macchina host

Come da titolo, per ottenere soltanto l’anno da un campo “date” (nella forma “aaaa-mm-gg”, per esempio: “2018-01-03”) eseguire la seguente istruzione:

nomedb=# SELECT date_part(‘year’, nome_colonna_date) FROM nome_tabella;

Supponiamo di avere due tabelle (tabella01 e tabella02) e vogliamo concatenarle in una nuova tabella (in sostanza vogliamo accodare i record delle due tabelle). Ecco l’istruzione SQL (grazie a questo thread):

=# SELECT * INTO nuova_tabella FROM (SELECT * FROM tabella01 UNION SELECT * FROM tabella02) AS tmp;

Supponiamo di avere una tabella con un campo “data” di tipo DATE (nella forma “aaaa-mm-gg” – esempio: 2018-01-03) e vogliamo popolare un altro campo (per esempio “anno”) di tipo integer con il solo valore dell’anno prendendolo dal campo “data”. Ecco la sintassi SQL:

=# UPDATE nome_tabella SET anno=date_part(‘year’, data);

Se ad una tabella sono collegati dei trigger è possibile disabilitarli temporaneamente e riabilitarli in un secondo momento. Prima di tutto è necessario conoscere quali siano i trigger della tabella in oggetto con il comando:

=# \dS nome_tabella

che restituisce la lista dei trigger attivi.

Per disabilitarne uno:

=# ALTER TABLE nome_tabella DISABLE TRIGGER nome_trigger;

rilanciando il comando

=# \dS nome_tabella

vedremo che il trigger disabilitato verrà marcato con non attivo.

Per riabilitarlo:

=# ALTER TABLE nome_tabella ENABLE TRIGGER nome_trigger;

Tratto, tradotto e leggermente modificato da: https://postgis.net/workshops/postgis-intro/history_tracking.html

Questo articolo non è assolutamente “farina del mio sacco”; ho soltanto tradotto e leggermente modificato quanto riportato in una pagina fatta molto bene (ringrazio sentitamente l’autore o gli autori) che si trova qui: https://postgis.net/workshops/postgis-intro/history_tracking.html adattando l’esempio ai dati che ho utilizzato per fare un test. Funziona davvero bene!

Un requisito comune per i database è la capacità di tenere traccia della cronologia: come sono cambiati i dati tra due date, chi ha apportato le modifiche e dove si sono verificate?

Utilizzando il database e il sistema di trigger, è possibile aggiungere il monitoraggio della cronologia a qualsiasi tabella, mantenendo un semplice accesso di “modifica diretta” alla tabella principale.

Il monitoraggio della cronologia funziona mantenendo una tabella della cronologia che registra, per ogni modifica:

• Se un record è stato creato, quando è stato aggiunto e da chi.
• Se un record è stato eliminato, quando è stato eliminato e da chi.
• Se un record è stato aggiornato, aggiungendo un record di cancellazione (per il vecchio stato) e un record di creazione (per il nuovo stato).

Utilizzo di TSTZRANGE

La tabella della cronologia utilizza una funzionalità specifica di PostgreSQL, il tipo “intervallo di timestamp” (tstzrange), per memorizzare l’intervallo di tempo in cui un record della cronologia era il record “live”. Tutti gli intervalli di timestamp nella tabella della cronologia per una particolare caratteristica non si sovrappongono ma restano adiacenti.

L’intervallo per un nuovo record inizierà a now() e avrà un punto finale aperto, in modo che l’intervallo copra tutto il tempo dall’ora corrente al futuro.

Impartendo il comando seguente:

=# SELECT tstzrange(current_timestamp, NULL);

Otterremo per esempio:

=#

tstzrange
————————————
[“2023-08-01 14:49:40.910074-07”,)

Allo stesso modo, l’intervallo di tempo per un record eliminato verrà aggiornato per includere l’ora corrente come punto finale dell’intervallo di tempo.

La ricerca di intervalli di tempo è molto più semplice della ricerca di una coppia di timestamp: un intervallo di tempo aperto comprende tutto il tempo dal punto iniziale all’infinito. Per gli intervalli useremo l’operatore “contiene” @>. Per esempio:

=# SELECT tstzrange(current_timestamp – ’10m’::interval, NULL) @> current_timestamp;

Gli intervalli possono essere indicizzati in modo molto efficiente utilizzando un indice GIST, proprio come i dati spaziali, come mostreremo di seguito. Ciò rende le query di cronologia molto efficienti.

Costruire la tabella della storia (history)

Utilizzando queste informazioni è possibile ricostruire lo stato della tabella di modifica in qualsiasi momento. Partiamo per esempio da una tabella che contiene lo stradario (strade); aggiungeremo quindi il monitoraggio della cronologia alla nostra tabella “strade”.

Innanzitutto, aggiungiamo una nuova tabella “strade_history”. Questa è la tabella che useremo per memorizzare tutte le informazioni di modifica storiche. Oltre a tutti i campi di “strade”, aggiungiamo altri quattro campi.

• hid: la chiave primaria per la tabella della cronologia
• created_by: l’utente del database che ha creato il record
• deleted_by: l’utente del database che ha causato la marcatura del record come cancellato
• valid_range: l’intervallo di tempo entro il quale il record era “live”

Si noti che in realtà non eliminiamo alcun record nella tabella della cronologia, contrassegniamo solo l’ora in cui hanno cessato di far parte dello stato corrente della tabella di modifica.

=# CREATE TABLE strade_history (hid SERIAL PRIMARY KEY, gid INTEGER, nome VARCHAR(50), geom GEOMETRY (MULTILINESTRING, 3003), valid_range TSTZRANGE, created_by VARCHAR(32), deleted_by VARCHAR(32));

=# CREATE INDEX strade_history_geom_x ON strade_history USING GIST (geom);

=# CREATE INDEX strade_history_tstz_x ON strade_history USING GIST (valid_range);

Successivamente, importiamo lo stato corrente della tabella attiva, “strade” nella tabella della cronologia, in modo da avere un punto di partenza da cui tracciare la cronologia. Si noti che inseriamo l’ora di creazione e l’utente di creazione, ma lasciamo NULL la fine dell’intervallo di tempo e l’informazione “deleted_by”.

=# INSERT INTO strade_history (gid, nome, geom, valid_range, created_by) SELECT gid, nome, geom, tstzrange(now(), NULL), current_user FROM strade;

Ora abbiamo bisogno di tre trigger sulla tabella attiva, per le azioni INSERT, DELETE e UPDATE. Per prima cosa creiamo le funzioni trigger, quindi le colleghiamo alla tabella come trigger.

Per un nuovo inserimento, aggiungiamo semplicemente un nuovo record nella tabella della cronologia con l’ora di creazione/utente.

=# CREATE OR REPLACE FUNCTION strade_insert() RETURNS trigger AS
$$
BEGIN
INSERT INTO strade_history
(gid, nome, geom, valid_range, created_by)
VALUES
(NEW.gid, NEW.nome, NEW.geom,
tstzrange(current_timestamp, NULL), current_user);
RETURN NEW;
END;
$$
LANGUAGE plpgsql;

Quindi creiamo il primo trigger per l’inserimento

=# CREATE TRIGGER strade_insert_trigger AFTER INSERT ON strade FOR EACH ROW EXECUTE PROCEDURE strade_insert();

Per la cancellazione, contrassegniamo semplicemente il record della cronologia attualmente attivo (quello con un tempo di cancellazione NULL) come cancellato.

=# CREATE OR REPLACE FUNCTION strade_delete() RETURNS trigger AS
$$
BEGIN
UPDATE strade_history
SET valid_range = tstzrange(lower(valid_range), current_timestamp),
deleted_by = current_user
WHERE valid_range @> current_timestamp AND gid = OLD.gid;
RETURN NULL;
END;
$$
LANGUAGE plpgsql;

E relativo trigger per l’eliminazione:

=# CREATE TRIGGER strade_delete_trigger AFTER DELETE ON strade FOR EACH ROW EXECUTE PROCEDURE strade_delete();

Per un aggiornamento, prima contrassegniamo il record della cronologia attivo come eliminato, quindi inseriamo un nuovo record per lo stato aggiornato.

=# CREATE OR REPLACE FUNCTION strade_update() RETURNS trigger AS
$$
BEGIN
UPDATE strade_history
SET valid_range = tstzrange(lower(valid_range), current_timestamp),
deleted_by = current_user
WHERE valid_range @> current_timestamp AND gid = OLD.gid;
INSERT INTO strade_history
(gid, nome, geom, valid_range, created_by)
VALUES
(NEW.gid, NEW.nome, NEW.geom,
tstzrange(current_timestamp, NULL), current_user);
RETURN NEW;
END;
$$
LANGUAGE plpgsql;

E relativo trigger per l’aggiornamento:

=# CREATE TRIGGER strade_update_trigger AFTER UPDATE ON strade FOR EACH ROW EXECUTE PROCEDURE strade_update();

Modificare la tabella

Ora che la tabella della cronologia è abilitata, possiamo apportare modifiche alla tabella principale (“strade”) e guardare le voci del registro apparire nella tabella della cronologia (“history_strade”).

Da notare la potenza di questo approccio alla cronologia basato su database: indipendentemente dallo strumento utilizzato per apportare le modifiche, che si tratti della riga di comando SQL, di uno strumento JDBC basato sul Web o di uno strumento desktop come QGIS, la cronologia viene costantemente monitorata.

Modifiche SQL

Trasformiamo la due strada denominata “VIA ROMA” in “VIA ROMA IMPERIALE” (per esempio):

L’aggiornamento della strada farà sì che la strada originale venga contrassegnata come cancellata nella tabella della cronologia, con un’ora di eliminazione di adesso, e una nuova strada con l’aggiunta del nuovo nome, con un’ora di aggiunta di adesso. Possiamo consultare i dati storici.

Interrogazione della tabella cronologica

Ora che abbiamo una tabella cronologica, a cosa serve? È utile per viaggiare nel tempo! Per viaggiare in un particolare tempo T, è necessario costruire una query che includa:

• Tutti i record creati prima di T e non ancora cancellati; e anche

• Tutti i record creati prima di T, ma eliminati dopo T.

Possiamo usare questa logica per creare una query, o una vista, dello stato dei dati nel passato. Poiché presumibilmente tutte le tue modifiche di prova sono avvenute negli ultimi due minuti, creiamo una vista della tabella della cronologia che mostri lo stato della tabella 10 minuti fa, prima che si iniziasse a modificare (quindi, i dati originali).

=# CREATE OR REPLACE VIEW strade_dieci_min_ago AS SELECT * FROM strade_history WHERE valid_range @> (now() – ’10min’::interval);

Caricando questa vista su QGIS possiamo vedere i dati come erano 10 minuti fa

Se invece volessimo recuperare la versione della tabella ad una certa data (per esempio alla data del 01 agosto 2023):

=# CREATE OR REPLACE VIEW strade_al_20230801 AS SELECT strade_history.hid, strade_history.gid, strade_history.nome, strade_history.geom, strade_history.valid_range, strade_history.created_by, strade_history.deleted_by FROM strade_history WHERE lower(strade_history.valid_range) < ‘2023-08-02 13:10:38’;

In questo modo avremo tutti gli oggetti presenti nel database prima del 2 agosto 2023 alle ore 13:10:38″. Verranno pertanto esclusi tutti gli oggetti creati, modificati o eliminati dopo quel momento.