postgis2spatialite
Locked
 
|
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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
|
|
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 ... _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
|
|
In reply to this post by Flavio Rigolon
Ciao Flavio,
2010/11/29 flavio rigolon <[hidden email]> "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
-- Giuseppe Sucameli _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
|
|
Il giorno 29 novembre 2010 15:39, Giuseppe Sucameli <[hidden email]> ha scritto: Ciao Flavio, 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:
Quindi è riferito ad una tabella/layer alla volta. O sbaglio io a capire? grazie ancora flavio _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
|
|
In reply to this post by a.furieri
grazie Sandro per i poderosi chiarimenti!
si; questo puo' essere stato un refuso da import "vecchi"
grazie 1000! flavio _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
|
|
In reply to this post by Flavio Rigolon
2010/11/29 flavio rigolon <[hidden email]>
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.
-- Giuseppe Sucameli _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |