[Gfoss] postgis2spatialite

a.furieri a lqt.it a.furieri a lqt.it
Lun 29 Nov 2010 15:04:22 CET


On Mon, 29 Nov 2010 11:51:16 +0100, flavio rigolon wrote
> ciao,
>  sto cercando di esportare un DB Postgis in Spatialite (sono su debian testing, GDAL 1.7 compilate venerdì).
> Ho seguito la procedura indicata qui [0] (ultimo punto).
> Il db viene creato con successo; se cerco di caricare i dati da QGIS (r14757)
> riesco a connettermi, a visualizzare l'elenco delle tabelle ma al momento del
> caricamento ottengo un errore:
> 
> ------------------------------
> "nome del layer" (GEOMETRY non è un layer valido e non può essere caricato)
> ------------------------------
> 
> Ho provato ad aprire il db con sqlitebrowser: vedo tutte le tabelle ben pololate
> ma in effetti il campo GEOMETRY è vuoto (o almeno così pare)...
>

ok, nel frattempo Flavio mi ha girato (privatamente)
il DB SpatiaLite generato da ogr2ogr, e quindi sono
in grado di dare una risposta esaustiva.

in parole spicciole: l'output di ogr2ogr "funzionicchia",
ma ci sono diverse criticità (bugs ????) che vanno
corrette "a manina" per ottenere un vero DB splite 
funzionante senza problemi

----------------
NOTIZIA IMPORTANTE: non utilizzate mai strumenti come
sqlitebrowser per lavorare su un DB spatialite: supportano
solo SQLite 'base', ma non hanno nessuna idea di cosa
sia spatialite e/o di come vanno gestiti/visualizzati
i dati Geometry ... rischiate di corrompere il DB :-)
----------------

GEOMETRY_COLUMNS
==========================
ci sono almeno un paio di "farfalline":
- molto spesso trovo SRID=NULL: ma questo per
splite è assolutamente *illegale* (casomai per
marcare uno srid 'non identificato' occorre
usare -1, come da standard OCG)
- trovo inoltre utilizzata due volte una classe 
GEOMETRY (che non è supportata da splite: 
casomai dovrebbe essere GEOMETRY_COLLECTION)

TAVOLE GEOMETRICHE
==========================
quasi sempre i valori delle geometrie presentano 
SRID=-1
non sono in grado di dire se era un problema già
presente nel DB PostGIS di origine.
in ogni caso è sempre meglio assegnare uno
SRID esplicito ovviamente
inolte non sono mai definiti i triggers
(che invece sono fondamentali per il
corretto funzionamento di splite)

COME CORREGGERE
=============================

UPDATE geometry_columns SET srid = 3003;

UPDATE geometry_columns SET type = 'POLYGON' 
WHERE type = 'GEOMETRY';

n.b.: questo nel caso del DB di Flavio; non
saprei dire se è una regola generale, ovviamente

---

a questo punto occorre "ripulire" tutte le
colonne geometriche mal definite: io ho 
usato Spatialite_GUI perchè è più facile.
per ciascuna tavola occorre:

UPDATE acqua SET GEOMETRY = SetSrid(GEOMETRY, 3003);
- strumento GUI: Rebuild Geometry Triggers

in questo modo si sistema correttamente lo SRID su
tutte le geometrie e si creano i trigges necessari
al buon funzionamento di spatialite

quando avrete (pazientemente) finito, alla fine
avrete un DB SpatiaLite che funziona perfettamente
con QGIS e con qualsiasi altro sw "spatialite compliant" :-)

ciao Sandro

P.S.: la netta sensazione è che all'origine di tutti
i malfunzionamenti di ogr2ogr c'è un fatto semplice
ed assolutamente banale
per creare correttamente una colonna geometrica
occorre usare l'apposita funzione SQL (esattamente
come su PostGIS):

SELECT AddGeometryColumn(....)

se invece il SW va a "sciacquettarsi" direttamente
la GEOMETRY_COLUMNS saltando la chiamata
alla funzione, poi non ci si deve stupire se la
definizione della geometria è invalida è può creare 
problemi durante l'uso successivo ...
 

 
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20101129/7cfa29f4/attachment.htm>


Maggiori informazioni sulla lista Gfoss