[Gfoss] Export PostGIS - SpatiaLITE

Sab 24 Feb 2018 19:28:06 CET

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 <
massimilianomoraca a 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&drop 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 <aperi2007 a gmail.com> 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 <pigrecoinfinito a gmail.com
>> > 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 <
>>> massimilianomoraca a 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 <
>>>> pigrecoinfinito a 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 <
>>>>> massimilianomoraca a 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 <aperi2007 a gmail.com>
>>>>>> 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" <pigrecoinfinito a gmail.com> 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, <a.furieri a lqt.it> 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 a 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*: *pigrecoinfinito a gmail.com <pigrecoinfinito a gmail.com>*
>>>>>>> > *C.F*.: FNDSVT71E29Z103G
>>>>>>> > *P.IVA*: 06597870820
>>>>>>> > *membro QGIS Italia - http://qgis.it/ <http://qgis.it/>*
>>>>>>> > *socio GFOSS.it - *http://gfoss.it/
>>>>>>> > *blog:*
>>>>>>> > * https://pigrecoinfinito.wordpress.com/
>>>>>>> > <https://pigrecoinfinito.wordpress.com/> FB: Co-admin
>>>>>>> > - https://www.facebook.com/qgis.it/ <https://www.facebook.com/qgis
>>>>>>> .it/>**
>>>>>>> > <https://www.facebook.com/qgis.it/> *
>>>>>>> > *FB: moderatore - **https://www.facebook.com/groups/GisItalia/
>>>>>>> > <https://www.facebook.com/groups/GisItalia/>**
>>>>>>> > <https://www.facebook.com/groups/GisItalia/> *
>>>>>>> > *TW:  <http://goog_95411464>**https://twitter.com/totofiandaca
>>>>>>> > <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 a 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
>>>>>>> _______________________________________________
>>>>>>> Gfoss a 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*: *pigrecoinfinito a gmail.com <pigrecoinfinito a gmail.com>*
>>>>> *C.F*.: FNDSVT71E29Z103G
>>>>> *P.IVA*: 06597870820
>>>>> *membro QGIS Italia - http://qgis.it/ <http://qgis.it/>*
>>>>> *socio GFOSS.it - *http://gfoss.it/
>>>>> *blog:*
>>>>> * https://pigrecoinfinito.wordpress.com/
>>>>> <https://pigrecoinfinito.wordpress.com/> FB: Co-admin
>>>>> - https://www.facebook.com/qgis.it/ <https://www.facebook.com/qgis.it/>**
>>>>> <https://www.facebook.com/qgis.it/> *
>>>>> *FB: moderatore - **https://www.facebook.com/groups/GisItalia/
>>>>> <https://www.facebook.com/groups/GisItalia/>**
>>>>> <https://www.facebook.com/groups/GisItalia/> *
>>>>> *TW:  <http://goog_95411464>**https://twitter.com/totofiandaca
>>>>> <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*: *pigrecoinfinito a gmail.com <pigrecoinfinito a gmail.com>*
>>> *C.F*.: FNDSVT71E29Z103G
>>> *P.IVA*: 06597870820
>>> *membro QGIS Italia - http://qgis.it/ <http://qgis.it/>*
>>> *socio GFOSS.it - *http://gfoss.it/
>>> *blog:*
>>> * https://pigrecoinfinito.wordpress.com/
>>> <https://pigrecoinfinito.wordpress.com/> FB: Co-admin
>>> - https://www.facebook.com/qgis.it/ <https://www.facebook.com/qgis.it/>**
>>> <https://www.facebook.com/qgis.it/> *
>>> *FB: moderatore - **https://www.facebook.com/groups/GisItalia/
>>> <https://www.facebook.com/groups/GisItalia/>**
>>> <https://www.facebook.com/groups/GisItalia/> *
>>> *TW:  <http://goog_95411464>**https://twitter.com/totofiandaca
>>> <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.
>>>
>>>
>>>
>>
>>
>> --
>> -----------------
>> Andrea Peri
>> . . . . . . . . .
>> qwerty àèìòù
>> -----------------
>>
>
>