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 ![:slight_smile: :slight_smile:](/images/emoji/twitter/slight_smile.png?v=12)
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” ![:slight_smile: :slight_smile:](/images/emoji/twitter/slight_smile.png?v=12)
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 …