[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