Re: [Gfoss] Export PostGIS - SpatiaLITE

[a . furieri]

On Sun, 25 Feb 2018 12:00:41 +0100, Andrea Peri wrote:

Forse sarebbe stato meglio introdurre una codifica differente dal
NULLO per gestire l'eccezione ? Boh.



forse tutto considerato la soluzione piu' corretta sarebbe
quella di supportare il geom-type EMPTY, che e' previsto
dalle specifiche OGC-SFS ma che purtroppo non e' supportato
da SpatiaLite.

questo ci consentirebbe di eliminare qualsiasi ambiguita',
perche' p.es. determinare un'intersezione tra due geometrie
perfettamente valide ma completamente disgiunte tornerebbe
EMPTY, mentre un valore di ritorno NULL a questo punto
indicherebbe con assoluta certezza che almeno uno tra gli
argomenti di invocazione della funzione era inaccettabile.



in ogni caso ora anche cio' comporterebbe una perdita di
compatibilita' e quindi e' una disquisizione inutile.



vero: ma sicuramente l'ipotesi di introdurre prima o poi
le geometrie EMPTY si presenta come una soluzione piu'
facile da implementare, e con conseguenze molto meno
traumatiche.
dopo tutto il flusso di esecuzione non verrebbe interrotto,
proprio come avviene attualmente.
mentre invece i valori di ritorno si presterebbero ad una
interpretazione non ambigua.

ciao Sandro
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Andrea Peri]

Hai fatot bene a correggermi.
In effetti mi ero sbagliato. Per qualche strana ragione mi e' rimasto in
testa che la tua CastToSimple ritornasse sempre il primo. Forse faceva
cosi' nelle prime versioni ?

Ad ogni modo la prudenza e' sempre d'obbligo perche' se ritorna NUL uno le
perde tutte anziche' tutte meno una.

Invece interessante lo spunto sul ritorno del NULL anziche' l'eccezione.

Charisco quindimeglio il mio punto di vista.

La ragione per cui io preferirei l'eccezione e' legata a due considerazioni:

la prima e' che cosi' mi accorgo subito che li vi e' un errore.
Mentre se faccio una elaborazione diqualche ora e parecchie funzioni.
Se alla fine manca qualcosa devo fare un step by step di ogni funzione per
capire dove sta il problema.

ma su questo ci si tira su le maniche e si fa'.


Il vero problema sorge quando si fanno delle elaborazioni che ritornano
NULL in alcuni casi.

Mi spiego con un esempio a parole.

Se io faccio delle intersezioni e voglio alla fine estrarre i records da
cui queste intersezioni restituiscono un valore non nullo.

Io ottengo dei risultati, MA NON HO CERTEZZA che quelle escluse perche'
NULLE lo sono perche' realmente deve essere NULLO (ovvero nessuna
intersezione) o perche' vi era intersezione, ma a causa di un problema
della geometria ha generato una eccezione che e' stata trasformata in NULLO.

Quindi ho sempre una ambiguita nel risultato in certe situazioni.

Forse sarebbe stato meglio introdurre una codifica differente dal NULLO per
gestire l'eccezione ? Boh.
in ogni caso ora anche cio' comporterebbe una perdita di compatibilita' e
quindi e' una disquisizione inutile.

Ma ci tenevo a chiarire il mio punto di vista perche' piu' si conoscono gli
strumenti che si usa e meglio e'.

A.


Il giorno 25 febbraio 2018 11:06,  ha scritto:

> On Sun, 25 Feb 2018 06:48:04 +0100, Andrea Peri wrote:
>
>> Sempre esatto e preciso
>> ma questa volta sento di dover aggiungere un dettaglio ulteriore.
>> :D
>>
>> L operatore casttomulti te dici che si può sempre applicare.
>> Occorre però stare attenti quando si applica per passare da multi a
>> simple ovvero usando l operatore casttosimple.
>>
>> Infatti occorre controllare prima quante parti ha la multi che si
>> vuole trasformare.
>> Se ne ha una sola, ok, si può fare e tutto funziona bene.
>> Se ne ha più di una , su spatialite non si può fare perché si perde
>> tutte le parti eccedenti la prima.
>> Occorre stare veramente attenti perché spatialite non da errore, ma
>> si limita a passare solo la prima parte.
>>
>> Esempio : se ho il.dataset Delle isole dell' arcipelago toscano con un
>> poligono di tipo multipolygon che comprende tutte le isole.
>> Se faccio un semplice casttosimple perdo tutte le isole eccetto la
>> prima.
>>
>>
> Andrea,
>
> scusami ma ti devo correggere almeno in parte.
> e' verissimo che occorre molta cautela quando si applica un cast da
> multi a single, perche' ovviamente il cast funzionera' solo se la
> collection contiene un singolo elemento.
>
> ma quando la collection contiene due o piu' elementi non ti torna
> affatto il primo elemento; ti torna invece un NULL.
>
> spiegazione per chi non e' al corrente: Andrea sostiene da tempo
> che SpatiaLite ha un "brutto vizietto", cioe' quello che moltissime
> funzioni (praticamente tutte) ritornaro valori NULL o FALSE quando
> riscontrano una condizione di errore, mentre invece sarebbe
> preferibile che sollevassero un'eccezione bloccando immediatamente
> il flusso di esecuzione.
>
> dal punto di vista teorico non c'e' dubbio che ha ragione Andrea;
> nella pratica pero' dovere correggere pesantemete svariate
> centinaia di funzioni, oltre ad essere una faticaccia impproba,
> implica anche il rischio di introdurre involontariamente un
> visibilio di regressioni potenzialmente pericolose.
> infine va anche considerato che un cambiamento cosi' radicale
> provocherebbe sicuramente molte difficolta' a tantissime
> applicazioni gia' esistenti che si basano strutturalmente
> sulla logica di funzionamento attuale.
>
> insomma, non escludo che in qualche versione futuribile
> SpatiaLite finira' per abbracciare sistematicamente la
> logica delle eccezioni bloccanti, ma almeno per ora e'
> piu' prudente non allontanarsi troppo da una tradizione
> storicamente ben consolidata.
>
> ciao Sandro
> che implica un vero e proprio cambiamento
>



-- 
-
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Export PostGIS - SpatiaLITE

[a . furieri]

On Sun, 25 Feb 2018 06:48:04 +0100, Andrea Peri wrote:

Sempre esatto e preciso
ma questa volta sento di dover aggiungere un dettaglio ulteriore.
:D

L operatore casttomulti te dici che si può sempre applicare.
Occorre però stare attenti quando si applica per passare da multi a
simple ovvero usando l operatore casttosimple.

Infatti occorre controllare prima quante parti ha la multi che si
vuole trasformare.
Se ne ha una sola, ok, si può fare e tutto funziona bene.
Se ne ha più di una , su spatialite non si può fare perché si perde
tutte le parti eccedenti la prima.
Occorre stare veramente attenti perché spatialite non da errore, ma
si limita a passare solo la prima parte.

Esempio : se ho il.dataset Delle isole dell' arcipelago toscano con 
un

poligono di tipo multipolygon che comprende tutte le isole.
Se faccio un semplice casttosimple perdo tutte le isole eccetto la
prima.



Andrea,

scusami ma ti devo correggere almeno in parte.
e' verissimo che occorre molta cautela quando si applica un cast da
multi a single, perche' ovviamente il cast funzionera' solo se la
collection contiene un singolo elemento.

ma quando la collection contiene due o piu' elementi non ti torna
affatto il primo elemento; ti torna invece un NULL.

spiegazione per chi non e' al corrente: Andrea sostiene da tempo
che SpatiaLite ha un "brutto vizietto", cioe' quello che moltissime
funzioni (praticamente tutte) ritornaro valori NULL o FALSE quando
riscontrano una condizione di errore, mentre invece sarebbe
preferibile che sollevassero un'eccezione bloccando immediatamente
il flusso di esecuzione.

dal punto di vista teorico non c'e' dubbio che ha ragione Andrea;
nella pratica pero' dovere correggere pesantemete svariate
centinaia di funzioni, oltre ad essere una faticaccia impproba,
implica anche il rischio di introdurre involontariamente un
visibilio di regressioni potenzialmente pericolose.
infine va anche considerato che un cambiamento cosi' radicale
provocherebbe sicuramente molte difficolta' a tantissime
applicazioni gia' esistenti che si basano strutturalmente
sulla logica di funzionamento attuale.

insomma, non escludo che in qualche versione futuribile
SpatiaLite finira' per abbracciare sistematicamente la
logica delle eccezioni bloccanti, ma almeno per ora e'
piu' prudente non allontanarsi troppo da una tradizione
storicamente ben consolidata.

ciao Sandro
che implica un vero e proprio cambiamento
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Andrea Peri]

Sempre esatto e preciso
ma questa volta sento di dover aggiungere un dettaglio ulteriore.
:D

L operatore casttomulti te dici che si può sempre applicare.
Occorre però stare attenti quando si applica per passare da multi a simple
ovvero usando l operatore casttosimple.

Infatti occorre controllare prima quante parti ha la multi che si vuole
trasformare.
Se ne ha una sola, ok, si può fare e tutto funziona bene.
Se ne ha più di una , su spatialite non si può fare perché si perde tutte
le parti eccedenti la prima.
Occorre stare veramente attenti perché spatialite non da errore, ma si
limita a passare solo la prima parte.

Esempio : se ho il.dataset Delle isole dell' arcipelago toscano con un
poligono di tipo multipolygon che comprende tutte le isole.
Se faccio un semplice casttosimple perdo tutte le isole eccetto la prima.

A.


Il 24 Feb 2018 20:33,  ha scritto:

On Sat, 24 Feb 2018 19:01:46 +0100, Massimiliano Moraca wrote:

> Buonasera a tutti, vi scrivo dopo un po' per aggiornarvi.
> Senza fare alcuna modifica al db esportato da PostGIS ed usando un semplice
> drag in QGIS tutti i layer vengono correttamente letti. Il problema
> nasce però dopo un po', infatti per non so quale motivo saltano tematismi
> ad esempio. Ho quindi seguito le indicazioni di Alessandro Furieri in
> questo modo:
>
> - per prima cosa occorre verificare cosa contiene
>
>>   esattamente il dataset; basta eseguire la seguente
>>   query SQL:
>> SELECT Count(*), GeometryType(geom), Srid(geom), CoordDimension(geom)
>> FROM table
>> GROUP BY 2, 3, 4;
>>
>
>
> A seguito di questa verifica in SpatiaLite mi sono ritrovato con alcune
> tabelle che erano multi geometrie ma che almeno non mischiavano le
> tipologie di geometrie. Ho ad esempio Polygon e MultiPolygon. Quindi mi
> trovo nel caso 2:
>
>   
>
>
> Non mi è chiaro però se le procedure indicate devono essere svolte in
> PostGIS pre esportazione o in SpatiaLite post esportazione. Qualcuno può
> chiarirmi questo punto?
>
>
ciao Massimiliano,

la procedura di cui al caso 2) la devi eseguire su SpatiaLite.



Un'altra cosa che non mi è chiara, e l'ho verificata anche in PostGIS: come
> è possibile che da una intersezione di due vettori MultiPolygon ne venga
> fuori uno che è sia Polygon che MultiPolygon?
>
>
risposta rapida:

il risultato dell'intersezione tra due (o piu') poligoni dipende tutto da
come si relazionano le figure; a seconda dei casi potresti avere un POINT
(le due figure si toccano su un unico vertice), un LINESTRING (le due
figure si toccano solo lungo un lato), oppure un POLYGON (esiste una vera
e propria intersezione).
piu' ovviamente tutte le combinazioni in salsa "multi" tra i casi
precedenti;
non esiste regola, dipende tutto caso per caso.


risposta ragionata:
---
cerchiamo per prima cosa di sgombrare il campo da eventuali equivoci sulla
terminologia; immagino che quando tu dici "vettore" intendi dire "dataset
contenente geometrie vettoriali", vero ? che quindi secondo la terminologia
SQL corrisponde ad una Spatial Table.

giusto un richiamo veloce al data-model OGC-SFS per il data-type GEOMETRY:
- esistono 3 classi "semplici" (single-part, capaci di rappresentare un
unico
  oggetto geometrico) che sono POINT, LINESTRING e POLYGON.
- poi esistono 4 classi "collection" (multi-part, con la possibilita di
  contenere contemporaneamente piu' oggetti geometrici di tipo semplice)
  che sono MULTIPOINT, MULTILINESTRING, MULTIPOLYGON e GEOMETRYCOLLECTION.
  nei primi tre casi tutti i  membri della collection devono essere del
  medesimo tipo; nell'ultimo caso possono essere di qulunque tipo senza
  restrizioni di sorta.

nota: qualsiasi collection puo' contenere un numero arbitrario di elementi
a partire da uno.

corollario: un oggetto "semplice" come p.es. un POLYGON secondo il modello
canonico OGC-SFS si puo' legittimamente rappresentare anche sotto forma
di MULTIPOLYGON e persino di GEOMETRYCOLLECTION.
dato che questo apre una potenziale ambiguita', e' ovvio che in questo caso
occorre assegnare esplicitamente il Geom-Type desiderato.
purtroppo in molti casi non e' possibile determinare a priori il geom-type
del risultato atteso, e quindi molte librerie lo determinano basandosi
esclusivamente sul conteggio degli oggetti elementari.
quindi se trovano un unico POLYGON concludono che tutta quanta la Geometry
nel suo complesso sia un POLYGON, senza prendere in considerazione che
invece ci si attendeva un MULTIPOLYGON.

SpatiaLite offre un metodo molto semplice ed efficare per aggirare il
problema; le funzioni di casting.
p.es. la CastToMultiPolygon() e' in grado di trasformare "al volo" un
POLYGON in un MULTIPOLYGON. sarebbe sempre opportuno applicare il
casting piu' appropriato prima di provare ad inserire una Geometry
in una Spatial Table, proprio per evitare pasticci come questi di
cui stiamo parlando, ma e' ovvio che da qualche parte questa buona
regola non viene applicata.

ultima 

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Massimiliano Moraca]

Ciao Alessandro, grazie mille per la risposta dettagliata :)

Avevo già eseguito nel frattempo dei test in SpatiaLite per vedere se
dovevo applicare le tue indicazioni lì o altrove risolvendo la
problematica. So già che la problematica mi si ripresenterà al prossimo
export ma ora so come affrontarla definitivamente.
Quando parlo di vettore intendo il dataset delle geometrie vettoriali(a
prescindere dalle primitive geometriche in esse contenute).

Il giorno 24 febbraio 2018 20:33,  ha scritto:

> On Sat, 24 Feb 2018 19:01:46 +0100, Massimiliano Moraca wrote:
>
>> Buonasera a tutti, vi scrivo dopo un po' per aggiornarvi.
>> Senza fare alcuna modifica al db esportato da PostGIS ed usando un
>> semplice
>> drag in QGIS tutti i layer vengono correttamente letti. Il problema
>> nasce però dopo un po', infatti per non so quale motivo saltano tematismi
>> ad esempio. Ho quindi seguito le indicazioni di Alessandro Furieri in
>> questo modo:
>>
>> - per prima cosa occorre verificare cosa contiene
>>
>>>   esattamente il dataset; basta eseguire la seguente
>>>   query SQL:
>>> SELECT Count(*), GeometryType(geom), Srid(geom), CoordDimension(geom)
>>> FROM table
>>> GROUP BY 2, 3, 4;
>>>
>>
>>
>> A seguito di questa verifica in SpatiaLite mi sono ritrovato con alcune
>> tabelle che erano multi geometrie ma che almeno non mischiavano le
>> tipologie di geometrie. Ho ad esempio Polygon e MultiPolygon. Quindi mi
>> trovo nel caso 2:
>>
>>   
>>
>> Non mi è chiaro però se le procedure indicate devono essere svolte in
>> PostGIS pre esportazione o in SpatiaLite post esportazione. Qualcuno può
>> chiarirmi questo punto?
>>
>>
> ciao Massimiliano,
>
> la procedura di cui al caso 2) la devi eseguire su SpatiaLite.
>
>
> Un'altra cosa che non mi è chiara, e l'ho verificata anche in PostGIS: come
>> è possibile che da una intersezione di due vettori MultiPolygon ne venga
>> fuori uno che è sia Polygon che MultiPolygon?
>>
>>
> risposta rapida:
> 
> il risultato dell'intersezione tra due (o piu') poligoni dipende tutto da
> come si relazionano le figure; a seconda dei casi potresti avere un POINT
> (le due figure si toccano su un unico vertice), un LINESTRING (le due
> figure si toccano solo lungo un lato), oppure un POLYGON (esiste una vera
> e propria intersezione).
> piu' ovviamente tutte le combinazioni in salsa "multi" tra i casi
> precedenti;
> non esiste regola, dipende tutto caso per caso.
>
>
> risposta ragionata:
> ---
> cerchiamo per prima cosa di sgombrare il campo da eventuali equivoci sulla
> terminologia; immagino che quando tu dici "vettore" intendi dire "dataset
> contenente geometrie vettoriali", vero ? che quindi secondo la terminologia
> SQL corrisponde ad una Spatial Table.
>
> giusto un richiamo veloce al data-model OGC-SFS per il data-type GEOMETRY:
> - esistono 3 classi "semplici" (single-part, capaci di rappresentare un
> unico
>   oggetto geometrico) che sono POINT, LINESTRING e POLYGON.
> - poi esistono 4 classi "collection" (multi-part, con la possibilita di
>   contenere contemporaneamente piu' oggetti geometrici di tipo semplice)
>   che sono MULTIPOINT, MULTILINESTRING, MULTIPOLYGON e GEOMETRYCOLLECTION.
>   nei primi tre casi tutti i  membri della collection devono essere del
>   medesimo tipo; nell'ultimo caso possono essere di qulunque tipo senza
>   restrizioni di sorta.
>
> nota: qualsiasi collection puo' contenere un numero arbitrario di elementi
> a partire da uno.
>
> corollario: un oggetto "semplice" come p.es. un POLYGON secondo il modello
> canonico OGC-SFS si puo' legittimamente rappresentare anche sotto forma
> di MULTIPOLYGON e persino di GEOMETRYCOLLECTION.
> dato che questo apre una potenziale ambiguita', e' ovvio che in questo caso
> occorre assegnare esplicitamente il Geom-Type desiderato.
> purtroppo in molti casi non e' possibile determinare a priori il geom-type
> del risultato atteso, e quindi molte librerie lo determinano basandosi
> esclusivamente sul conteggio degli oggetti elementari.
> quindi se trovano un unico POLYGON concludono che tutta quanta la Geometry
> nel suo complesso sia un POLYGON, senza prendere in considerazione che
> invece ci si attendeva un MULTIPOLYGON.
>
> SpatiaLite offre un metodo molto semplice ed efficare per aggirare il
> problema; le funzioni di casting.
> p.es. la CastToMultiPolygon() e' in grado di trasformare "al volo" un
> POLYGON in un MULTIPOLYGON. sarebbe sempre opportuno applicare il
> casting piu' appropriato prima di provare ad inserire una Geometry
> in una Spatial Table, proprio per evitare pasticci come questi di
> cui stiamo parlando, ma e' ovvio che da qualche parte questa buona
> regola non viene applicata.
>
> ultima puntualizzazione per chiarire definitivamente il quadro.
> SpatiaLite segue alla lettera le specifiche OGC-SFS, cosa che
> per vari motivi non avviene invece in altri Spatial DBMS ed
> applicazioni GIS.
> (e quando dico che "segue 

Re: [Gfoss] Export PostGIS - SpatiaLITE

[a . furieri]

On Sat, 24 Feb 2018 19:01:46 +0100, Massimiliano Moraca wrote:

Buonasera a tutti, vi scrivo dopo un po' per aggiornarvi.
Senza fare alcuna modifica al db esportato da PostGIS ed usando un 
semplice
drag in QGIS tutti i layer vengono correttamente letti. Il 
problema
nasce però dopo un po', infatti per non so quale motivo saltano 
tematismi

ad esempio. Ho quindi seguito le indicazioni di Alessandro Furieri in
questo modo:

- per prima cosa occorre verificare cosa contiene

  esattamente il dataset; basta eseguire la seguente
  query SQL:
SELECT Count(*), GeometryType(geom), Srid(geom), 
CoordDimension(geom)

FROM table
GROUP BY 2, 3, 4;



A seguito di questa verifica in SpatiaLite mi sono ritrovato con 
alcune

tabelle che erano multi geometrie ma che almeno non mischiavano le
tipologie di geometrie. Ho ad esempio Polygon e MultiPolygon. Quindi 
mi

trovo nel caso 2:

  

Non mi è chiaro però se le procedure indicate devono essere svolte in
PostGIS pre esportazione o in SpatiaLite post esportazione. Qualcuno 
può

chiarirmi questo punto?



ciao Massimiliano,

la procedura di cui al caso 2) la devi eseguire su SpatiaLite.


Un'altra cosa che non mi è chiara, e l'ho verificata anche in 
PostGIS: come
è possibile che da una intersezione di due vettori MultiPolygon ne 
venga

fuori uno che è sia Polygon che MultiPolygon?



risposta rapida:

il risultato dell'intersezione tra due (o piu') poligoni dipende tutto 
da
come si relazionano le figure; a seconda dei casi potresti avere un 
POINT

(le due figure si toccano su un unico vertice), un LINESTRING (le due
figure si toccano solo lungo un lato), oppure un POLYGON (esiste una 
vera

e propria intersezione).
piu' ovviamente tutte le combinazioni in salsa "multi" tra i casi 
precedenti;

non esiste regola, dipende tutto caso per caso.


risposta ragionata:
---
cerchiamo per prima cosa di sgombrare il campo da eventuali equivoci 
sulla
terminologia; immagino che quando tu dici "vettore" intendi dire 
"dataset
contenente geometrie vettoriali", vero ? che quindi secondo la 
terminologia

SQL corrisponde ad una Spatial Table.

giusto un richiamo veloce al data-model OGC-SFS per il data-type 
GEOMETRY:
- esistono 3 classi "semplici" (single-part, capaci di rappresentare un 
unico

  oggetto geometrico) che sono POINT, LINESTRING e POLYGON.
- poi esistono 4 classi "collection" (multi-part, con la possibilita di
  contenere contemporaneamente piu' oggetti geometrici di tipo 
semplice)
  che sono MULTIPOINT, MULTILINESTRING, MULTIPOLYGON e 
GEOMETRYCOLLECTION.

  nei primi tre casi tutti i  membri della collection devono essere del
  medesimo tipo; nell'ultimo caso possono essere di qulunque tipo senza
  restrizioni di sorta.

nota: qualsiasi collection puo' contenere un numero arbitrario di 
elementi

a partire da uno.

corollario: un oggetto "semplice" come p.es. un POLYGON secondo il 
modello

canonico OGC-SFS si puo' legittimamente rappresentare anche sotto forma
di MULTIPOLYGON e persino di GEOMETRYCOLLECTION.
dato che questo apre una potenziale ambiguita', e' ovvio che in questo 
caso

occorre assegnare esplicitamente il Geom-Type desiderato.
purtroppo in molti casi non e' possibile determinare a priori il 
geom-type

del risultato atteso, e quindi molte librerie lo determinano basandosi
esclusivamente sul conteggio degli oggetti elementari.
quindi se trovano un unico POLYGON concludono che tutta quanta la 
Geometry

nel suo complesso sia un POLYGON, senza prendere in considerazione che
invece ci si attendeva un MULTIPOLYGON.

SpatiaLite offre un metodo molto semplice ed efficare per aggirare il
problema; le funzioni di casting.
p.es. la CastToMultiPolygon() e' in grado di trasformare "al volo" un
POLYGON in un MULTIPOLYGON. sarebbe sempre opportuno applicare il
casting piu' appropriato prima di provare ad inserire una Geometry
in una Spatial Table, proprio per evitare pasticci come questi di
cui stiamo parlando, ma e' ovvio che da qualche parte questa buona
regola non viene applicata.

ultima puntualizzazione per chiarire definitivamente il quadro.
SpatiaLite segue alla lettera le specifiche OGC-SFS, cosa che
per vari motivi non avviene invece in altri Spatial DBMS ed
applicazioni GIS.
(e quando dico che "segue alla lettera" intendo dire che non solo
e' conforme alle ultime specifiche che definiscono lo standard,
ma che l'implementazione e' stata verificata ed approvata dai
tecnici della stessa OGC al tempo del comitato che defini' la
prima bozza dello standard GPKG - GeoPackage).

le specifiche OGC impongono che tutte le Geometrie contenute nella
medesima colonna di un qualsiasi Spatial Table _DEVONO_ avere
esattamente lo stesso Geom-Type, e che questo deve coincidere
col valore dichirato nella meta-tavola "geometry_column".
SpatiaLite e' molto pignola su questo: se una Spatial Table
e' definita come MULTIPOLYGON l'inserimento di una geometria
POLYGON viene respinto perche' e' 

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Massimiliano Moraca]

Mi rispondo da solo dicendo che devo applicare il tutto nel post
esportazione in SpatiaLite.

A questa però non sono arrivato...

Un'altra cosa che non mi è chiara, e l'ho verificata anche in PostGIS: come
> è possibile che da una intersezione di due vettori MultiPolygon ne venga
> fuori uno che è sia Polygon che MultiPolygon? E' il caso della
> cuas09_select che ho intersecato con il vettore ambito; entrambi i dati li
> trovate nel db che ho condiviso qualche settimana fa e che ricondivido qui:
> https://drive.google.com/open?id=1WGJuUutyBO3_wqkQkth-flQTn5E-CAFe



Il giorno 24 febbraio 2018 19:01, Massimiliano Moraca <
massimilianomor...@gmail.com> ha scritto:

> Buonasera a tutti, vi scrivo dopo un po' per aggiornarvi.
> Senza fare alcuna modifica al db esportato da PostGIS ed usando un
> semplice drag in QGIS tutti i layer vengono correttamente letti. Il
> problema nasce però dopo un po', infatti per non so quale motivo saltano
> tematismi ad esempio. Ho quindi seguito le indicazioni di Alessandro
> Furieri in questo modo:
>
> - per prima cosa occorre verificare cosa contiene
>>   esattamente il dataset; basta eseguire la seguente
>>   query SQL:
>> SELECT Count(*), GeometryType(geom), Srid(geom), CoordDimension(geom)
>> FROM table
>> GROUP BY 2, 3, 4;
>
>
> A seguito di questa verifica in SpatiaLite mi sono ritrovato con alcune
> tabelle che erano multi geometrie ma che almeno non mischiavano le
> tipologie di geometrie. Ho ad esempio Polygon e MultiPolygon. Quindi mi
> trovo nel caso 2:
>
> caso #2
>> ===
>> nel resultset appaiono un paio di righe, ma
>> tutte con il medesimo modello dimensionale e
>> con tipi geometrici compatibili, uno di tipo
>> single-part e l'altro di tipo multi-part
>> (p.es. POINT e MULTIPOINT, oppure POLYGON
>> e MULTIPOLYGON).
>> a questo punto occorre creare la seconda
>> colonna-geometria stando ben attenti a
>> specificare il MultiType:
>> SELECT AddGeometryColumn('table', 'geom2', srid, 'MULTIPOLYGON', 'XY');
>> infine si procede al popolamento della
>> seconda colonna-geometria applicando un
>> opportuno operatore di cast, tale da
>> forzare il geometry-type per uniformare
>> tutte le geometrie al caso multi-part:
>> UPDATE table SET geom2 = CastToMultiPolygon(geom);
>
>
> Non mi è chiaro però se le procedure indicate devono essere svolte in
> PostGIS pre esportazione o in SpatiaLite post esportazione. Qualcuno può
> chiarirmi questo punto?
>
> Un'altra cosa che non mi è chiara, e l'ho verificata anche in PostGIS:
> come è possibile che da una intersezione di due vettori MultiPolygon ne
> venga fuori uno che è sia Polygon che MultiPolygon? E' il caso della
> cuas09_select che ho intersecato con il vettore ambito; entrambi i dati li
> trovate nel db che ho condiviso qualche settimana fa e che ricondivido qui:
> https://drive.google.com/open?id=1WGJuUutyBO3_wqkQkth-flQTn5E-CAFe
>
> Il giorno 7 febbraio 2018 22:33, Andrea Peri  ha
> scritto:
>
>> Infatti.
>> Il drag-drop usa il driver gdal ma lo usa in modo semplificato.
>> La piu' grande differenza che io ho riscontrato e' quando ho una tabella
>> con piu' campi geometrici.
>> Il driver spatialite le intercetta tutte e le distingue. Ovvero ti mostra
>> la lista con tutti i campi geometrici tra cui scegliere.
>> Il dragndrop analizza la tabella e si colloca sul primo campo geometrico
>> che incontra.
>>
>> Altra differenza. Il driver spatialite controlla se le statistiche della
>> tabella sono riempite e se rileva che non sono valorizzate le valorizza
>> prima di usare la geometria.
>> Questo a volte provoca dei ritardi di reazione, ma solo la prima volta,
>> poi e' piu' veloce e le statistiche aiutano.
>>
>> Il driver drag-drop ignora la cosa. Se sono presenti bene, altrimenti
>> ciccia.
>>
>> A.
>>
>>
>> Il giorno 7 febbraio 2018 21:51, Totò Fiandaca > > ha scritto:
>>
>>> controlla bene, la tabella comuni_ambito che aveva inizialmente 23
>>> righe, dopo dragAndDrop risultano 22.
>>>
>>> meglio seguire la procedura descritta e non usare il dragAndDrop che,
>>> credo, non passi per ogr.
>>>
>>> notte
>>>
>>> Il giorno 7 febbraio 2018 21:45, Massimiliano Moraca <
>>> massimilianomor...@gmail.com> ha scritto:
>>>
 Salvatore ho fatto come hai indicato ed effettivamente vengono caricati
 tutti i layer in maniera corretta(perchè dici che spariscono le geometrie,
 a me sono comparse tutte). Quindi potrei bypassare il problema facendo
 così? O devo per forza seguire le procedure che sono state indicate nei
 vari interventi?
 Alla fine ho effettuato questa esportazione per comodità(devo portarmi
 appresso solo due file: progetto qgis e db al posto dei tanti shp) di
 esportazione in questa fase di raccolta dati; poi tutto sarà a dimora su
 PostGIS.

 Il giorno 7 febbraio 2018 21:36, Totò Fiandaca <
 pigrecoinfin...@gmail.com> ha scritto:

> aggiungo, solo ai fini di aver un quadro più completo, che aggiungendo

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Massimiliano Moraca]

Buonasera a tutti, vi scrivo dopo un po' per aggiornarvi.
Senza fare alcuna modifica al db esportato da PostGIS ed usando un semplice
drag in QGIS tutti i layer vengono correttamente letti. Il problema
nasce però dopo un po', infatti per non so quale motivo saltano tematismi
ad esempio. Ho quindi seguito le indicazioni di Alessandro Furieri in
questo modo:

- per prima cosa occorre verificare cosa contiene
>   esattamente il dataset; basta eseguire la seguente
>   query SQL:
> SELECT Count(*), GeometryType(geom), Srid(geom), CoordDimension(geom)
> FROM table
> GROUP BY 2, 3, 4;


A seguito di questa verifica in SpatiaLite mi sono ritrovato con alcune
tabelle che erano multi geometrie ma che almeno non mischiavano le
tipologie di geometrie. Ho ad esempio Polygon e MultiPolygon. Quindi mi
trovo nel caso 2:

caso #2
> ===
> nel resultset appaiono un paio di righe, ma
> tutte con il medesimo modello dimensionale e
> con tipi geometrici compatibili, uno di tipo
> single-part e l'altro di tipo multi-part
> (p.es. POINT e MULTIPOINT, oppure POLYGON
> e MULTIPOLYGON).
> a questo punto occorre creare la seconda
> colonna-geometria stando ben attenti a
> specificare il MultiType:
> SELECT AddGeometryColumn('table', 'geom2', srid, 'MULTIPOLYGON', 'XY');
> infine si procede al popolamento della
> seconda colonna-geometria applicando un
> opportuno operatore di cast, tale da
> forzare il geometry-type per uniformare
> tutte le geometrie al caso multi-part:
> UPDATE table SET geom2 = CastToMultiPolygon(geom);


Non mi è chiaro però se le procedure indicate devono essere svolte in
PostGIS pre esportazione o in SpatiaLite post esportazione. Qualcuno può
chiarirmi questo punto?

Un'altra cosa che non mi è chiara, e l'ho verificata anche in PostGIS: come
è possibile che da una intersezione di due vettori MultiPolygon ne venga
fuori uno che è sia Polygon che MultiPolygon? E' il caso della
cuas09_select che ho intersecato con il vettore ambito; entrambi i dati li
trovate nel db che ho condiviso qualche settimana fa e che ricondivido qui:
https://drive.google.com/open?id=1WGJuUutyBO3_wqkQkth-flQTn5E-CAFe

Il giorno 7 febbraio 2018 22:33, Andrea Peri  ha
scritto:

> Infatti.
> Il drag-drop usa il driver gdal ma lo usa in modo semplificato.
> La piu' grande differenza che io ho riscontrato e' quando ho una tabella
> con piu' campi geometrici.
> Il driver spatialite le intercetta tutte e le distingue. Ovvero ti mostra
> la lista con tutti i campi geometrici tra cui scegliere.
> Il dragndrop analizza la tabella e si colloca sul primo campo geometrico
> che incontra.
>
> Altra differenza. Il driver spatialite controlla se le statistiche della
> tabella sono riempite e se rileva che non sono valorizzate le valorizza
> prima di usare la geometria.
> Questo a volte provoca dei ritardi di reazione, ma solo la prima volta,
> poi e' piu' veloce e le statistiche aiutano.
>
> Il driver drag-drop ignora la cosa. Se sono presenti bene, altrimenti
> ciccia.
>
> A.
>
>
> Il giorno 7 febbraio 2018 21:51, Totò Fiandaca 
> ha scritto:
>
>> controlla bene, la tabella comuni_ambito che aveva inizialmente 23 righe,
>> dopo dragAndDrop risultano 22.
>>
>> meglio seguire la procedura descritta e non usare il dragAndDrop che,
>> credo, non passi per ogr.
>>
>> notte
>>
>> Il giorno 7 febbraio 2018 21:45, Massimiliano Moraca <
>> massimilianomor...@gmail.com> ha scritto:
>>
>>> Salvatore ho fatto come hai indicato ed effettivamente vengono caricati
>>> tutti i layer in maniera corretta(perchè dici che spariscono le geometrie,
>>> a me sono comparse tutte). Quindi potrei bypassare il problema facendo
>>> così? O devo per forza seguire le procedure che sono state indicate nei
>>> vari interventi?
>>> Alla fine ho effettuato questa esportazione per comodità(devo portarmi
>>> appresso solo due file: progetto qgis e db al posto dei tanti shp) di
>>> esportazione in questa fase di raccolta dati; poi tutto sarà a dimora su
>>> PostGIS.
>>>
>>> Il giorno 7 febbraio 2018 21:36, Totò Fiandaca <
>>> pigrecoinfin...@gmail.com> ha scritto:
>>>
 aggiungo, solo ai fini di aver un quadro più completo, che aggiungendo
 il database spatialite (creato con la procedura esposta in questo thread)
 non con il provider spatialite ma con il dragAndDrop tutte le tabelle
 vengono lette da QGIS; alcune stranezze riscontrate: scomparsa di poligoni;
 geometrie definite multipoligono vengono lette come poligoni.

 notte

 Il giorno 7 febbraio 2018 21:25, Massimiliano Moraca <
 massimilianomor...@gmail.com> ha scritto:

> Grazie a tutti per le risposte.
> Ancora non ho avuto modo di applicare le indicazioni che mi avete
> dato, spero di farlo questo fine settimana. Vi tengo aggiornati.
>
> Il giorno 7 febbraio 2018 18:48, Andrea Peri  ha
> scritto:
>
>> Grazie a te che scrivendo articoli crei una base di letture da cui un
>> 

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Andrea Peri]

 Infatti.
Il drag-drop usa il driver gdal ma lo usa in modo semplificato.
La piu' grande differenza che io ho riscontrato e' quando ho una tabella
con piu' campi geometrici.
Il driver spatialite le intercetta tutte e le distingue. Ovvero ti mostra
la lista con tutti i campi geometrici tra cui scegliere.
Il dragndrop analizza la tabella e si colloca sul primo campo geometrico
che incontra.

Altra differenza. Il driver spatialite controlla se le statistiche della
tabella sono riempite e se rileva che non sono valorizzate le valorizza
prima di usare la geometria.
Questo a volte provoca dei ritardi di reazione, ma solo la prima volta, poi
e' piu' veloce e le statistiche aiutano.

Il driver drag-drop ignora la cosa. Se sono presenti bene, altrimenti
ciccia.

A.


Il giorno 7 febbraio 2018 21:51, Totò Fiandaca 
ha scritto:

> controlla bene, la tabella comuni_ambito che aveva inizialmente 23 righe,
> dopo dragAndDrop risultano 22.
>
> meglio seguire la procedura descritta e non usare il dragAndDrop che,
> credo, non passi per ogr.
>
> notte
>
> Il giorno 7 febbraio 2018 21:45, Massimiliano Moraca <
> massimilianomor...@gmail.com> ha scritto:
>
>> Salvatore ho fatto come hai indicato ed effettivamente vengono caricati
>> tutti i layer in maniera corretta(perchè dici che spariscono le geometrie,
>> a me sono comparse tutte). Quindi potrei bypassare il problema facendo
>> così? O devo per forza seguire le procedure che sono state indicate nei
>> vari interventi?
>> Alla fine ho effettuato questa esportazione per comodità(devo portarmi
>> appresso solo due file: progetto qgis e db al posto dei tanti shp) di
>> esportazione in questa fase di raccolta dati; poi tutto sarà a dimora su
>> PostGIS.
>>
>> Il giorno 7 febbraio 2018 21:36, Totò Fiandaca > > ha scritto:
>>
>>> aggiungo, solo ai fini di aver un quadro più completo, che aggiungendo
>>> il database spatialite (creato con la procedura esposta in questo thread)
>>> non con il provider spatialite ma con il dragAndDrop tutte le tabelle
>>> vengono lette da QGIS; alcune stranezze riscontrate: scomparsa di poligoni;
>>> geometrie definite multipoligono vengono lette come poligoni.
>>>
>>> notte
>>>
>>> Il giorno 7 febbraio 2018 21:25, Massimiliano Moraca <
>>> massimilianomor...@gmail.com> ha scritto:
>>>
 Grazie a tutti per le risposte.
 Ancora non ho avuto modo di applicare le indicazioni che mi avete dato,
 spero di farlo questo fine settimana. Vi tengo aggiornati.

 Il giorno 7 febbraio 2018 18:48, Andrea Peri  ha
 scritto:

> Grazie a te che scrivendo articoli crei una base di letture da cui un
> nuovo
> utente può partire per navigare in questo complicato universo.
>
> Il 07 Feb 2018 18:25, "Totò Fiandaca"  ha
> scritto:
>
> > Vorrei esprimere la mia gratitudine a Andrea Peri e Alessandro
> Furieri per
> > le spiegazioni, chiare ed efficaci.
> >
> > Ho fatto delle prove sul db messo a disposizione da Massimiliano,
> seguendo
> > i consigli di Furieri, tutto funziona alla perfezione.
> >
> > grazie
> >
> > forse scriverò un articolo su questo thread.
> >
> > saluti
> >
> >
> >
> >
> > Il giorno 7 febbraio 2018 12:53,  ha scritto:
> >
> > > On Wed, 7 Feb 2018 12:06:06 +0100, Totò Fiandaca wrote:
> > >
> > >> correggetemi se dico fesserie:
> > >>
> > >> una soluzione sarebbe quella di aggiungere un altro campo
> geometry (es:
> > >> geom, definirlo per bene) alle tabelle e popolarle con la
> geometria con
> > un
> > >> UPDATE.
> > >>
> > >> credo funzioni.
> > >>
> > >>
> > > si, dovrebbe funzionare, ma il percorso da seguire per
> > > fare un lavoro ben fatto e' un po' piu' complesso:
> > >
> > > - per prima cosa occorre verificare cosa contiene
> > >   esattamente il dataset; basta eseguire la seguente
> > >   query SQL:
> > >
> > > SELECT Count(*), GeometryType(geom), Srid(geom),
> CoordDimension(geom)
> > > FROM table
> > > GROUP BY 2, 3, 4;
> > >
> > > n.b. chi usa spatialite_gui puo' usare direttamente
> > > il tool "check geometries" dal menu associato a quella
> > > particolare colonna-geometria.
> > >
> > > - a questo punto tutto dipende dai risultati della
> > >   query precedente.
> > >
> > > caso #1
> > > ===
> > > nel resultset appare una singola riga.
> > > basta creare la seconda colonna-geometria con gli
> > > argomenti appropriati, p.es.
> > >
> > > SELECT AddGeometryColumn('table', 'geom2', srid, 'POINT', 'XY');
> > >
> > > a questo punto si procede direttamente al popolamento
> > > della nuova colonna-geometria:
> > >
> > > UPDATE table SET geom2 = geom;
> > >
> > >
> > > caso #2
> > > 

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Massimiliano Moraca]

Ho capito a che fai riferimento! In quella tabella c'erano 23 righe in
origine poi ho tolto quella con pkca 14 e non ho aggiornato il field. Me ne
ritrovo 22 anche in da PgAdmin :)

Comunque appena ho un po' più di tempo e lucidità mentale eseguo le
procedure che mi avete indicato e vedo che ne viene fuori. Ancora grazie e
buona serata a tutti

Il giorno 7 febbraio 2018 21:51, Totò Fiandaca 
ha scritto:

> controlla bene, la tabella comuni_ambito che aveva inizialmente 23 righe,
> dopo dragAndDrop risultano 22.
>
> meglio seguire la procedura descritta e non usare il dragAndDrop che,
> credo, non passi per ogr.
>
> notte
>
> Il giorno 7 febbraio 2018 21:45, Massimiliano Moraca <
> massimilianomor...@gmail.com> ha scritto:
>
>> Salvatore ho fatto come hai indicato ed effettivamente vengono caricati
>> tutti i layer in maniera corretta(perchè dici che spariscono le geometrie,
>> a me sono comparse tutte). Quindi potrei bypassare il problema facendo
>> così? O devo per forza seguire le procedure che sono state indicate nei
>> vari interventi?
>> Alla fine ho effettuato questa esportazione per comodità(devo portarmi
>> appresso solo due file: progetto qgis e db al posto dei tanti shp) di
>> esportazione in questa fase di raccolta dati; poi tutto sarà a dimora su
>> PostGIS.
>>
>> Il giorno 7 febbraio 2018 21:36, Totò Fiandaca > > ha scritto:
>>
>>> aggiungo, solo ai fini di aver un quadro più completo, che aggiungendo
>>> il database spatialite (creato con la procedura esposta in questo thread)
>>> non con il provider spatialite ma con il dragAndDrop tutte le tabelle
>>> vengono lette da QGIS; alcune stranezze riscontrate: scomparsa di poligoni;
>>> geometrie definite multipoligono vengono lette come poligoni.
>>>
>>> notte
>>>
>>> Il giorno 7 febbraio 2018 21:25, Massimiliano Moraca <
>>> massimilianomor...@gmail.com> ha scritto:
>>>
 Grazie a tutti per le risposte.
 Ancora non ho avuto modo di applicare le indicazioni che mi avete dato,
 spero di farlo questo fine settimana. Vi tengo aggiornati.

 Il giorno 7 febbraio 2018 18:48, Andrea Peri  ha
 scritto:

> Grazie a te che scrivendo articoli crei una base di letture da cui un
> nuovo
> utente può partire per navigare in questo complicato universo.
>
> Il 07 Feb 2018 18:25, "Totò Fiandaca"  ha
> scritto:
>
> > Vorrei esprimere la mia gratitudine a Andrea Peri e Alessandro
> Furieri per
> > le spiegazioni, chiare ed efficaci.
> >
> > Ho fatto delle prove sul db messo a disposizione da Massimiliano,
> seguendo
> > i consigli di Furieri, tutto funziona alla perfezione.
> >
> > grazie
> >
> > forse scriverò un articolo su questo thread.
> >
> > saluti
> >
> >
> >
> >
> > Il giorno 7 febbraio 2018 12:53,  ha scritto:
> >
> > > On Wed, 7 Feb 2018 12:06:06 +0100, Totò Fiandaca wrote:
> > >
> > >> correggetemi se dico fesserie:
> > >>
> > >> una soluzione sarebbe quella di aggiungere un altro campo
> geometry (es:
> > >> geom, definirlo per bene) alle tabelle e popolarle con la
> geometria con
> > un
> > >> UPDATE.
> > >>
> > >> credo funzioni.
> > >>
> > >>
> > > si, dovrebbe funzionare, ma il percorso da seguire per
> > > fare un lavoro ben fatto e' un po' piu' complesso:
> > >
> > > - per prima cosa occorre verificare cosa contiene
> > >   esattamente il dataset; basta eseguire la seguente
> > >   query SQL:
> > >
> > > SELECT Count(*), GeometryType(geom), Srid(geom),
> CoordDimension(geom)
> > > FROM table
> > > GROUP BY 2, 3, 4;
> > >
> > > n.b. chi usa spatialite_gui puo' usare direttamente
> > > il tool "check geometries" dal menu associato a quella
> > > particolare colonna-geometria.
> > >
> > > - a questo punto tutto dipende dai risultati della
> > >   query precedente.
> > >
> > > caso #1
> > > ===
> > > nel resultset appare una singola riga.
> > > basta creare la seconda colonna-geometria con gli
> > > argomenti appropriati, p.es.
> > >
> > > SELECT AddGeometryColumn('table', 'geom2', srid, 'POINT', 'XY');
> > >
> > > a questo punto si procede direttamente al popolamento
> > > della nuova colonna-geometria:
> > >
> > > UPDATE table SET geom2 = geom;
> > >
> > >
> > > caso #2
> > > ===
> > > nel resultset appaiono un paio di righe, ma
> > > tutte con il medesimo modello dimensionale e
> > > con tipi geometrici compatibili, uno di tipo
> > > single-part e l'altro di tipo multi-part
> > > (p.es. POINT e MULTIPOINT, oppure POLYGON
> > > e MULTIPOLYGON).
> > >
> > > a questo punto occorre creare la seconda
> > > colonna-geometria stando ben attenti a
> > 

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Totò Fiandaca]

controlla bene, la tabella comuni_ambito che aveva inizialmente 23 righe,
dopo dragAndDrop risultano 22.

meglio seguire la procedura descritta e non usare il dragAndDrop che,
credo, non passi per ogr.

notte

Il giorno 7 febbraio 2018 21:45, Massimiliano Moraca <
massimilianomor...@gmail.com> ha scritto:

> Salvatore ho fatto come hai indicato ed effettivamente vengono caricati
> tutti i layer in maniera corretta(perchè dici che spariscono le geometrie,
> a me sono comparse tutte). Quindi potrei bypassare il problema facendo
> così? O devo per forza seguire le procedure che sono state indicate nei
> vari interventi?
> Alla fine ho effettuato questa esportazione per comodità(devo portarmi
> appresso solo due file: progetto qgis e db al posto dei tanti shp) di
> esportazione in questa fase di raccolta dati; poi tutto sarà a dimora su
> PostGIS.
>
> Il giorno 7 febbraio 2018 21:36, Totò Fiandaca 
> ha scritto:
>
>> aggiungo, solo ai fini di aver un quadro più completo, che aggiungendo il
>> database spatialite (creato con la procedura esposta in questo thread) non
>> con il provider spatialite ma con il dragAndDrop tutte le tabelle vengono
>> lette da QGIS; alcune stranezze riscontrate: scomparsa di poligoni;
>> geometrie definite multipoligono vengono lette come poligoni.
>>
>> notte
>>
>> Il giorno 7 febbraio 2018 21:25, Massimiliano Moraca <
>> massimilianomor...@gmail.com> ha scritto:
>>
>>> Grazie a tutti per le risposte.
>>> Ancora non ho avuto modo di applicare le indicazioni che mi avete dato,
>>> spero di farlo questo fine settimana. Vi tengo aggiornati.
>>>
>>> Il giorno 7 febbraio 2018 18:48, Andrea Peri  ha
>>> scritto:
>>>
 Grazie a te che scrivendo articoli crei una base di letture da cui un
 nuovo
 utente può partire per navigare in questo complicato universo.

 Il 07 Feb 2018 18:25, "Totò Fiandaca"  ha
 scritto:

 > Vorrei esprimere la mia gratitudine a Andrea Peri e Alessandro
 Furieri per
 > le spiegazioni, chiare ed efficaci.
 >
 > Ho fatto delle prove sul db messo a disposizione da Massimiliano,
 seguendo
 > i consigli di Furieri, tutto funziona alla perfezione.
 >
 > grazie
 >
 > forse scriverò un articolo su questo thread.
 >
 > saluti
 >
 >
 >
 >
 > Il giorno 7 febbraio 2018 12:53,  ha scritto:
 >
 > > On Wed, 7 Feb 2018 12:06:06 +0100, Totò Fiandaca wrote:
 > >
 > >> correggetemi se dico fesserie:
 > >>
 > >> una soluzione sarebbe quella di aggiungere un altro campo geometry
 (es:
 > >> geom, definirlo per bene) alle tabelle e popolarle con la
 geometria con
 > un
 > >> UPDATE.
 > >>
 > >> credo funzioni.
 > >>
 > >>
 > > si, dovrebbe funzionare, ma il percorso da seguire per
 > > fare un lavoro ben fatto e' un po' piu' complesso:
 > >
 > > - per prima cosa occorre verificare cosa contiene
 > >   esattamente il dataset; basta eseguire la seguente
 > >   query SQL:
 > >
 > > SELECT Count(*), GeometryType(geom), Srid(geom),
 CoordDimension(geom)
 > > FROM table
 > > GROUP BY 2, 3, 4;
 > >
 > > n.b. chi usa spatialite_gui puo' usare direttamente
 > > il tool "check geometries" dal menu associato a quella
 > > particolare colonna-geometria.
 > >
 > > - a questo punto tutto dipende dai risultati della
 > >   query precedente.
 > >
 > > caso #1
 > > ===
 > > nel resultset appare una singola riga.
 > > basta creare la seconda colonna-geometria con gli
 > > argomenti appropriati, p.es.
 > >
 > > SELECT AddGeometryColumn('table', 'geom2', srid, 'POINT', 'XY');
 > >
 > > a questo punto si procede direttamente al popolamento
 > > della nuova colonna-geometria:
 > >
 > > UPDATE table SET geom2 = geom;
 > >
 > >
 > > caso #2
 > > ===
 > > nel resultset appaiono un paio di righe, ma
 > > tutte con il medesimo modello dimensionale e
 > > con tipi geometrici compatibili, uno di tipo
 > > single-part e l'altro di tipo multi-part
 > > (p.es. POINT e MULTIPOINT, oppure POLYGON
 > > e MULTIPOLYGON).
 > >
 > > a questo punto occorre creare la seconda
 > > colonna-geometria stando ben attenti a
 > > specificare il MultiType:
 > >
 > > SELECT AddGeometryColumn('table', 'geom2', srid, 'MULTIPOLYGON',
 'XY');
 > >
 > > infine si procede al popolamento della
 > > seconda colonna-geometria applicando un
 > > opportuno operatore di cast, tale da
 > > forzare il geometry-type per uniformare
 > > tutte le geometrie al caso multi-part:
 > >
 > > UPDATE table SET geom2 = CastToMultiPolygon(geom);
 > >
 > >
 > > caso #3
 > > ===
 > > nel resultset appaiono svariate righe, con
 > > 

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Massimiliano Moraca]

Salvatore ho fatto come hai indicato ed effettivamente vengono caricati
tutti i layer in maniera corretta(perchè dici che spariscono le geometrie,
a me sono comparse tutte). Quindi potrei bypassare il problema facendo
così? O devo per forza seguire le procedure che sono state indicate nei
vari interventi?
Alla fine ho effettuato questa esportazione per comodità(devo portarmi
appresso solo due file: progetto qgis e db al posto dei tanti shp) di
esportazione in questa fase di raccolta dati; poi tutto sarà a dimora su
PostGIS.

Il giorno 7 febbraio 2018 21:36, Totò Fiandaca 
ha scritto:

> aggiungo, solo ai fini di aver un quadro più completo, che aggiungendo il
> database spatialite (creato con la procedura esposta in questo thread) non
> con il provider spatialite ma con il dragAndDrop tutte le tabelle vengono
> lette da QGIS; alcune stranezze riscontrate: scomparsa di poligoni;
> geometrie definite multipoligono vengono lette come poligoni.
>
> notte
>
> Il giorno 7 febbraio 2018 21:25, Massimiliano Moraca <
> massimilianomor...@gmail.com> ha scritto:
>
>> Grazie a tutti per le risposte.
>> Ancora non ho avuto modo di applicare le indicazioni che mi avete dato,
>> spero di farlo questo fine settimana. Vi tengo aggiornati.
>>
>> Il giorno 7 febbraio 2018 18:48, Andrea Peri  ha
>> scritto:
>>
>>> Grazie a te che scrivendo articoli crei una base di letture da cui un
>>> nuovo
>>> utente può partire per navigare in questo complicato universo.
>>>
>>> Il 07 Feb 2018 18:25, "Totò Fiandaca"  ha
>>> scritto:
>>>
>>> > Vorrei esprimere la mia gratitudine a Andrea Peri e Alessandro Furieri
>>> per
>>> > le spiegazioni, chiare ed efficaci.
>>> >
>>> > Ho fatto delle prove sul db messo a disposizione da Massimiliano,
>>> seguendo
>>> > i consigli di Furieri, tutto funziona alla perfezione.
>>> >
>>> > grazie
>>> >
>>> > forse scriverò un articolo su questo thread.
>>> >
>>> > saluti
>>> >
>>> >
>>> >
>>> >
>>> > Il giorno 7 febbraio 2018 12:53,  ha scritto:
>>> >
>>> > > On Wed, 7 Feb 2018 12:06:06 +0100, Totò Fiandaca wrote:
>>> > >
>>> > >> correggetemi se dico fesserie:
>>> > >>
>>> > >> una soluzione sarebbe quella di aggiungere un altro campo geometry
>>> (es:
>>> > >> geom, definirlo per bene) alle tabelle e popolarle con la geometria
>>> con
>>> > un
>>> > >> UPDATE.
>>> > >>
>>> > >> credo funzioni.
>>> > >>
>>> > >>
>>> > > si, dovrebbe funzionare, ma il percorso da seguire per
>>> > > fare un lavoro ben fatto e' un po' piu' complesso:
>>> > >
>>> > > - per prima cosa occorre verificare cosa contiene
>>> > >   esattamente il dataset; basta eseguire la seguente
>>> > >   query SQL:
>>> > >
>>> > > SELECT Count(*), GeometryType(geom), Srid(geom), CoordDimension(geom)
>>> > > FROM table
>>> > > GROUP BY 2, 3, 4;
>>> > >
>>> > > n.b. chi usa spatialite_gui puo' usare direttamente
>>> > > il tool "check geometries" dal menu associato a quella
>>> > > particolare colonna-geometria.
>>> > >
>>> > > - a questo punto tutto dipende dai risultati della
>>> > >   query precedente.
>>> > >
>>> > > caso #1
>>> > > ===
>>> > > nel resultset appare una singola riga.
>>> > > basta creare la seconda colonna-geometria con gli
>>> > > argomenti appropriati, p.es.
>>> > >
>>> > > SELECT AddGeometryColumn('table', 'geom2', srid, 'POINT', 'XY');
>>> > >
>>> > > a questo punto si procede direttamente al popolamento
>>> > > della nuova colonna-geometria:
>>> > >
>>> > > UPDATE table SET geom2 = geom;
>>> > >
>>> > >
>>> > > caso #2
>>> > > ===
>>> > > nel resultset appaiono un paio di righe, ma
>>> > > tutte con il medesimo modello dimensionale e
>>> > > con tipi geometrici compatibili, uno di tipo
>>> > > single-part e l'altro di tipo multi-part
>>> > > (p.es. POINT e MULTIPOINT, oppure POLYGON
>>> > > e MULTIPOLYGON).
>>> > >
>>> > > a questo punto occorre creare la seconda
>>> > > colonna-geometria stando ben attenti a
>>> > > specificare il MultiType:
>>> > >
>>> > > SELECT AddGeometryColumn('table', 'geom2', srid, 'MULTIPOLYGON',
>>> 'XY');
>>> > >
>>> > > infine si procede al popolamento della
>>> > > seconda colonna-geometria applicando un
>>> > > opportuno operatore di cast, tale da
>>> > > forzare il geometry-type per uniformare
>>> > > tutte le geometrie al caso multi-part:
>>> > >
>>> > > UPDATE table SET geom2 = CastToMultiPolygon(geom);
>>> > >
>>> > >
>>> > > caso #3
>>> > > ===
>>> > > nel resultset appaiono svariate righe, con
>>> > > geometry-type incompatibili (p.es. POINT,
>>> > > LINESTRING e MULTIPOLYGON).
>>> > >
>>> > > in questo caso non e' possibile procedere
>>> > > ad una conversione diretta, andranno create
>>> > > tante colonne-geometria quanti sono i
>>> > > geometry-types, e durante la fase di popolamento
>>> > > le geometrie andranno opportunamente filtrate
>>> > > in base al tipo.
>>> > >
>>> > > ciao Sandro
>>> > >
>>> > >
>>> > > poi, il provider spatialite di QGIS 

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Totò Fiandaca]

aggiungo, solo ai fini di aver un quadro più completo, che aggiungendo il
database spatialite (creato con la procedura esposta in questo thread) non
con il provider spatialite ma con il dragAndDrop tutte le tabelle vengono
lette da QGIS; alcune stranezze riscontrate: scomparsa di poligoni;
geometrie definite multipoligono vengono lette come poligoni.

notte

Il giorno 7 febbraio 2018 21:25, Massimiliano Moraca <
massimilianomor...@gmail.com> ha scritto:

> Grazie a tutti per le risposte.
> Ancora non ho avuto modo di applicare le indicazioni che mi avete dato,
> spero di farlo questo fine settimana. Vi tengo aggiornati.
>
> Il giorno 7 febbraio 2018 18:48, Andrea Peri  ha
> scritto:
>
>> Grazie a te che scrivendo articoli crei una base di letture da cui un
>> nuovo
>> utente può partire per navigare in questo complicato universo.
>>
>> Il 07 Feb 2018 18:25, "Totò Fiandaca"  ha
>> scritto:
>>
>> > Vorrei esprimere la mia gratitudine a Andrea Peri e Alessandro Furieri
>> per
>> > le spiegazioni, chiare ed efficaci.
>> >
>> > Ho fatto delle prove sul db messo a disposizione da Massimiliano,
>> seguendo
>> > i consigli di Furieri, tutto funziona alla perfezione.
>> >
>> > grazie
>> >
>> > forse scriverò un articolo su questo thread.
>> >
>> > saluti
>> >
>> >
>> >
>> >
>> > Il giorno 7 febbraio 2018 12:53,  ha scritto:
>> >
>> > > On Wed, 7 Feb 2018 12:06:06 +0100, Totò Fiandaca wrote:
>> > >
>> > >> correggetemi se dico fesserie:
>> > >>
>> > >> una soluzione sarebbe quella di aggiungere un altro campo geometry
>> (es:
>> > >> geom, definirlo per bene) alle tabelle e popolarle con la geometria
>> con
>> > un
>> > >> UPDATE.
>> > >>
>> > >> credo funzioni.
>> > >>
>> > >>
>> > > si, dovrebbe funzionare, ma il percorso da seguire per
>> > > fare un lavoro ben fatto e' un po' piu' complesso:
>> > >
>> > > - per prima cosa occorre verificare cosa contiene
>> > >   esattamente il dataset; basta eseguire la seguente
>> > >   query SQL:
>> > >
>> > > SELECT Count(*), GeometryType(geom), Srid(geom), CoordDimension(geom)
>> > > FROM table
>> > > GROUP BY 2, 3, 4;
>> > >
>> > > n.b. chi usa spatialite_gui puo' usare direttamente
>> > > il tool "check geometries" dal menu associato a quella
>> > > particolare colonna-geometria.
>> > >
>> > > - a questo punto tutto dipende dai risultati della
>> > >   query precedente.
>> > >
>> > > caso #1
>> > > ===
>> > > nel resultset appare una singola riga.
>> > > basta creare la seconda colonna-geometria con gli
>> > > argomenti appropriati, p.es.
>> > >
>> > > SELECT AddGeometryColumn('table', 'geom2', srid, 'POINT', 'XY');
>> > >
>> > > a questo punto si procede direttamente al popolamento
>> > > della nuova colonna-geometria:
>> > >
>> > > UPDATE table SET geom2 = geom;
>> > >
>> > >
>> > > caso #2
>> > > ===
>> > > nel resultset appaiono un paio di righe, ma
>> > > tutte con il medesimo modello dimensionale e
>> > > con tipi geometrici compatibili, uno di tipo
>> > > single-part e l'altro di tipo multi-part
>> > > (p.es. POINT e MULTIPOINT, oppure POLYGON
>> > > e MULTIPOLYGON).
>> > >
>> > > a questo punto occorre creare la seconda
>> > > colonna-geometria stando ben attenti a
>> > > specificare il MultiType:
>> > >
>> > > SELECT AddGeometryColumn('table', 'geom2', srid, 'MULTIPOLYGON',
>> 'XY');
>> > >
>> > > infine si procede al popolamento della
>> > > seconda colonna-geometria applicando un
>> > > opportuno operatore di cast, tale da
>> > > forzare il geometry-type per uniformare
>> > > tutte le geometrie al caso multi-part:
>> > >
>> > > UPDATE table SET geom2 = CastToMultiPolygon(geom);
>> > >
>> > >
>> > > caso #3
>> > > ===
>> > > nel resultset appaiono svariate righe, con
>> > > geometry-type incompatibili (p.es. POINT,
>> > > LINESTRING e MULTIPOLYGON).
>> > >
>> > > in questo caso non e' possibile procedere
>> > > ad una conversione diretta, andranno create
>> > > tante colonne-geometria quanti sono i
>> > > geometry-types, e durante la fase di popolamento
>> > > le geometrie andranno opportunamente filtrate
>> > > in base al tipo.
>> > >
>> > > ciao Sandro
>> > >
>> > >
>> > > poi, il provider spatialite di QGIS vedrebbe due colonne geometriche
>> > dello
>> > >> stesso strato.
>> > >>
>> > >> ___
>> > > Gfoss@lists.gfoss.it
>> > > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>> > > Questa e' una lista di discussione pubblica aperta a tutti.
>> > > I messaggi di questa lista non hanno relazione diretta con le
>> posizioni
>> > > dell'Associazione GFOSS.it.
>> > > 796 iscritti al 28/12/2017
>> > >
>> >
>> >
>> >
>> > --
>> > *Ing. Salvatore Fiandaca*
>> > *mobile*.:+39 327.493.8955
>> > *m*: *pigrecoinfin...@gmail.com *
>> > *C.F*.: FNDSVT71E29Z103G
>> > *P.IVA*: 06597870820
>> > *membro QGIS Italia - http://qgis.it/ *
>> > *socio GFOSS.it - *http://gfoss.it/
>> > 

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Andrea Peri]

Grazie a te che scrivendo articoli crei una base di letture da cui un nuovo
utente può partire per navigare in questo complicato universo.

Il 07 Feb 2018 18:25, "Totò Fiandaca"  ha
scritto:

> Vorrei esprimere la mia gratitudine a Andrea Peri e Alessandro Furieri per
> le spiegazioni, chiare ed efficaci.
>
> Ho fatto delle prove sul db messo a disposizione da Massimiliano, seguendo
> i consigli di Furieri, tutto funziona alla perfezione.
>
> grazie
>
> forse scriverò un articolo su questo thread.
>
> saluti
>
>
>
>
> Il giorno 7 febbraio 2018 12:53,  ha scritto:
>
> > On Wed, 7 Feb 2018 12:06:06 +0100, Totò Fiandaca wrote:
> >
> >> correggetemi se dico fesserie:
> >>
> >> una soluzione sarebbe quella di aggiungere un altro campo geometry (es:
> >> geom, definirlo per bene) alle tabelle e popolarle con la geometria con
> un
> >> UPDATE.
> >>
> >> credo funzioni.
> >>
> >>
> > si, dovrebbe funzionare, ma il percorso da seguire per
> > fare un lavoro ben fatto e' un po' piu' complesso:
> >
> > - per prima cosa occorre verificare cosa contiene
> >   esattamente il dataset; basta eseguire la seguente
> >   query SQL:
> >
> > SELECT Count(*), GeometryType(geom), Srid(geom), CoordDimension(geom)
> > FROM table
> > GROUP BY 2, 3, 4;
> >
> > n.b. chi usa spatialite_gui puo' usare direttamente
> > il tool "check geometries" dal menu associato a quella
> > particolare colonna-geometria.
> >
> > - a questo punto tutto dipende dai risultati della
> >   query precedente.
> >
> > caso #1
> > ===
> > nel resultset appare una singola riga.
> > basta creare la seconda colonna-geometria con gli
> > argomenti appropriati, p.es.
> >
> > SELECT AddGeometryColumn('table', 'geom2', srid, 'POINT', 'XY');
> >
> > a questo punto si procede direttamente al popolamento
> > della nuova colonna-geometria:
> >
> > UPDATE table SET geom2 = geom;
> >
> >
> > caso #2
> > ===
> > nel resultset appaiono un paio di righe, ma
> > tutte con il medesimo modello dimensionale e
> > con tipi geometrici compatibili, uno di tipo
> > single-part e l'altro di tipo multi-part
> > (p.es. POINT e MULTIPOINT, oppure POLYGON
> > e MULTIPOLYGON).
> >
> > a questo punto occorre creare la seconda
> > colonna-geometria stando ben attenti a
> > specificare il MultiType:
> >
> > SELECT AddGeometryColumn('table', 'geom2', srid, 'MULTIPOLYGON', 'XY');
> >
> > infine si procede al popolamento della
> > seconda colonna-geometria applicando un
> > opportuno operatore di cast, tale da
> > forzare il geometry-type per uniformare
> > tutte le geometrie al caso multi-part:
> >
> > UPDATE table SET geom2 = CastToMultiPolygon(geom);
> >
> >
> > caso #3
> > ===
> > nel resultset appaiono svariate righe, con
> > geometry-type incompatibili (p.es. POINT,
> > LINESTRING e MULTIPOLYGON).
> >
> > in questo caso non e' possibile procedere
> > ad una conversione diretta, andranno create
> > tante colonne-geometria quanti sono i
> > geometry-types, e durante la fase di popolamento
> > le geometrie andranno opportunamente filtrate
> > in base al tipo.
> >
> > ciao Sandro
> >
> >
> > poi, il provider spatialite di QGIS vedrebbe due colonne geometriche
> dello
> >> stesso strato.
> >>
> >> ___
> > Gfoss@lists.gfoss.it
> > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> > Questa e' una lista di discussione pubblica aperta a tutti.
> > I messaggi di questa lista non hanno relazione diretta con le posizioni
> > dell'Associazione GFOSS.it.
> > 796 iscritti al 28/12/2017
> >
>
>
>
> --
> *Ing. Salvatore Fiandaca*
> *mobile*.:+39 327.493.8955
> *m*: *pigrecoinfin...@gmail.com *
> *C.F*.: FNDSVT71E29Z103G
> *P.IVA*: 06597870820
> *membro QGIS Italia - http://qgis.it/ *
> *socio GFOSS.it - *http://gfoss.it/
> *blog:*
> * https://pigrecoinfinito.wordpress.com/
>  FB: Co-admin
> - https://www.facebook.com/qgis.it/ **
>  *
> *FB: moderatore - **https://www.facebook.com/groups/GisItalia/
> **
>  *
> *TW:  **https://twitter.com/totofiandaca
> *
>
> 43°51'0.54"N  10°34'27.62"E - EPSG:4326
>
> “Se la conoscenza deve essere aperta a tutti,
> perchè mai limitarne l’accesso?”
> R. Stallman
>
> Questo documento, allegati inclusi, contiene informazioni di proprietà di
> FIANDACA SALVATORE e deve essere utilizzato esclusivamente dal destinatario
> in relazione alle finalità per le quali è stato ricevuto. E' vietata
> qualsiasi forma di riproduzione o divulgazione senza l'esplicito consenso
> di FIANDACA SALVATORE. Qualora fosse stato ricevuto per errore si prega di
> informare tempestivamente il mittente e distruggere la copia in proprio
> possesso.
> 

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Totò Fiandaca]

Vorrei esprimere la mia gratitudine a Andrea Peri e Alessandro Furieri per
le spiegazioni, chiare ed efficaci.

Ho fatto delle prove sul db messo a disposizione da Massimiliano, seguendo
i consigli di Furieri, tutto funziona alla perfezione.

grazie

forse scriverò un articolo su questo thread.

saluti




Il giorno 7 febbraio 2018 12:53,  ha scritto:

> On Wed, 7 Feb 2018 12:06:06 +0100, Totò Fiandaca wrote:
>
>> correggetemi se dico fesserie:
>>
>> una soluzione sarebbe quella di aggiungere un altro campo geometry (es:
>> geom, definirlo per bene) alle tabelle e popolarle con la geometria con un
>> UPDATE.
>>
>> credo funzioni.
>>
>>
> si, dovrebbe funzionare, ma il percorso da seguire per
> fare un lavoro ben fatto e' un po' piu' complesso:
>
> - per prima cosa occorre verificare cosa contiene
>   esattamente il dataset; basta eseguire la seguente
>   query SQL:
>
> SELECT Count(*), GeometryType(geom), Srid(geom), CoordDimension(geom)
> FROM table
> GROUP BY 2, 3, 4;
>
> n.b. chi usa spatialite_gui puo' usare direttamente
> il tool "check geometries" dal menu associato a quella
> particolare colonna-geometria.
>
> - a questo punto tutto dipende dai risultati della
>   query precedente.
>
> caso #1
> ===
> nel resultset appare una singola riga.
> basta creare la seconda colonna-geometria con gli
> argomenti appropriati, p.es.
>
> SELECT AddGeometryColumn('table', 'geom2', srid, 'POINT', 'XY');
>
> a questo punto si procede direttamente al popolamento
> della nuova colonna-geometria:
>
> UPDATE table SET geom2 = geom;
>
>
> caso #2
> ===
> nel resultset appaiono un paio di righe, ma
> tutte con il medesimo modello dimensionale e
> con tipi geometrici compatibili, uno di tipo
> single-part e l'altro di tipo multi-part
> (p.es. POINT e MULTIPOINT, oppure POLYGON
> e MULTIPOLYGON).
>
> a questo punto occorre creare la seconda
> colonna-geometria stando ben attenti a
> specificare il MultiType:
>
> SELECT AddGeometryColumn('table', 'geom2', srid, 'MULTIPOLYGON', 'XY');
>
> infine si procede al popolamento della
> seconda colonna-geometria applicando un
> opportuno operatore di cast, tale da
> forzare il geometry-type per uniformare
> tutte le geometrie al caso multi-part:
>
> UPDATE table SET geom2 = CastToMultiPolygon(geom);
>
>
> caso #3
> ===
> nel resultset appaiono svariate righe, con
> geometry-type incompatibili (p.es. POINT,
> LINESTRING e MULTIPOLYGON).
>
> in questo caso non e' possibile procedere
> ad una conversione diretta, andranno create
> tante colonne-geometria quanti sono i
> geometry-types, e durante la fase di popolamento
> le geometrie andranno opportunamente filtrate
> in base al tipo.
>
> ciao Sandro
>
>
> poi, il provider spatialite di QGIS vedrebbe due colonne geometriche dello
>> stesso strato.
>>
>> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 796 iscritti al 28/12/2017
>



-- 
*Ing. Salvatore Fiandaca*
*mobile*.:+39 327.493.8955
*m*: *pigrecoinfin...@gmail.com *
*C.F*.: FNDSVT71E29Z103G
*P.IVA*: 06597870820
*membro QGIS Italia - http://qgis.it/ *
*socio GFOSS.it - *http://gfoss.it/
*blog:*
* https://pigrecoinfinito.wordpress.com/
 FB: Co-admin
- https://www.facebook.com/qgis.it/ **
 *
*FB: moderatore - **https://www.facebook.com/groups/GisItalia/
**
 *
*TW:  **https://twitter.com/totofiandaca
*

43°51'0.54"N  10°34'27.62"E - EPSG:4326

“Se la conoscenza deve essere aperta a tutti,
perchè mai limitarne l’accesso?”
R. Stallman

Questo documento, allegati inclusi, contiene informazioni di proprietà di
FIANDACA SALVATORE e deve essere utilizzato esclusivamente dal destinatario
in relazione alle finalità per le quali è stato ricevuto. E' vietata
qualsiasi forma di riproduzione o divulgazione senza l'esplicito consenso
di FIANDACA SALVATORE. Qualora fosse stato ricevuto per errore si prega di
informare tempestivamente il mittente e distruggere la copia in proprio
possesso.
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Andrea Peri]

Su mapserver quando accedo spatialite uso un trucco mitico che mi insegnò
even rouault.

Anziché chiamare il.dataset direttamente in loco una query. Se il dataset e
ha due campi geometrici  uno di nome centroide e l altro dimtipo altro e
con nome geometry e il dataset si chiama pippo , uso questa query

Select pippo.rowid ad msFID, pippo.centroide,
pippo.* from Pippo

In questo modo si presenta per primo il campo centroide rispetto all' altro
campo geometrico.

Gdal usa il primo che trova e quindi mi sono assicurato che usi il campo
che voglio io.

Noi abbiamo più din500 strati esposti sui nostri wms.
Questa sintassi ci ha risolto un mare di problemi.

A



Il 07 Feb 2018 12:47, "Andrea Peri"  ha scritto:

> A gdal , se ci sono più campi geometrici si può dire quale utilizzare con
> un opportuno parametro.
> Il problema è che qgis usa gdal con le opzioni di default è a quello che
> so io non consente l impostazione di parametri extra. Anche se esistenti
> nel driver di gdal usato.
>
> Il 07 Feb 2018 12:06, "Totò Fiandaca"  ha
> scritto:
>
>> correggetemi se dico fesserie:
>>
>> una soluzione sarebbe quella di aggiungere un altro campo geometry (es:
>> geom, definirlo per bene) alle tabelle e popolarle con la geometria con un
>> UPDATE.
>>
>> credo funzioni.
>>
>> poi, il provider spatialite di QGIS vedrebbe due colonne geometriche
>> dello stesso strato.
>>
>>
>>
>> Il giorno 7 febbraio 2018 11:49, Andrea Peri  ha
>> scritto:
>>
>>> Questo succedeva anche nelle precedenti versioni dinpostgis.
>>>
>>>  Io Vecchi postgis richiedevano che l'utente dopo aver inserito una
>>> geometria su una tabella la definisse in una speciale tabella chiamata
>>> geometry_columns.
>>>
>>> Qui nascevano un sacco di casini. Perché spesso l'utente non valorizzava
>>> questo record, magari perché non aveva i diritti per farlo.
>>> Nelle versioni più recenti è stata rasformata in una vista e il.tipo di
>>> geometria è ripreso dalla definizione del campo stesso.
>>>
>>> Spatialite per ragioni strutturali dello SQLite è costretto a seguire la
>>> vecchia strada.
>>>
>>> Per prova uno può provare a definire in una tabella di postgis un campo
>>> geometrico e definirlo genericamente "geometry".
>>> Postgis se vede che il campo è di tipo geometry permette di scriverci
>>> dentro punti linee o poligoni indifferenziatamente.
>>>
>>> Poi però qgis farà esattamente come nel caso tuo di spatialite, non
>>> capisce che tipo di geometria sia.
>>>
>>> Ogr/gdal è pensato per supportare attualmente geometrie di tipo
>>> simple-feature.
>>> E quindi devono essere necessariamente
>>> Punti linee o poligoni.
>>> Il tipo generico geometry o quello complesso
>>> Collection non sono supportati.
>>>
>>> Eventualmente potrà certamente spiegare meglio.
>>>
>>> A.
>>>
>>>
>>> Il 07 Feb 2018 10:35, "Totò Fiandaca"  ha
>>> scritto:
>>>
 Ciao,
 ho notato che i layer non riconosciuti da QGIS hanno, nella
 tabella "geometry_columns" di spaltialite, codice 0 nella colonna
 geometry_type;

 credo che dipenda, come hai scritto, dal modo con cui li hai generati.

 un parere da persone più esperte sarebbe gradito.

 ciao

 Il giorno 6 febbraio 2018 22:26, Massimiliano Moraca <
 massimilianomor...@gmail.com> ha scritto:

 > Funziona Totò :)
 > Avevo notato l'assenza di apici prima e li ho aggiunti credendo fosse
 una
 > tua svista. Ho dovuto inserire il path di destinazione perchè mi è
 uscito
 > questo messaggio:
 >
 > *ERROR 4: sqlite3_open(parete_puc.sqlite) failed: unable to open
 database
 > file*
 > *ERROR 1: SQLite driver failed to create parete_puc.sqlite*
 >
 > A path inserito ho ottenuto db esportato, credo che quell'errore
 faccia
 > riferimento all'assenza di permessi per scrivere in C
 >
 > Aprendo il db ho notato però che alcune tabelle non sono correttamente
 > viste in QGIS. Sono quelle con il simbolo della foto(img [0] e [1].
 Se apro
 > il db da Spatialite GUI però le geometrie sono correttamente
 riprodotte
 > come puoi vedere. Ti inserisco il link[2] per download del db
 > Ho notato che le tabelle problematiche sono quelle che ho ottenuto da
 > geoprocessing in PostGIS, dei banali clip da intersezione tra
 "ambito" e
 > "cuas09_select" per esempio; poi ci sono i due buffer che ho ottenuto
 con
 > ST_Union(ST_Buffer(geometry, distanza)).
 >
 > [0]https://drive.google.com/open?id=1PMMJYiez-fWGLoG1YC_WArBKKaZ0VFLk
 > [1]https://drive.google.com/open?id=11v9ZMMUX96-YiywS0x63BNNGWXp3fZLr
 > [2]https://drive.google.com/open?id=1WGJuUutyBO3_wqkQkth-flQTn5E-CAFe
 >
 > Il giorno 6 febbraio 2018 21:57, Totò Fiandaca <
 pigrecoinfin...@gmail.com>
 > ha scritto:
 >
 >> massimiliano, è importante seguire bene la sintassi; hai aggiunto
 apici
 >> 

Re: [Gfoss] Export PostGIS - SpatiaLITE

[a . furieri]

On Wed, 7 Feb 2018 12:06:06 +0100, Totò Fiandaca wrote:

correggetemi se dico fesserie:

una soluzione sarebbe quella di aggiungere un altro campo geometry 
(es:
geom, definirlo per bene) alle tabelle e popolarle con la geometria 
con un

UPDATE.

credo funzioni.



si, dovrebbe funzionare, ma il percorso da seguire per
fare un lavoro ben fatto e' un po' piu' complesso:

- per prima cosa occorre verificare cosa contiene
  esattamente il dataset; basta eseguire la seguente
  query SQL:

SELECT Count(*), GeometryType(geom), Srid(geom), CoordDimension(geom)
FROM table
GROUP BY 2, 3, 4;

n.b. chi usa spatialite_gui puo' usare direttamente
il tool "check geometries" dal menu associato a quella
particolare colonna-geometria.

- a questo punto tutto dipende dai risultati della
  query precedente.

caso #1
===
nel resultset appare una singola riga.
basta creare la seconda colonna-geometria con gli
argomenti appropriati, p.es.

SELECT AddGeometryColumn('table', 'geom2', srid, 'POINT', 'XY');

a questo punto si procede direttamente al popolamento
della nuova colonna-geometria:

UPDATE table SET geom2 = geom;


caso #2
===
nel resultset appaiono un paio di righe, ma
tutte con il medesimo modello dimensionale e
con tipi geometrici compatibili, uno di tipo
single-part e l'altro di tipo multi-part
(p.es. POINT e MULTIPOINT, oppure POLYGON
e MULTIPOLYGON).

a questo punto occorre creare la seconda
colonna-geometria stando ben attenti a
specificare il MultiType:

SELECT AddGeometryColumn('table', 'geom2', srid, 'MULTIPOLYGON', 'XY');

infine si procede al popolamento della
seconda colonna-geometria applicando un
opportuno operatore di cast, tale da
forzare il geometry-type per uniformare
tutte le geometrie al caso multi-part:

UPDATE table SET geom2 = CastToMultiPolygon(geom);


caso #3
===
nel resultset appaiono svariate righe, con
geometry-type incompatibili (p.es. POINT,
LINESTRING e MULTIPOLYGON).

in questo caso non e' possibile procedere
ad una conversione diretta, andranno create
tante colonne-geometria quanti sono i
geometry-types, e durante la fase di popolamento
le geometrie andranno opportunamente filtrate
in base al tipo.

ciao Sandro


poi, il provider spatialite di QGIS vedrebbe due colonne geometriche 
dello

stesso strato.


___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Andrea Peri]

A gdal , se ci sono più campi geometrici si può dire quale utilizzare con
un opportuno parametro.
Il problema è che qgis usa gdal con le opzioni di default è a quello che so
io non consente l impostazione di parametri extra. Anche se esistenti nel
driver di gdal usato.

Il 07 Feb 2018 12:06, "Totò Fiandaca"  ha
scritto:

> correggetemi se dico fesserie:
>
> una soluzione sarebbe quella di aggiungere un altro campo geometry (es:
> geom, definirlo per bene) alle tabelle e popolarle con la geometria con un
> UPDATE.
>
> credo funzioni.
>
> poi, il provider spatialite di QGIS vedrebbe due colonne geometriche dello
> stesso strato.
>
>
>
> Il giorno 7 febbraio 2018 11:49, Andrea Peri  ha
> scritto:
>
>> Questo succedeva anche nelle precedenti versioni dinpostgis.
>>
>>  Io Vecchi postgis richiedevano che l'utente dopo aver inserito una
>> geometria su una tabella la definisse in una speciale tabella chiamata
>> geometry_columns.
>>
>> Qui nascevano un sacco di casini. Perché spesso l'utente non valorizzava
>> questo record, magari perché non aveva i diritti per farlo.
>> Nelle versioni più recenti è stata rasformata in una vista e il.tipo di
>> geometria è ripreso dalla definizione del campo stesso.
>>
>> Spatialite per ragioni strutturali dello SQLite è costretto a seguire la
>> vecchia strada.
>>
>> Per prova uno può provare a definire in una tabella di postgis un campo
>> geometrico e definirlo genericamente "geometry".
>> Postgis se vede che il campo è di tipo geometry permette di scriverci
>> dentro punti linee o poligoni indifferenziatamente.
>>
>> Poi però qgis farà esattamente come nel caso tuo di spatialite, non
>> capisce che tipo di geometria sia.
>>
>> Ogr/gdal è pensato per supportare attualmente geometrie di tipo
>> simple-feature.
>> E quindi devono essere necessariamente
>> Punti linee o poligoni.
>> Il tipo generico geometry o quello complesso
>> Collection non sono supportati.
>>
>> Eventualmente potrà certamente spiegare meglio.
>>
>> A.
>>
>>
>> Il 07 Feb 2018 10:35, "Totò Fiandaca"  ha
>> scritto:
>>
>>> Ciao,
>>> ho notato che i layer non riconosciuti da QGIS hanno, nella
>>> tabella "geometry_columns" di spaltialite, codice 0 nella colonna
>>> geometry_type;
>>>
>>> credo che dipenda, come hai scritto, dal modo con cui li hai generati.
>>>
>>> un parere da persone più esperte sarebbe gradito.
>>>
>>> ciao
>>>
>>> Il giorno 6 febbraio 2018 22:26, Massimiliano Moraca <
>>> massimilianomor...@gmail.com> ha scritto:
>>>
>>> > Funziona Totò :)
>>> > Avevo notato l'assenza di apici prima e li ho aggiunti credendo fosse
>>> una
>>> > tua svista. Ho dovuto inserire il path di destinazione perchè mi è
>>> uscito
>>> > questo messaggio:
>>> >
>>> > *ERROR 4: sqlite3_open(parete_puc.sqlite) failed: unable to open
>>> database
>>> > file*
>>> > *ERROR 1: SQLite driver failed to create parete_puc.sqlite*
>>> >
>>> > A path inserito ho ottenuto db esportato, credo che quell'errore faccia
>>> > riferimento all'assenza di permessi per scrivere in C
>>> >
>>> > Aprendo il db ho notato però che alcune tabelle non sono correttamente
>>> > viste in QGIS. Sono quelle con il simbolo della foto(img [0] e [1]. Se
>>> apro
>>> > il db da Spatialite GUI però le geometrie sono correttamente riprodotte
>>> > come puoi vedere. Ti inserisco il link[2] per download del db
>>> > Ho notato che le tabelle problematiche sono quelle che ho ottenuto da
>>> > geoprocessing in PostGIS, dei banali clip da intersezione tra "ambito"
>>> e
>>> > "cuas09_select" per esempio; poi ci sono i due buffer che ho ottenuto
>>> con
>>> > ST_Union(ST_Buffer(geometry, distanza)).
>>> >
>>> > [0]https://drive.google.com/open?id=1PMMJYiez-fWGLoG1YC_WArBKKaZ0VFLk
>>> > [1]https://drive.google.com/open?id=11v9ZMMUX96-YiywS0x63BNNGWXp3fZLr
>>> > [2]https://drive.google.com/open?id=1WGJuUutyBO3_wqkQkth-flQTn5E-CAFe
>>> >
>>> > Il giorno 6 febbraio 2018 21:57, Totò Fiandaca <
>>> pigrecoinfin...@gmail.com>
>>> > ha scritto:
>>> >
>>> >> massimiliano, è importante seguire bene la sintassi; hai aggiunto
>>> apici
>>> >> dove non ci vogliono è public senza apici:
>>> >>
>>> >> *ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO -f
>>> >> "SQLite" parete_puc.sqlite -progress PG:"dbname='parete_puc'
>>> >> active_schema=public schemas=public host='localhost' port='5432'
>>> >> user='postgres' password='1983' " -lco LAUNDER=yes -dsco
>>> SPATIALITE=yes
>>> >> -lco SPATIAL_INDEX=no*
>>> >>
>>> >> riprova con quella di sopra.
>>> >>
>>> >> Il giorno 6 febbraio 2018 21:49, Massimiliano Moraca <
>>> >> massimilianomor...@gmail.com> ha scritto:
>>> >>
>>> >>> Nulla da fare...ti copio pari pari quello che scrivo:
>>> >>>
>>> >>> *ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO -f
>>> >>> "SQLite" parete_puc.sqlite -progress PG:"dbname='parete_puc'
>>> >>> active_schema='public' schemas='public' host='localhost' port='5432'
>>> >>> user='postgres' 

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Totò Fiandaca]

correggetemi se dico fesserie:

una soluzione sarebbe quella di aggiungere un altro campo geometry (es:
geom, definirlo per bene) alle tabelle e popolarle con la geometria con un
UPDATE.

credo funzioni.

poi, il provider spatialite di QGIS vedrebbe due colonne geometriche dello
stesso strato.



Il giorno 7 febbraio 2018 11:49, Andrea Peri  ha
scritto:

> Questo succedeva anche nelle precedenti versioni dinpostgis.
>
>  Io Vecchi postgis richiedevano che l'utente dopo aver inserito una
> geometria su una tabella la definisse in una speciale tabella chiamata
> geometry_columns.
>
> Qui nascevano un sacco di casini. Perché spesso l'utente non valorizzava
> questo record, magari perché non aveva i diritti per farlo.
> Nelle versioni più recenti è stata rasformata in una vista e il.tipo di
> geometria è ripreso dalla definizione del campo stesso.
>
> Spatialite per ragioni strutturali dello SQLite è costretto a seguire la
> vecchia strada.
>
> Per prova uno può provare a definire in una tabella di postgis un campo
> geometrico e definirlo genericamente "geometry".
> Postgis se vede che il campo è di tipo geometry permette di scriverci
> dentro punti linee o poligoni indifferenziatamente.
>
> Poi però qgis farà esattamente come nel caso tuo di spatialite, non
> capisce che tipo di geometria sia.
>
> Ogr/gdal è pensato per supportare attualmente geometrie di tipo
> simple-feature.
> E quindi devono essere necessariamente
> Punti linee o poligoni.
> Il tipo generico geometry o quello complesso
> Collection non sono supportati.
>
> Eventualmente potrà certamente spiegare meglio.
>
> A.
>
>
> Il 07 Feb 2018 10:35, "Totò Fiandaca"  ha
> scritto:
>
>> Ciao,
>> ho notato che i layer non riconosciuti da QGIS hanno, nella
>> tabella "geometry_columns" di spaltialite, codice 0 nella colonna
>> geometry_type;
>>
>> credo che dipenda, come hai scritto, dal modo con cui li hai generati.
>>
>> un parere da persone più esperte sarebbe gradito.
>>
>> ciao
>>
>> Il giorno 6 febbraio 2018 22:26, Massimiliano Moraca <
>> massimilianomor...@gmail.com> ha scritto:
>>
>> > Funziona Totò :)
>> > Avevo notato l'assenza di apici prima e li ho aggiunti credendo fosse
>> una
>> > tua svista. Ho dovuto inserire il path di destinazione perchè mi è
>> uscito
>> > questo messaggio:
>> >
>> > *ERROR 4: sqlite3_open(parete_puc.sqlite) failed: unable to open
>> database
>> > file*
>> > *ERROR 1: SQLite driver failed to create parete_puc.sqlite*
>> >
>> > A path inserito ho ottenuto db esportato, credo che quell'errore faccia
>> > riferimento all'assenza di permessi per scrivere in C
>> >
>> > Aprendo il db ho notato però che alcune tabelle non sono correttamente
>> > viste in QGIS. Sono quelle con il simbolo della foto(img [0] e [1]. Se
>> apro
>> > il db da Spatialite GUI però le geometrie sono correttamente riprodotte
>> > come puoi vedere. Ti inserisco il link[2] per download del db
>> > Ho notato che le tabelle problematiche sono quelle che ho ottenuto da
>> > geoprocessing in PostGIS, dei banali clip da intersezione tra "ambito" e
>> > "cuas09_select" per esempio; poi ci sono i due buffer che ho ottenuto
>> con
>> > ST_Union(ST_Buffer(geometry, distanza)).
>> >
>> > [0]https://drive.google.com/open?id=1PMMJYiez-fWGLoG1YC_WArBKKaZ0VFLk
>> > [1]https://drive.google.com/open?id=11v9ZMMUX96-YiywS0x63BNNGWXp3fZLr
>> > [2]https://drive.google.com/open?id=1WGJuUutyBO3_wqkQkth-flQTn5E-CAFe
>> >
>> > Il giorno 6 febbraio 2018 21:57, Totò Fiandaca <
>> pigrecoinfin...@gmail.com>
>> > ha scritto:
>> >
>> >> massimiliano, è importante seguire bene la sintassi; hai aggiunto apici
>> >> dove non ci vogliono è public senza apici:
>> >>
>> >> *ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO -f
>> >> "SQLite" parete_puc.sqlite -progress PG:"dbname='parete_puc'
>> >> active_schema=public schemas=public host='localhost' port='5432'
>> >> user='postgres' password='1983' " -lco LAUNDER=yes -dsco SPATIALITE=yes
>> >> -lco SPATIAL_INDEX=no*
>> >>
>> >> riprova con quella di sopra.
>> >>
>> >> Il giorno 6 febbraio 2018 21:49, Massimiliano Moraca <
>> >> massimilianomor...@gmail.com> ha scritto:
>> >>
>> >>> Nulla da fare...ti copio pari pari quello che scrivo:
>> >>>
>> >>> *ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO -f
>> >>> "SQLite" parete_puc.sqlite -progress PG:"dbname='parete_puc'
>> >>> active_schema='public' schemas='public' host='localhost' port='5432'
>> >>> user='postgres' password='1983' " -lco LAUNDER=yes -dsco
>> SPATIALITE=yes
>> >>> -lco SPATIAL_INDEX=no*
>> >>>
>> >>> L'errore ora è questo:
>> >>>
>> >>> *ERROR 1: ERRORE:  errore di sintassi a o presso "public"*
>> >>> *LINE 1: SET search_path=''public'',public*
>> >>> *  ^*
>> >>>
>> >>> *ERROR 1: ERRORE:  errore di sintassi a o presso "public"*
>> >>> *LINE 1: SET search_path=''public''*
>> >>> *  ^*
>> >>>
>> >>> *ERROR 1: ERRORE:  errore di sintassi a 

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Andrea Peri]

Questo succedeva anche nelle precedenti versioni dinpostgis.

 Io Vecchi postgis richiedevano che l'utente dopo aver inserito una
geometria su una tabella la definisse in una speciale tabella chiamata
geometry_columns.

Qui nascevano un sacco di casini. Perché spesso l'utente non valorizzava
questo record, magari perché non aveva i diritti per farlo.
Nelle versioni più recenti è stata rasformata in una vista e il.tipo di
geometria è ripreso dalla definizione del campo stesso.

Spatialite per ragioni strutturali dello SQLite è costretto a seguire la
vecchia strada.

Per prova uno può provare a definire in una tabella di postgis un campo
geometrico e definirlo genericamente "geometry".
Postgis se vede che il campo è di tipo geometry permette di scriverci
dentro punti linee o poligoni indifferenziatamente.

Poi però qgis farà esattamente come nel caso tuo di spatialite, non capisce
che tipo di geometria sia.

Ogr/gdal è pensato per supportare attualmente geometrie di tipo
simple-feature.
E quindi devono essere necessariamente
Punti linee o poligoni.
Il tipo generico geometry o quello complesso
Collection non sono supportati.

Eventualmente potrà certamente spiegare meglio.

A.


Il 07 Feb 2018 10:35, "Totò Fiandaca"  ha
scritto:

> Ciao,
> ho notato che i layer non riconosciuti da QGIS hanno, nella
> tabella "geometry_columns" di spaltialite, codice 0 nella colonna
> geometry_type;
>
> credo che dipenda, come hai scritto, dal modo con cui li hai generati.
>
> un parere da persone più esperte sarebbe gradito.
>
> ciao
>
> Il giorno 6 febbraio 2018 22:26, Massimiliano Moraca <
> massimilianomor...@gmail.com> ha scritto:
>
> > Funziona Totò :)
> > Avevo notato l'assenza di apici prima e li ho aggiunti credendo fosse una
> > tua svista. Ho dovuto inserire il path di destinazione perchè mi è uscito
> > questo messaggio:
> >
> > *ERROR 4: sqlite3_open(parete_puc.sqlite) failed: unable to open
> database
> > file*
> > *ERROR 1: SQLite driver failed to create parete_puc.sqlite*
> >
> > A path inserito ho ottenuto db esportato, credo che quell'errore faccia
> > riferimento all'assenza di permessi per scrivere in C
> >
> > Aprendo il db ho notato però che alcune tabelle non sono correttamente
> > viste in QGIS. Sono quelle con il simbolo della foto(img [0] e [1]. Se
> apro
> > il db da Spatialite GUI però le geometrie sono correttamente riprodotte
> > come puoi vedere. Ti inserisco il link[2] per download del db
> > Ho notato che le tabelle problematiche sono quelle che ho ottenuto da
> > geoprocessing in PostGIS, dei banali clip da intersezione tra "ambito" e
> > "cuas09_select" per esempio; poi ci sono i due buffer che ho ottenuto con
> > ST_Union(ST_Buffer(geometry, distanza)).
> >
> > [0]https://drive.google.com/open?id=1PMMJYiez-fWGLoG1YC_WArBKKaZ0VFLk
> > [1]https://drive.google.com/open?id=11v9ZMMUX96-YiywS0x63BNNGWXp3fZLr
> > [2]https://drive.google.com/open?id=1WGJuUutyBO3_wqkQkth-flQTn5E-CAFe
> >
> > Il giorno 6 febbraio 2018 21:57, Totò Fiandaca <
> pigrecoinfin...@gmail.com>
> > ha scritto:
> >
> >> massimiliano, è importante seguire bene la sintassi; hai aggiunto apici
> >> dove non ci vogliono è public senza apici:
> >>
> >> *ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO -f
> >> "SQLite" parete_puc.sqlite -progress PG:"dbname='parete_puc'
> >> active_schema=public schemas=public host='localhost' port='5432'
> >> user='postgres' password='1983' " -lco LAUNDER=yes -dsco SPATIALITE=yes
> >> -lco SPATIAL_INDEX=no*
> >>
> >> riprova con quella di sopra.
> >>
> >> Il giorno 6 febbraio 2018 21:49, Massimiliano Moraca <
> >> massimilianomor...@gmail.com> ha scritto:
> >>
> >>> Nulla da fare...ti copio pari pari quello che scrivo:
> >>>
> >>> *ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO -f
> >>> "SQLite" parete_puc.sqlite -progress PG:"dbname='parete_puc'
> >>> active_schema='public' schemas='public' host='localhost' port='5432'
> >>> user='postgres' password='1983' " -lco LAUNDER=yes -dsco SPATIALITE=yes
> >>> -lco SPATIAL_INDEX=no*
> >>>
> >>> L'errore ora è questo:
> >>>
> >>> *ERROR 1: ERRORE:  errore di sintassi a o presso "public"*
> >>> *LINE 1: SET search_path=''public'',public*
> >>> *  ^*
> >>>
> >>> *ERROR 1: ERRORE:  errore di sintassi a o presso "public"*
> >>> *LINE 1: SET search_path=''public''*
> >>> *  ^*
> >>>
> >>> *ERROR 1: ERRORE:  errore di sintassi a o presso "public"*
> >>> *LINE 1: SET search_path=''public''*
> >>> *  ^*
> >>>
> >>> *FAILURE:*
> >>> *Unable to open datasource `PG:dbname='parete_puc'
> >>> active_schema='public' schemas='public' host='localhost' port='5432'
> >>> user='postgres' password='1983' ' with the following drivers.*
> >>>
> >>>
> >>>
> >>> Il giorno 6 febbraio 2018 21:38, Totò Fiandaca <
> >>> pigrecoinfin...@gmail.com> ha scritto:
> >>>
>  Incolla sempre l'intero script cosi possiamo controllare.
>  nello script 

Re: [Gfoss] Export PostGIS - SpatiaLITE

[a . furieri]

On Wed, 7 Feb 2018 10:35:39 +0100, Totò Fiandaca wrote:

Ciao,
ho notato che i layer non riconosciuti da QGIS hanno, nella
tabella "geometry_columns" di spaltialite, codice 0 nella colonna
geometry_type;



conformemente alle specifiche OGC-SFS geometry-type=0 identifica
la super-classe astratta GEOMETRY (cioe' in soldoni indica che
quella colonna puo' contenere qualsiasi tipo di geometria, dal
POINT al LINESTRING al POLYGON etc).
e notoriamente QGIS non e' in grado di gestire i geometry-type
GEOMETRY e GEOMETRYCOLLECTION, come invece fanno piu' o meno
tutti i WMS/WFS servers ed OpenJump.


credo che dipenda, come hai scritto, dal modo con cui li hai 
generati.




probabilmente sono il frutto di qualche funzione che genera
risultati "a tipo variabile".
in ogni caso una query come la seguente aiuta a comprendere
meglio la situazione reale del dataset:

SELECT ST_GeometryType(geom), count(*)
FROM table
GROUP BY ST_GeometryType(geom);



un parere da persone più esperte sarebbe gradito.



provate a contattare Even Rouault sulle mailing
lists di GDAL; nessuno meglio di lui e' in grado
di darvi una risposta completa ed esaustiva per
tutto quel che riguarda tutta la famiglia dei
drivers OGR/SQLite.

ciao Sandro


___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Massimiliano Moraca]

Riporto come esempio la query che ho scritto per definire comuni_ambito:

*CREATE TABLE comuni_ambito AS*
*SELECT*

*ST_Intersection (a1.geometry, a2.geometry) AS geometry,*

*a2.comune AS comune*

*FROM ambito AS a1, comuni_limitrofi_orig AS a2*
*WHERE ST_Intersects(a1.geometry, a2.geometry);*

Successivamente ho inserito la chiave primaria con:

*ALTER TABLE comuni_ambito*
*ADD COLUMN pkca SERIAL PRIMARY KEY;*

Per gli altri clip ho usato la stessa procedura ovviamente cambiando i
field di riferimento in a2.

Il giorno 7 febbraio 2018 10:35, Totò Fiandaca 
ha scritto:

> Ciao,
> ho notato che i layer non riconosciuti da QGIS hanno, nella
> tabella "geometry_columns" di spaltialite, codice 0 nella colonna
> geometry_type;
>
> credo che dipenda, come hai scritto, dal modo con cui li hai generati.
>
> un parere da persone più esperte sarebbe gradito.
>
> ciao
>
> Il giorno 6 febbraio 2018 22:26, Massimiliano Moraca <
> massimilianomor...@gmail.com> ha scritto:
>
>> Funziona Totò :)
>> Avevo notato l'assenza di apici prima e li ho aggiunti credendo fosse una
>> tua svista. Ho dovuto inserire il path di destinazione perchè mi è uscito
>> questo messaggio:
>>
>> *ERROR 4: sqlite3_open(parete_puc.sqlite) failed: unable to open database
>> file*
>> *ERROR 1: SQLite driver failed to create parete_puc.sqlite*
>>
>> A path inserito ho ottenuto db esportato, credo che quell'errore faccia
>> riferimento all'assenza di permessi per scrivere in C
>>
>> Aprendo il db ho notato però che alcune tabelle non sono correttamente
>> viste in QGIS. Sono quelle con il simbolo della foto(img [0] e [1]. Se apro
>> il db da Spatialite GUI però le geometrie sono correttamente riprodotte
>> come puoi vedere. Ti inserisco il link[2] per download del db
>> Ho notato che le tabelle problematiche sono quelle che ho ottenuto da
>> geoprocessing in PostGIS, dei banali clip da intersezione tra "ambito" e
>> "cuas09_select" per esempio; poi ci sono i due buffer che ho ottenuto con
>> ST_Union(ST_Buffer(geometry, distanza)).
>>
>> [0]https://drive.google.com/open?id=1PMMJYiez-fWGLoG1YC_WArBKKaZ0VFLk
>> [1]https://drive.google.com/open?id=11v9ZMMUX96-YiywS0x63BNNGWXp3fZLr
>> [2]https://drive.google.com/open?id=1WGJuUutyBO3_wqkQkth-flQTn5E-CAFe
>>
>> Il giorno 6 febbraio 2018 21:57, Totò Fiandaca > > ha scritto:
>>
>>> massimiliano, è importante seguire bene la sintassi; hai aggiunto apici
>>> dove non ci vogliono è public senza apici:
>>>
>>> *ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO -f
>>> "SQLite" parete_puc.sqlite -progress PG:"dbname='parete_puc'
>>> active_schema=public schemas=public host='localhost' port='5432'
>>> user='postgres' password='1983' " -lco LAUNDER=yes -dsco SPATIALITE=yes
>>> -lco SPATIAL_INDEX=no*
>>>
>>> riprova con quella di sopra.
>>>
>>> Il giorno 6 febbraio 2018 21:49, Massimiliano Moraca <
>>> massimilianomor...@gmail.com> ha scritto:
>>>
 Nulla da fare...ti copio pari pari quello che scrivo:

 *ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO -f
 "SQLite" parete_puc.sqlite -progress PG:"dbname='parete_puc'
 active_schema='public' schemas='public' host='localhost' port='5432'
 user='postgres' password='1983' " -lco LAUNDER=yes -dsco SPATIALITE=yes
 -lco SPATIAL_INDEX=no*

 L'errore ora è questo:

 *ERROR 1: ERRORE:  errore di sintassi a o presso "public"*
 *LINE 1: SET search_path=''public'',public*
 *  ^*

 *ERROR 1: ERRORE:  errore di sintassi a o presso "public"*
 *LINE 1: SET search_path=''public''*
 *  ^*

 *ERROR 1: ERRORE:  errore di sintassi a o presso "public"*
 *LINE 1: SET search_path=''public''*
 *  ^*

 *FAILURE:*
 *Unable to open datasource `PG:dbname='parete_puc'
 active_schema='public' schemas='public' host='localhost' port='5432'
 user='postgres' password='1983' ' with the following drivers.*



 Il giorno 6 febbraio 2018 21:38, Totò Fiandaca <
 pigrecoinfin...@gmail.com> ha scritto:

> Incolla sempre l'intero script cosi possiamo controllare.
> nello script del blog, il db pg ha due schemi:  
> active_schema=public,data_2015
> schemas=public,data_2015
> tu, se hai un solo schema, devi scrivere:  active_schema=public
> schemas=public
>
> usa questo:
> ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO -f
> “SQLite” nome_database.sqlite -progress PG:”dbname=’puc_parete’
> active_schema=public schemas=public host=’localhost’ port=’5432′
> user=’postgres’ password=’1983’ ” -lco LAUNDER=yes -dsco SPATIALITE=yes
> -lco SPATIAL_INDEX=no
>
>
> Il giorno 6 febbraio 2018 21:26, Massimiliano Moraca <
> massimilianomor...@gmail.com> ha scritto:
>
>> Ho fatto come mi hai detto Totò(password a parte che era chiaro :D)
>> 

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Totò Fiandaca]

Ciao,
ho notato che i layer non riconosciuti da QGIS hanno, nella
tabella "geometry_columns" di spaltialite, codice 0 nella colonna
geometry_type;

credo che dipenda, come hai scritto, dal modo con cui li hai generati.

un parere da persone più esperte sarebbe gradito.

ciao

Il giorno 6 febbraio 2018 22:26, Massimiliano Moraca <
massimilianomor...@gmail.com> ha scritto:

> Funziona Totò :)
> Avevo notato l'assenza di apici prima e li ho aggiunti credendo fosse una
> tua svista. Ho dovuto inserire il path di destinazione perchè mi è uscito
> questo messaggio:
>
> *ERROR 4: sqlite3_open(parete_puc.sqlite) failed: unable to open database
> file*
> *ERROR 1: SQLite driver failed to create parete_puc.sqlite*
>
> A path inserito ho ottenuto db esportato, credo che quell'errore faccia
> riferimento all'assenza di permessi per scrivere in C
>
> Aprendo il db ho notato però che alcune tabelle non sono correttamente
> viste in QGIS. Sono quelle con il simbolo della foto(img [0] e [1]. Se apro
> il db da Spatialite GUI però le geometrie sono correttamente riprodotte
> come puoi vedere. Ti inserisco il link[2] per download del db
> Ho notato che le tabelle problematiche sono quelle che ho ottenuto da
> geoprocessing in PostGIS, dei banali clip da intersezione tra "ambito" e
> "cuas09_select" per esempio; poi ci sono i due buffer che ho ottenuto con
> ST_Union(ST_Buffer(geometry, distanza)).
>
> [0]https://drive.google.com/open?id=1PMMJYiez-fWGLoG1YC_WArBKKaZ0VFLk
> [1]https://drive.google.com/open?id=11v9ZMMUX96-YiywS0x63BNNGWXp3fZLr
> [2]https://drive.google.com/open?id=1WGJuUutyBO3_wqkQkth-flQTn5E-CAFe
>
> Il giorno 6 febbraio 2018 21:57, Totò Fiandaca 
> ha scritto:
>
>> massimiliano, è importante seguire bene la sintassi; hai aggiunto apici
>> dove non ci vogliono è public senza apici:
>>
>> *ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO -f
>> "SQLite" parete_puc.sqlite -progress PG:"dbname='parete_puc'
>> active_schema=public schemas=public host='localhost' port='5432'
>> user='postgres' password='1983' " -lco LAUNDER=yes -dsco SPATIALITE=yes
>> -lco SPATIAL_INDEX=no*
>>
>> riprova con quella di sopra.
>>
>> Il giorno 6 febbraio 2018 21:49, Massimiliano Moraca <
>> massimilianomor...@gmail.com> ha scritto:
>>
>>> Nulla da fare...ti copio pari pari quello che scrivo:
>>>
>>> *ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO -f
>>> "SQLite" parete_puc.sqlite -progress PG:"dbname='parete_puc'
>>> active_schema='public' schemas='public' host='localhost' port='5432'
>>> user='postgres' password='1983' " -lco LAUNDER=yes -dsco SPATIALITE=yes
>>> -lco SPATIAL_INDEX=no*
>>>
>>> L'errore ora è questo:
>>>
>>> *ERROR 1: ERRORE:  errore di sintassi a o presso "public"*
>>> *LINE 1: SET search_path=''public'',public*
>>> *  ^*
>>>
>>> *ERROR 1: ERRORE:  errore di sintassi a o presso "public"*
>>> *LINE 1: SET search_path=''public''*
>>> *  ^*
>>>
>>> *ERROR 1: ERRORE:  errore di sintassi a o presso "public"*
>>> *LINE 1: SET search_path=''public''*
>>> *  ^*
>>>
>>> *FAILURE:*
>>> *Unable to open datasource `PG:dbname='parete_puc'
>>> active_schema='public' schemas='public' host='localhost' port='5432'
>>> user='postgres' password='1983' ' with the following drivers.*
>>>
>>>
>>>
>>> Il giorno 6 febbraio 2018 21:38, Totò Fiandaca <
>>> pigrecoinfin...@gmail.com> ha scritto:
>>>
 Incolla sempre l'intero script cosi possiamo controllare.
 nello script del blog, il db pg ha due schemi:  
 active_schema=public,data_2015
 schemas=public,data_2015
 tu, se hai un solo schema, devi scrivere:  active_schema=public
 schemas=public

 usa questo:
 ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO -f
 “SQLite” nome_database.sqlite -progress PG:”dbname=’puc_parete’
 active_schema=public schemas=public host=’localhost’ port=’5432′
 user=’postgres’ password=’1983’ ” -lco LAUNDER=yes -dsco SPATIALITE=yes
 -lco SPATIAL_INDEX=no


 Il giorno 6 febbraio 2018 21:26, Massimiliano Moraca <
 massimilianomor...@gmail.com> ha scritto:

> Ho fatto come mi hai detto Totò(password a parte che era chiaro :D) ed
> ora ho questo messaggio:
>
> *ERROR 1: PQconnectdb failed.*
> *FATALE:  il database "puc_parete" non esiste*
>
> *FAILURE:*
> *Unable to open datasource `PG:dbname='puc_parete'
> active_schema='public' schemas='public' host='localhost' port='5432'
> user='postgres' password='1983' ' with the following drivers.*
>
> Nello script sul tuo blog c'è scritto *active_schema='public.data_2015'
> schemas= 'public.data_2015'*, io ho lasciato solo public perchè credo
> che il tuo script faccia riferimento ad una specifica tabella(
> *data_2015*). Confermi? Io voglio esportare tutto ciò che c'è in
> public.
>
> Il giorno 6 febbraio 2018 21:00, Totò Fiandaca <

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Massimiliano Moraca]

 Funziona Totò :)
Avevo notato l'assenza di apici prima e li ho aggiunti credendo fosse una
tua svista. Ho dovuto inserire il path di destinazione perchè mi è uscito
questo messaggio:

*ERROR 4: sqlite3_open(parete_puc.sqlite) failed: unable to open database
file*
*ERROR 1: SQLite driver failed to create parete_puc.sqlite*

A path inserito ho ottenuto db esportato, credo che quell'errore faccia
riferimento all'assenza di permessi per scrivere in C

Aprendo il db ho notato però che alcune tabelle non sono correttamente
viste in QGIS. Sono quelle con il simbolo della foto(img [0] e [1]. Se apro
il db da Spatialite GUI però le geometrie sono correttamente riprodotte
come puoi vedere. Ti inserisco il link[2] per download del db
Ho notato che le tabelle problematiche sono quelle che ho ottenuto da
geoprocessing in PostGIS, dei banali clip da intersezione tra "ambito" e
"cuas09_select" per esempio; poi ci sono i due buffer che ho ottenuto con
ST_Union(ST_Buffer(geometry, distanza)).

[0]https://drive.google.com/open?id=1PMMJYiez-fWGLoG1YC_WArBKKaZ0VFLk
[1]https://drive.google.com/open?id=11v9ZMMUX96-YiywS0x63BNNGWXp3fZLr
[2]https://drive.google.com/open?id=1WGJuUutyBO3_wqkQkth-flQTn5E-CAFe

Il giorno 6 febbraio 2018 21:57, Totò Fiandaca 
ha scritto:

> massimiliano, è importante seguire bene la sintassi; hai aggiunto apici
> dove non ci vogliono è public senza apici:
>
> *ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO -f
> "SQLite" parete_puc.sqlite -progress PG:"dbname='parete_puc'
> active_schema=public schemas=public host='localhost' port='5432'
> user='postgres' password='1983' " -lco LAUNDER=yes -dsco SPATIALITE=yes
> -lco SPATIAL_INDEX=no*
>
> riprova con quella di sopra.
>
> Il giorno 6 febbraio 2018 21:49, Massimiliano Moraca <
> massimilianomor...@gmail.com> ha scritto:
>
>> Nulla da fare...ti copio pari pari quello che scrivo:
>>
>> *ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO -f
>> "SQLite" parete_puc.sqlite -progress PG:"dbname='parete_puc'
>> active_schema='public' schemas='public' host='localhost' port='5432'
>> user='postgres' password='1983' " -lco LAUNDER=yes -dsco SPATIALITE=yes
>> -lco SPATIAL_INDEX=no*
>>
>> L'errore ora è questo:
>>
>> *ERROR 1: ERRORE:  errore di sintassi a o presso "public"*
>> *LINE 1: SET search_path=''public'',public*
>> *  ^*
>>
>> *ERROR 1: ERRORE:  errore di sintassi a o presso "public"*
>> *LINE 1: SET search_path=''public''*
>> *  ^*
>>
>> *ERROR 1: ERRORE:  errore di sintassi a o presso "public"*
>> *LINE 1: SET search_path=''public''*
>> *  ^*
>>
>> *FAILURE:*
>> *Unable to open datasource `PG:dbname='parete_puc'
>> active_schema='public' schemas='public' host='localhost' port='5432'
>> user='postgres' password='1983' ' with the following drivers.*
>>
>>
>>
>> Il giorno 6 febbraio 2018 21:38, Totò Fiandaca > > ha scritto:
>>
>>> Incolla sempre l'intero script cosi possiamo controllare.
>>> nello script del blog, il db pg ha due schemi:  
>>> active_schema=public,data_2015
>>> schemas=public,data_2015
>>> tu, se hai un solo schema, devi scrivere:  active_schema=public
>>> schemas=public
>>>
>>> usa questo:
>>> ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO -f
>>> “SQLite” nome_database.sqlite -progress PG:”dbname=’puc_parete’
>>> active_schema=public schemas=public host=’localhost’ port=’5432′
>>> user=’postgres’ password=’1983’ ” -lco LAUNDER=yes -dsco SPATIALITE=yes
>>> -lco SPATIAL_INDEX=no
>>>
>>>
>>> Il giorno 6 febbraio 2018 21:26, Massimiliano Moraca <
>>> massimilianomor...@gmail.com> ha scritto:
>>>
 Ho fatto come mi hai detto Totò(password a parte che era chiaro :D) ed
 ora ho questo messaggio:

 *ERROR 1: PQconnectdb failed.*
 *FATALE:  il database "puc_parete" non esiste*

 *FAILURE:*
 *Unable to open datasource `PG:dbname='puc_parete'
 active_schema='public' schemas='public' host='localhost' port='5432'
 user='postgres' password='1983' ' with the following drivers.*

 Nello script sul tuo blog c'è scritto *active_schema='public.data_2015'
 schemas= 'public.data_2015'*, io ho lasciato solo public perchè credo
 che il tuo script faccia riferimento ad una specifica tabella(
 *data_2015*). Confermi? Io voglio esportare tutto ciò che c'è in
 public.

 Il giorno 6 febbraio 2018 21:00, Totò Fiandaca <
 pigrecoinfin...@gmail.com> ha scritto:

> massimiliano,
> stai attento agli spazi (tra NO e -f  "SQLite" occorre uno spazio)
> inoltre, meglio esplicitarlo: al posto degli ** occorre mettere
> password
>
> poi, non mettere intero percorso del file sqlite ma solo il
> nome.sqlite; poi lo ritroverai sotto c:\utenti\nome_utente
>
> ciao
>
> Il giorno 6 febbraio 2018 19:47, Massimiliano Moraca <
> massimilianomor...@gmail.com> ha scritto:
>

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Totò Fiandaca]

massimiliano, è importante seguire bene la sintassi; hai aggiunto apici
dove non ci vogliono è public senza apici:

*ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO -f
"SQLite" parete_puc.sqlite -progress PG:"dbname='parete_puc'
active_schema=public schemas=public host='localhost' port='5432'
user='postgres' password='1983' " -lco LAUNDER=yes -dsco SPATIALITE=yes
-lco SPATIAL_INDEX=no*

riprova con quella di sopra.

Il giorno 6 febbraio 2018 21:49, Massimiliano Moraca <
massimilianomor...@gmail.com> ha scritto:

> Nulla da fare...ti copio pari pari quello che scrivo:
>
> *ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO -f
> "SQLite" parete_puc.sqlite -progress PG:"dbname='parete_puc'
> active_schema='public' schemas='public' host='localhost' port='5432'
> user='postgres' password='1983' " -lco LAUNDER=yes -dsco SPATIALITE=yes
> -lco SPATIAL_INDEX=no*
>
> L'errore ora è questo:
>
> *ERROR 1: ERRORE:  errore di sintassi a o presso "public"*
> *LINE 1: SET search_path=''public'',public*
> *  ^*
>
> *ERROR 1: ERRORE:  errore di sintassi a o presso "public"*
> *LINE 1: SET search_path=''public''*
> *  ^*
>
> *ERROR 1: ERRORE:  errore di sintassi a o presso "public"*
> *LINE 1: SET search_path=''public''*
> *  ^*
>
> *FAILURE:*
> *Unable to open datasource `PG:dbname='parete_puc'  active_schema='public'
> schemas='public' host='localhost' port='5432' user='postgres'
> password='1983' ' with the following drivers.*
>
>
>
> Il giorno 6 febbraio 2018 21:38, Totò Fiandaca 
> ha scritto:
>
>> Incolla sempre l'intero script cosi possiamo controllare.
>> nello script del blog, il db pg ha due schemi:  
>> active_schema=public,data_2015
>> schemas=public,data_2015
>> tu, se hai un solo schema, devi scrivere:  active_schema=public
>> schemas=public
>>
>> usa questo:
>> ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO -f
>> “SQLite” nome_database.sqlite -progress PG:”dbname=’puc_parete’
>> active_schema=public schemas=public host=’localhost’ port=’5432′
>> user=’postgres’ password=’1983’ ” -lco LAUNDER=yes -dsco SPATIALITE=yes
>> -lco SPATIAL_INDEX=no
>>
>>
>> Il giorno 6 febbraio 2018 21:26, Massimiliano Moraca <
>> massimilianomor...@gmail.com> ha scritto:
>>
>>> Ho fatto come mi hai detto Totò(password a parte che era chiaro :D) ed
>>> ora ho questo messaggio:
>>>
>>> *ERROR 1: PQconnectdb failed.*
>>> *FATALE:  il database "puc_parete" non esiste*
>>>
>>> *FAILURE:*
>>> *Unable to open datasource `PG:dbname='puc_parete'
>>> active_schema='public' schemas='public' host='localhost' port='5432'
>>> user='postgres' password='1983' ' with the following drivers.*
>>>
>>> Nello script sul tuo blog c'è scritto *active_schema='public.data_2015'
>>> schemas= 'public.data_2015'*, io ho lasciato solo public perchè credo
>>> che il tuo script faccia riferimento ad una specifica tabella(
>>> *data_2015*). Confermi? Io voglio esportare tutto ciò che c'è in
>>> public.
>>>
>>> Il giorno 6 febbraio 2018 21:00, Totò Fiandaca <
>>> pigrecoinfin...@gmail.com> ha scritto:
>>>
 massimiliano,
 stai attento agli spazi (tra NO e -f  "SQLite" occorre uno spazio)
 inoltre, meglio esplicitarlo: al posto degli ** occorre mettere
 password

 poi, non mettere intero percorso del file sqlite ma solo il
 nome.sqlite; poi lo ritroverai sotto c:\utenti\nome_utente

 ciao

 Il giorno 6 febbraio 2018 19:47, Massimiliano Moraca <
 massimilianomor...@gmail.com> ha scritto:

> Luca sono su Windows 10
>
> Il giorno 6 febbraio 2018 19:46, Massimiliano Moraca <
> massimilianomor...@gmail.com> ha scritto:
>
>> Totò mi sono "permesso" di apportare due piccole modifiche allo
>> script e cioè yes al post di no per l'index ed ho inserito il percorso in
>> cui mi deve creare il db sqlite:
>>
>> *ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO-f
>> "SQLite" D:\Postgresql\export\puc_parete.sqlite -progress
>> PG:"dbname=puc_parete  active_schema=public schemas=public host=localhost
>> port=5432 user=postgres password= " -lco LAUNDER=yes -dsco
>> SPATIALITE=yes -lco SPATIAL_INDEX=yes*
>>
>> Il risultato è stato questo:
>>
>> *FAILURE:*
>> *Unable to open datasource `D:\Postgresql\export\puc_parete.sqlite'
>> with the following drivers.*
>>
>> :(
>>
>> Esportare uno per uno i singoli vettore è l'estrema ratio che vorrei
>> evitare
>>
>> Il giorno 6 febbraio 2018 11:45, Totò Fiandaca <
>> pigrecoinfin...@gmail.com> ha scritto:
>>
>>> Ciao massimiliano,
>>> io seguo questo articolo, funziona bene:
>>>
>>> https://pigrecoinfinito.wordpress.com/2017/11/28/da-postgis-
>>> a-spatialite/
>>>
>>> Il giorno 6 febbraio 2018 11:40, Luca Delucchi >> > ha scritto:
>>>
 

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Massimiliano Moraca]

Nulla da fare...ti copio pari pari quello che scrivo:

*ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO -f
"SQLite" parete_puc.sqlite -progress PG:"dbname='parete_puc'
active_schema='public' schemas='public' host='localhost' port='5432'
user='postgres' password='1983' " -lco LAUNDER=yes -dsco SPATIALITE=yes
-lco SPATIAL_INDEX=no*

L'errore ora è questo:

*ERROR 1: ERRORE:  errore di sintassi a o presso "public"*
*LINE 1: SET search_path=''public'',public*
*  ^*

*ERROR 1: ERRORE:  errore di sintassi a o presso "public"*
*LINE 1: SET search_path=''public''*
*  ^*

*ERROR 1: ERRORE:  errore di sintassi a o presso "public"*
*LINE 1: SET search_path=''public''*
*  ^*

*FAILURE:*
*Unable to open datasource `PG:dbname='parete_puc'  active_schema='public'
schemas='public' host='localhost' port='5432' user='postgres'
password='1983' ' with the following drivers.*



Il giorno 6 febbraio 2018 21:38, Totò Fiandaca 
ha scritto:

> Incolla sempre l'intero script cosi possiamo controllare.
> nello script del blog, il db pg ha due schemi:  active_schema=public,data_2015
> schemas=public,data_2015
> tu, se hai un solo schema, devi scrivere:  active_schema=public
> schemas=public
>
> usa questo:
> ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO -f
> “SQLite” nome_database.sqlite -progress PG:”dbname=’puc_parete’
> active_schema=public schemas=public host=’localhost’ port=’5432′
> user=’postgres’ password=’1983’ ” -lco LAUNDER=yes -dsco SPATIALITE=yes
> -lco SPATIAL_INDEX=no
>
>
> Il giorno 6 febbraio 2018 21:26, Massimiliano Moraca <
> massimilianomor...@gmail.com> ha scritto:
>
>> Ho fatto come mi hai detto Totò(password a parte che era chiaro :D) ed
>> ora ho questo messaggio:
>>
>> *ERROR 1: PQconnectdb failed.*
>> *FATALE:  il database "puc_parete" non esiste*
>>
>> *FAILURE:*
>> *Unable to open datasource `PG:dbname='puc_parete'
>> active_schema='public' schemas='public' host='localhost' port='5432'
>> user='postgres' password='1983' ' with the following drivers.*
>>
>> Nello script sul tuo blog c'è scritto *active_schema='public.data_2015'
>> schemas= 'public.data_2015'*, io ho lasciato solo public perchè credo
>> che il tuo script faccia riferimento ad una specifica tabella(*data_2015*).
>> Confermi? Io voglio esportare tutto ciò che c'è in public.
>>
>> Il giorno 6 febbraio 2018 21:00, Totò Fiandaca > > ha scritto:
>>
>>> massimiliano,
>>> stai attento agli spazi (tra NO e -f  "SQLite" occorre uno spazio)
>>> inoltre, meglio esplicitarlo: al posto degli ** occorre mettere
>>> password
>>>
>>> poi, non mettere intero percorso del file sqlite ma solo il nome.sqlite;
>>> poi lo ritroverai sotto c:\utenti\nome_utente
>>>
>>> ciao
>>>
>>> Il giorno 6 febbraio 2018 19:47, Massimiliano Moraca <
>>> massimilianomor...@gmail.com> ha scritto:
>>>
 Luca sono su Windows 10

 Il giorno 6 febbraio 2018 19:46, Massimiliano Moraca <
 massimilianomor...@gmail.com> ha scritto:

> Totò mi sono "permesso" di apportare due piccole modifiche allo script
> e cioè yes al post di no per l'index ed ho inserito il percorso in cui mi
> deve creare il db sqlite:
>
> *ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO-f
> "SQLite" D:\Postgresql\export\puc_parete.sqlite -progress
> PG:"dbname=puc_parete  active_schema=public schemas=public host=localhost
> port=5432 user=postgres password= " -lco LAUNDER=yes -dsco
> SPATIALITE=yes -lco SPATIAL_INDEX=yes*
>
> Il risultato è stato questo:
>
> *FAILURE:*
> *Unable to open datasource `D:\Postgresql\export\puc_parete.sqlite'
> with the following drivers.*
>
> :(
>
> Esportare uno per uno i singoli vettore è l'estrema ratio che vorrei
> evitare
>
> Il giorno 6 febbraio 2018 11:45, Totò Fiandaca <
> pigrecoinfin...@gmail.com> ha scritto:
>
>> Ciao massimiliano,
>> io seguo questo articolo, funziona bene:
>>
>> https://pigrecoinfinito.wordpress.com/2017/11/28/da-postgis-
>> a-spatialite/
>>
>> Il giorno 6 febbraio 2018 11:40, Luca Delucchi 
>> ha scritto:
>>
>>> 2018-02-06 10:51 GMT+01:00 Massimiliano Moraca <
>>> massimilianomor...@gmail.com>:
>>> >
>>> >
>>> > parete_puc
>>> >
>>>
>>> scusa mi ero dimenticato che volevi esportare l'intero db... io ho
>>> fatto una prova con un mio di db e ha funzionato correttamente.
>>>
>>> Su che sistema operativo sei? (io uso linux)
>>>
>>> Sembrerebbe che non legga correttamente  "--config PG_LIST_ALL_TABLES
>>> YES" e che voglia un layer da convertire. prova a rimuovere il "-gt
>>> 65536/"
>>>
>>> --
>>> ciao
>>> Luca
>>>
>>> www.lucadelu.org
>>> ___
>>> 

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Massimiliano Moraca]

Ho fatto come mi hai detto Totò(password a parte che era chiaro :D) ed ora
ho questo messaggio:

*ERROR 1: PQconnectdb failed.*
*FATALE:  il database "puc_parete" non esiste*

*FAILURE:*
*Unable to open datasource `PG:dbname='puc_parete'  active_schema='public'
schemas='public' host='localhost' port='5432' user='postgres'
password='1983' ' with the following drivers.*

Nello script sul tuo blog c'è scritto *active_schema='public.data_2015'
schemas= 'public.data_2015'*, io ho lasciato solo public perchè credo che
il tuo script faccia riferimento ad una specifica tabella(*data_2015*).
Confermi? Io voglio esportare tutto ciò che c'è in public.

Il giorno 6 febbraio 2018 21:00, Totò Fiandaca 
ha scritto:

> massimiliano,
> stai attento agli spazi (tra NO e -f  "SQLite" occorre uno spazio)
> inoltre, meglio esplicitarlo: al posto degli ** occorre mettere
> password
>
> poi, non mettere intero percorso del file sqlite ma solo il nome.sqlite;
> poi lo ritroverai sotto c:\utenti\nome_utente
>
> ciao
>
> Il giorno 6 febbraio 2018 19:47, Massimiliano Moraca <
> massimilianomor...@gmail.com> ha scritto:
>
>> Luca sono su Windows 10
>>
>> Il giorno 6 febbraio 2018 19:46, Massimiliano Moraca <
>> massimilianomor...@gmail.com> ha scritto:
>>
>>> Totò mi sono "permesso" di apportare due piccole modifiche allo script e
>>> cioè yes al post di no per l'index ed ho inserito il percorso in cui mi
>>> deve creare il db sqlite:
>>>
>>> *ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO-f
>>> "SQLite" D:\Postgresql\export\puc_parete.sqlite -progress
>>> PG:"dbname=puc_parete  active_schema=public schemas=public host=localhost
>>> port=5432 user=postgres password= " -lco LAUNDER=yes -dsco
>>> SPATIALITE=yes -lco SPATIAL_INDEX=yes*
>>>
>>> Il risultato è stato questo:
>>>
>>> *FAILURE:*
>>> *Unable to open datasource `D:\Postgresql\export\puc_parete.sqlite' with
>>> the following drivers.*
>>>
>>> :(
>>>
>>> Esportare uno per uno i singoli vettore è l'estrema ratio che vorrei
>>> evitare
>>>
>>> Il giorno 6 febbraio 2018 11:45, Totò Fiandaca <
>>> pigrecoinfin...@gmail.com> ha scritto:
>>>
 Ciao massimiliano,
 io seguo questo articolo, funziona bene:

 https://pigrecoinfinito.wordpress.com/2017/11/28/da-postgis-
 a-spatialite/

 Il giorno 6 febbraio 2018 11:40, Luca Delucchi 
 ha scritto:

> 2018-02-06 10:51 GMT+01:00 Massimiliano Moraca <
> massimilianomor...@gmail.com>:
> >
> >
> > parete_puc
> >
>
> scusa mi ero dimenticato che volevi esportare l'intero db... io ho
> fatto una prova con un mio di db e ha funzionato correttamente.
>
> Su che sistema operativo sei? (io uso linux)
>
> Sembrerebbe che non legga correttamente  "--config PG_LIST_ALL_TABLES
> YES" e che voglia un layer da convertire. prova a rimuovere il "-gt
> 65536/"
>
> --
> ciao
> Luca
>
> www.lucadelu.org
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le
> posizioni dell'Associazione GFOSS.it.
> 796 iscritti al 28/12/2017
>



 --
 *Ing. Salvatore Fiandaca*
 *mobile*.:+39 327.493.8955 <+39%20327%20493%208955>
 *m*: *pigrecoinfin...@gmail.com *
 *C.F*.: FNDSVT71E29Z103G
 *P.IVA*: 06597870820
 *membro QGIS Italia - http://qgis.it/ *
 *socio GFOSS.it - *http://gfoss.it/
 *blog:*
 * https://pigrecoinfinito.wordpress.com/
  FB: Co-admin
 - https://www.facebook.com/qgis.it/ **
  *
 *FB: moderatore - **https://www.facebook.com/groups/GisItalia/
 **
  *
 *TW:  **https://twitter.com/totofiandaca
 *

 43°51'0.54"N  10°34'27.62"E - EPSG:4326

 “Se la conoscenza deve essere aperta a tutti,
 perchè mai limitarne l’accesso?”
 R. Stallman

 Questo documento, allegati inclusi, contiene informazioni di proprietà
 di FIANDACA SALVATORE e deve essere utilizzato esclusivamente dal
 destinatario in relazione alle finalità per le quali è stato ricevuto. E'
 vietata qualsiasi forma di riproduzione o divulgazione senza l'esplicito
 consenso di FIANDACA SALVATORE. Qualora fosse stato ricevuto per
 errore si prega di informare tempestivamente il mittente e distruggere la
 copia in proprio possesso.



>>>
>>
>
>
> --
> *Ing. Salvatore Fiandaca*
> *mobile*.:+39 327.493.8955 <+39%20327%20493%208955>
> *m*: 

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Massimiliano Moraca]

Luca sono su Windows 10

Il giorno 6 febbraio 2018 19:46, Massimiliano Moraca <
massimilianomor...@gmail.com> ha scritto:

> Totò mi sono "permesso" di apportare due piccole modifiche allo script e
> cioè yes al post di no per l'index ed ho inserito il percorso in cui mi
> deve creare il db sqlite:
>
> *ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO-f
> "SQLite" D:\Postgresql\export\puc_parete.sqlite -progress
> PG:"dbname=puc_parete  active_schema=public schemas=public host=localhost
> port=5432 user=postgres password= " -lco LAUNDER=yes -dsco
> SPATIALITE=yes -lco SPATIAL_INDEX=yes*
>
> Il risultato è stato questo:
>
> *FAILURE:*
> *Unable to open datasource `D:\Postgresql\export\puc_parete.sqlite' with
> the following drivers.*
>
> :(
>
> Esportare uno per uno i singoli vettore è l'estrema ratio che vorrei
> evitare
>
> Il giorno 6 febbraio 2018 11:45, Totò Fiandaca 
> ha scritto:
>
>> Ciao massimiliano,
>> io seguo questo articolo, funziona bene:
>>
>> https://pigrecoinfinito.wordpress.com/2017/11/28/da-postgis-a-spatialite/
>>
>> Il giorno 6 febbraio 2018 11:40, Luca Delucchi  ha
>> scritto:
>>
>>> 2018-02-06 10:51 GMT+01:00 Massimiliano Moraca <
>>> massimilianomor...@gmail.com>:
>>> >
>>> >
>>> > parete_puc
>>> >
>>>
>>> scusa mi ero dimenticato che volevi esportare l'intero db... io ho
>>> fatto una prova con un mio di db e ha funzionato correttamente.
>>>
>>> Su che sistema operativo sei? (io uso linux)
>>>
>>> Sembrerebbe che non legga correttamente  "--config PG_LIST_ALL_TABLES
>>> YES" e che voglia un layer da convertire. prova a rimuovere il "-gt
>>> 65536/"
>>>
>>> --
>>> ciao
>>> Luca
>>>
>>> www.lucadelu.org
>>> ___
>>> Gfoss@lists.gfoss.it
>>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>>> Questa e' una lista di discussione pubblica aperta a tutti.
>>> I messaggi di questa lista non hanno relazione diretta con le posizioni
>>> dell'Associazione GFOSS.it.
>>> 796 iscritti al 28/12/2017
>>>
>>
>>
>>
>> --
>> *Ing. Salvatore Fiandaca*
>> *mobile*.:+39 327.493.8955 <+39%20327%20493%208955>
>> *m*: *pigrecoinfin...@gmail.com *
>> *C.F*.: FNDSVT71E29Z103G
>> *P.IVA*: 06597870820
>> *membro QGIS Italia - http://qgis.it/ *
>> *socio GFOSS.it - *http://gfoss.it/
>> *blog:*
>> * https://pigrecoinfinito.wordpress.com/
>>  FB: Co-admin
>> - https://www.facebook.com/qgis.it/ **
>>  *
>> *FB: moderatore - **https://www.facebook.com/groups/GisItalia/
>> **
>>  *
>> *TW:  **https://twitter.com/totofiandaca
>> *
>>
>> 43°51'0.54"N  10°34'27.62"E - EPSG:4326
>>
>> “Se la conoscenza deve essere aperta a tutti,
>> perchè mai limitarne l’accesso?”
>> R. Stallman
>>
>> Questo documento, allegati inclusi, contiene informazioni di proprietà di
>> FIANDACA SALVATORE e deve essere utilizzato esclusivamente dal destinatario
>> in relazione alle finalità per le quali è stato ricevuto. E' vietata
>> qualsiasi forma di riproduzione o divulgazione senza l'esplicito consenso
>> di FIANDACA SALVATORE. Qualora fosse stato ricevuto per errore si prega
>> di informare tempestivamente il mittente e distruggere la copia in proprio
>> possesso.
>>
>>
>>
>
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Massimiliano Moraca]

Totò mi sono "permesso" di apportare due piccole modifiche allo script e
cioè yes al post di no per l'index ed ho inserito il percorso in cui mi
deve creare il db sqlite:

*ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO-f
"SQLite" D:\Postgresql\export\puc_parete.sqlite -progress
PG:"dbname=puc_parete  active_schema=public schemas=public host=localhost
port=5432 user=postgres password= " -lco LAUNDER=yes -dsco
SPATIALITE=yes -lco SPATIAL_INDEX=yes*

Il risultato è stato questo:

*FAILURE:*
*Unable to open datasource `D:\Postgresql\export\puc_parete.sqlite' with
the following drivers.*

:(

Esportare uno per uno i singoli vettore è l'estrema ratio che vorrei
evitare

Il giorno 6 febbraio 2018 11:45, Totò Fiandaca 
ha scritto:

> Ciao massimiliano,
> io seguo questo articolo, funziona bene:
>
> https://pigrecoinfinito.wordpress.com/2017/11/28/da-postgis-a-spatialite/
>
> Il giorno 6 febbraio 2018 11:40, Luca Delucchi  ha
> scritto:
>
>> 2018-02-06 10:51 GMT+01:00 Massimiliano Moraca <
>> massimilianomor...@gmail.com>:
>> >
>> >
>> > parete_puc
>> >
>>
>> scusa mi ero dimenticato che volevi esportare l'intero db... io ho
>> fatto una prova con un mio di db e ha funzionato correttamente.
>>
>> Su che sistema operativo sei? (io uso linux)
>>
>> Sembrerebbe che non legga correttamente  "--config PG_LIST_ALL_TABLES
>> YES" e che voglia un layer da convertire. prova a rimuovere il "-gt
>> 65536/"
>>
>> --
>> ciao
>> Luca
>>
>> www.lucadelu.org
>> ___
>> Gfoss@lists.gfoss.it
>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>> Questa e' una lista di discussione pubblica aperta a tutti.
>> I messaggi di questa lista non hanno relazione diretta con le posizioni
>> dell'Associazione GFOSS.it.
>> 796 iscritti al 28/12/2017
>>
>
>
>
> --
> *Ing. Salvatore Fiandaca*
> *mobile*.:+39 327.493.8955 <+39%20327%20493%208955>
> *m*: *pigrecoinfin...@gmail.com *
> *C.F*.: FNDSVT71E29Z103G
> *P.IVA*: 06597870820
> *membro QGIS Italia - http://qgis.it/ *
> *socio GFOSS.it - *http://gfoss.it/
> *blog:*
> * https://pigrecoinfinito.wordpress.com/
>  FB: Co-admin
> - https://www.facebook.com/qgis.it/ **
>  *
> *FB: moderatore - **https://www.facebook.com/groups/GisItalia/
> **
>  *
> *TW:  **https://twitter.com/totofiandaca
> *
>
> 43°51'0.54"N  10°34'27.62"E - EPSG:4326
>
> “Se la conoscenza deve essere aperta a tutti,
> perchè mai limitarne l’accesso?”
> R. Stallman
>
> Questo documento, allegati inclusi, contiene informazioni di proprietà di
> FIANDACA SALVATORE e deve essere utilizzato esclusivamente dal destinatario
> in relazione alle finalità per le quali è stato ricevuto. E' vietata
> qualsiasi forma di riproduzione o divulgazione senza l'esplicito consenso
> di FIANDACA SALVATORE. Qualora fosse stato ricevuto per errore si prega
> di informare tempestivamente il mittente e distruggere la copia in proprio
> possesso.
>
>
>
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Totò Fiandaca]

Ciao massimiliano,
io seguo questo articolo, funziona bene:

https://pigrecoinfinito.wordpress.com/2017/11/28/da-postgis-a-spatialite/

Il giorno 6 febbraio 2018 11:40, Luca Delucchi  ha
scritto:

> 2018-02-06 10:51 GMT+01:00 Massimiliano Moraca <
> massimilianomor...@gmail.com>:
> >
> >
> > parete_puc
> >
>
> scusa mi ero dimenticato che volevi esportare l'intero db... io ho
> fatto una prova con un mio di db e ha funzionato correttamente.
>
> Su che sistema operativo sei? (io uso linux)
>
> Sembrerebbe che non legga correttamente  "--config PG_LIST_ALL_TABLES
> YES" e che voglia un layer da convertire. prova a rimuovere il "-gt
> 65536/"
>
> --
> ciao
> Luca
>
> www.lucadelu.org
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 796 iscritti al 28/12/2017
>



-- 
*Ing. Salvatore Fiandaca*
*mobile*.:+39 327.493.8955
*m*: *pigrecoinfin...@gmail.com *
*C.F*.: FNDSVT71E29Z103G
*P.IVA*: 06597870820
*membro QGIS Italia - http://qgis.it/ *
*socio GFOSS.it - *http://gfoss.it/
*blog:*
* https://pigrecoinfinito.wordpress.com/
 FB: Co-admin
- https://www.facebook.com/qgis.it/ **
 *
*FB: moderatore - **https://www.facebook.com/groups/GisItalia/
**
 *
*TW:  **https://twitter.com/totofiandaca
*

43°51'0.54"N  10°34'27.62"E - EPSG:4326

“Se la conoscenza deve essere aperta a tutti,
perchè mai limitarne l’accesso?”
R. Stallman

Questo documento, allegati inclusi, contiene informazioni di proprietà di
FIANDACA SALVATORE e deve essere utilizzato esclusivamente dal destinatario
in relazione alle finalità per le quali è stato ricevuto. E' vietata
qualsiasi forma di riproduzione o divulgazione senza l'esplicito consenso
di FIANDACA SALVATORE. Qualora fosse stato ricevuto per errore si prega di
informare tempestivamente il mittente e distruggere la copia in proprio
possesso.
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Luca Delucchi]

2018-02-06 10:51 GMT+01:00 Massimiliano Moraca :
>
>
> parete_puc
>

scusa mi ero dimenticato che volevi esportare l'intero db... io ho
fatto una prova con un mio di db e ha funzionato correttamente.

Su che sistema operativo sei? (io uso linux)

Sembrerebbe che non legga correttamente  "--config PG_LIST_ALL_TABLES
YES" e che voglia un layer da convertire. prova a rimuovere il "-gt
65536/"

-- 
ciao
Luca

www.lucadelu.org
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Massimiliano Moraca]

2018-02-06 10:44 GMT+01:00 Luca Delucchi :

> 2018-02-06 10:40 GMT+01:00 Massimiliano Moraca <
> massimilianomor...@gmail.com>:
> > Tolto ed ora mi compare questo:
> >
> > ERROR 1: Couldn't fetch requested layer '\'!
> >
>
> il layer come si chiama?
>
>
parete_puc
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Luca Delucchi]

2018-02-06 10:40 GMT+01:00 Massimiliano Moraca :
> Tolto ed ora mi compare questo:
>
> ERROR 1: Couldn't fetch requested layer '\'!
>

il layer come si chiama?

-- 
ciao
Luca

www.lucadelu.org
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Massimiliano Moraca]

Tolto ed ora mi compare questo:

*ERROR 1: Couldn't fetch requested layer '\'!*

Il giorno 6 febbraio 2018 10:38, Luca Delucchi  ha
scritto:

> 2018-02-06 10:29 GMT+01:00 Massimiliano Moraca <
> massimilianomor...@gmail.com>:
> > Buongiorno,
>
> ciao
>
>
> > ___
> > Ho ricontrollato la stringa ma mi sembra apposto e coincide con quella al
> > link[0]. La incollo di seguito:
> > ___
> > /ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEW YES -f
> > "SQLite" D:\Postgresql\export\miodb.sqlite -progress PG:"dbname='miodb'
> \
> > active_schema=public schemas=public host='localhost' port='5432'
> > user='postgres' password='' " -lco LAUNDER=yes \ -dsco SPATIALITE=yes
> > -lco SPATIAL_INDEX=yes -gt 65536/
> > ___
> > Dove sto sbagliando?
> >
>
> c'è uno \ di troppo dopo 'miodb'
>
> ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEW YES -f
>  "SQLite" D:\Postgresql\export\miodb.sqlite -progress PG:"dbname='miodb'
>  active_schema=public schemas=public host='localhost' port='5432'
>  user='postgres' password='' " -lco LAUNDER=yes  -dsco SPATIALITE=yes
>  -lco SPATIAL_INDEX=yes -gt 65536/
>
> --
> ciao
> Luca
>
> www.lucadelu.org
>
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Export PostGIS - SpatiaLITE

[Luca Delucchi]

2018-02-06 10:29 GMT+01:00 Massimiliano Moraca :
> Buongiorno,

ciao


> ___
> Ho ricontrollato la stringa ma mi sembra apposto e coincide con quella al
> link[0]. La incollo di seguito:
> ___
> /ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEW YES -f
> "SQLite" D:\Postgresql\export\miodb.sqlite -progress PG:"dbname='miodb' \
> active_schema=public schemas=public host='localhost' port='5432'
> user='postgres' password='' " -lco LAUNDER=yes \ -dsco SPATIALITE=yes
> -lco SPATIAL_INDEX=yes -gt 65536/
> ___
> Dove sto sbagliando?
>

c'è uno \ di troppo dopo 'miodb'

ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEW YES -f
 "SQLite" D:\Postgresql\export\miodb.sqlite -progress PG:"dbname='miodb'
 active_schema=public schemas=public host='localhost' port='5432'
 user='postgres' password='' " -lco LAUNDER=yes  -dsco SPATIALITE=yes
 -lco SPATIAL_INDEX=yes -gt 65536/

-- 
ciao
Luca

www.lucadelu.org
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017