[Gfoss] postgis2spatialite

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)…

Se qualcuno ha dei suggerimenti sono molto grato.

ciao
flavio

[0] http://trac.osgeo.org/postgis/wiki/SpatiaLite

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:

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:

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 …

Ciao Flavio,

2010/11/29 flavio rigolon <flavio.rigolon@gmail.com>

“nome del layer” (GEOMETRY non è un layer valido e non può essere caricato)

semplicemente devi forzare il tipo di geometrie da creare usando ogr2ogr con
l’opzione -nlt (vedi [1]) perché in effetti il tipo creato di default è GEOMETRY.

Saluti.

[1] http://www.gdal.org/ogr2ogr.html

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)…

Se qualcuno ha dei suggerimenti sono molto grato.

ciao
flavio

[0] http://trac.osgeo.org/postgis/wiki/SpatiaLite


Iscriviti all’associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell’Associazione GFOSS.it.
485 iscritti al 20.11.2010


Giuseppe Sucameli

Il giorno 29 novembre 2010 15:39, Giuseppe Sucameli <sucameli@faunalia.it> ha scritto:

Ciao Flavio,

2010/11/29 flavio rigolon <flavio.rigolon@gmail.com>

“nome del layer” (GEOMETRY non è un layer valido e non può essere caricato)

semplicemente devi forzare il tipo di geometrie da creare usando ogr2ogr con
l’opzione -nlt (vedi [1]) perché in effetti il tipo creato di default è GEOMETRY.

Grazie Giuseppe.
Pero’ in questo modo vado a forzare tutte le tabelle del DB
ad un solo tipo di geometria; quando invece ci sono varie tabelle
POINT, LINESTRING, MULTIPPLYGON,…

Alla pagina indicata dice:


-nlt type:

Define the geometry type for the created layer. One of NONE, GEOMETRY, POINT, LINESTRING, POLYGON, GEOMETRYCOLLECTION, MULTIPOINT, MULTIPOLYGON or MULTILINESTRING. Add “25D” to the name to get 2.5D versions.
-------------------------

Quindi è riferito ad una tabella/layer alla volta.
O sbaglio io a capire?

grazie ancora
flavio

grazie Sandro per i poderosi chiarimenti!

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.

si; questo puo’ essere stato un refuso da import “vecchi”

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

grazie 1000!

ciao
flavio

2010/11/29 flavio rigolon <flavio.rigolon@gmail.com>

Il giorno 29 novembre 2010 15:39, Giuseppe Sucameli <sucameli@faunalia.it> ha scritto:

“nome del layer” (GEOMETRY non è un layer valido e non può essere caricato)

semplicemente devi forzare il tipo di geometrie da creare usando ogr2ogr con
l’opzione -nlt (vedi [1]) perché in effetti il tipo creato di default è GEOMETRY.

Pero’ in questo modo vado a forzare tutte le tabelle del DB
ad un solo tipo di geometria; quando invece ci sono varie tabelle
POINT, LINESTRING, MULTIPPLYGON,…

In effetti non hai tutti i torti.
L’opzione -nlt nel tuo caso forza il tipo di geometria di tutte le tabelle create
nell’operazione.

Nel caso in cui hai tipi differenti, credo che non sia possibile copiare le tabelle con
i relativi tipi di geometria in maniera automatica (rimane da capirne il perché).
Devi quindi definire il tipo singolarmente per ogni tabella, ad es. come ci fa notare
Sandro potresti usare delle query successivamente alla creazione del DB.

Saluti.

grazie ancora
flavio


Giuseppe Sucameli