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" <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <
>>>> [hidden email]> 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 <
>>>> [hidden email]>
>>>> > 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 <
>>>> >> [hidden email]> 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 <
>>>> >>> [hidden email]> 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 <
>>>> >>>> [hidden email]> 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 <
>>>> >>>>> [hidden email]> 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 <
>>>> >>>>>> [hidden email]> ha scritto:
>>>> >>>>>>
>>>> >>>>>>> Luca sono su Windows 10
>>>> >>>>>>>
>>>> >>>>>>> Il giorno 6 febbraio 2018 19:46, Massimiliano Moraca <
>>>> >>>>>>> [hidden email]> 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_pare
>>>> te.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 <
>>>> >>>>>>>> [hidden email]> 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 <
>>>> >>>>>>>>> [hidden email]> ha scritto:
>>>> >>>>>>>>>
>>>> >>>>>>>>>> 2018-02-06 10:51 GMT+01:00 Massimiliano Moraca <
>>>> >>>>>>>>>> [hidden email]>:
>>>> >>>>>>>>>> >
>>>> >>>>>>>>>> >
>>>> >>>>>>>>>> > 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
>>>> >>>>>>>>>> _______________________________________________
>>>> >>>>>>>>>> [hidden email]
>>>> >>>>>>>>>> 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*: *[hidden email] <[hidden email]>*
>>>> >>>>>>>>> *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/gro
>>>> ups/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>
>>>> <+39%20327%20493%208955>
>>>> >>>>>> *m*: *[hidden email] <[hidden email]>*
>>>> >>>>>> *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>
>>>> <+39%20327%20493%208955>
>>>> >>>> *m*: *[hidden email] <[hidden email]>*
>>>> >>>> *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>
>>>> <+39%20327%20493%208955>
>>>> >> *m*: *[hidden email] <[hidden email]>*
>>>> >> *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*: *[hidden email] <[hidden email]>*
>>>> *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.
>>>> _______________________________________________
>>>> [hidden email]
>>>> 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*: *[hidden email] <[hidden email]>*
>> *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.
>>
>>
>>

_______________________________________________
[hidden email]
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

[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.
>
_______________________________________________
[hidden email]
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

[pigreco]

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, <[hidden email]> 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.
>>
>> _______________________________________________
> [hidden email]
> 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*: *[hidden email] <[hidden email]>*
*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.
_______________________________________________
[hidden email]
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

[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" <[hidden email]> 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, <[hidden email]> 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.
> >>
> >> _______________________________________________
> > [hidden email]
> > 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*: *[hidden email] <[hidden email]>*
> *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.
> _______________________________________________
> [hidden email]
> 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

_______________________________________________
[hidden email]
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

[Massimiliano Moraca]

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 <[hidden email]> 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" <[hidden email]> 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, <[hidden email]> 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.
> > >>
> > >> _______________________________________________
> > > [hidden email]
> > > 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*: *[hidden email] <[hidden email]>*
> > *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.
> > _______________________________________________
> > [hidden email]
> > 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
> _______________________________________________
> [hidden email]
> 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
>

_______________________________________________
[hidden email]
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

[pigreco]

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 <
[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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, <[hidden email]> 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.
>> > >>
>> > >> _______________________________________________
>> > > [hidden email]
>> > > 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*: *[hidden email] <[hidden email]>*
>> > *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.
>> > _______________________________________________
>> > [hidden email]
>> > 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
>> _______________________________________________
>> [hidden email]
>> 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*: *[hidden email] <[hidden email]>*
*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.
_______________________________________________
[hidden email]
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

[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 <[hidden email]>
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 <
> [hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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, <[hidden email]> 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.
>>> > >>
>>> > >> _______________________________________________
>>> > > [hidden email]
>>> > > 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*: *[hidden email] <[hidden email]>*
>>> > *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.
>>> > _______________________________________________
>>> > [hidden email]
>>> > 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
>>> _______________________________________________
>>> [hidden email]
>>> 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*: *[hidden email] <[hidden email]>*
> *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.
>
>
>

_______________________________________________
[hidden email]
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

[pigreco]

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 <
[hidden email]> 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 <[hidden email]>
> 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 <
>> [hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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, <[hidden email]> 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.
>>>> > >>
>>>> > >> _______________________________________________
>>>> > > [hidden email]
>>>> > > 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*: *[hidden email] <[hidden email]>*
>>>> > *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.
>>>> > _______________________________________________
>>>> > [hidden email]
>>>> > 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
>>>> _______________________________________________
>>>> [hidden email]
>>>> 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*: *[hidden email] <[hidden email]>*
>> *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
*m*: *[hidden email] <[hidden email]>*
*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.
_______________________________________________
[hidden email]
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

[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 <[hidden email]>
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 <
> [hidden email]> 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 <[hidden email]
>> > 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 <
>>> [hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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, <[hidden email]> 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.
>>>>> > >>
>>>>> > >> _______________________________________________
>>>>> > > [hidden email]
>>>>> > > 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*: *[hidden email] <[hidden email]>*
>>>>> > *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.
>>>>> > _______________________________________________
>>>>> > [hidden email]
>>>>> > 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
>>>>> _______________________________________________
>>>>> [hidden email]
>>>>> 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*: *[hidden email] <[hidden email]>*
>>> *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*: *[hidden email] <[hidden email]>*
> *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.
>
>
>

_______________________________________________
[hidden email]
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

[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 <[hidden email]>
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 <
> [hidden email]> 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 <[hidden email]
>> > 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 <
>>> [hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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, <[hidden email]> 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.
>>>>> > >>
>>>>> > >> _______________________________________________
>>>>> > > [hidden email]
>>>>> > > 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*: *[hidden email] <[hidden email]>*
>>>>> > *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.
>>>>> > _______________________________________________
>>>>> > [hidden email]
>>>>> > 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
>>>>> _______________________________________________
>>>>> [hidden email]
>>>>> 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*: *[hidden email] <[hidden email]>*
>>> *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*: *[hidden email] <[hidden email]>*
> *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 àèìòù
-----------------
_______________________________________________
[hidden email]
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

[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&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 <[hidden email]> 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 <[hidden email]>
> 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 <
>> [hidden email]> 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 <
>>> [hidden email]> 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 <
>>>> [hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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, <[hidden email]> 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.
>>>>>> > >>
>>>>>> > >> _______________________________________________
>>>>>> > > [hidden email]
>>>>>> > > 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*: *[hidden email] <[hidden email]>*
>>>>>> > *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.
>>>>>> > _______________________________________________
>>>>>> > [hidden email]
>>>>>> > 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
>>>>>> _______________________________________________
>>>>>> [hidden email]
>>>>>> 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*: *[hidden email] <[hidden email]>*
>>>> *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*: *[hidden email] <[hidden email]>*
>> *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 àèìòù
> -----------------
>

_______________________________________________
[hidden email]
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

[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 <
[hidden email]> 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 <[hidden email]> 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 <[hidden email]
>> > 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 <
>>> [hidden email]> 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 <
>>>> [hidden email]> 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 <
>>>>> [hidden email]> 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 <[hidden email]>
>>>>>> 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" <[hidden email]> 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, <[hidden email]> 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.
>>>>>>> > >>
>>>>>>> > >> _______________________________________________
>>>>>>> > > [hidden email]
>>>>>>> > > 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*: *[hidden email] <[hidden email]>*
>>>>>>> > *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.
>>>>>>> > _______________________________________________
>>>>>>> > [hidden email]
>>>>>>> > 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
>>>>>>> _______________________________________________
>>>>>>> [hidden email]
>>>>>>> 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*: *[hidden email] <[hidden email]>*
>>>>> *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*: *[hidden email] <[hidden email]>*
>>> *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 àèìòù
>> -----------------
>>
>
>

_______________________________________________
[hidden email]
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

[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&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:
>
> ---------------- <snip> --------------------
>
> 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' inammissibile; basta pero'
avere l'accortezza di usare sistematicamente gli operatori di
casting per aggirare l'ostacolo.

altre implementazioni sono piu' permissive, e consentono di
mescolare a gogo' POLYGON e MULTIPOLYGON; sicuramente torna
piu' comodo, ma non e' conforme allo standard.

ciao Sandro

_______________________________________________
[hidden email]
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

[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, <[hidden email]> 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&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:
>>
>> ---------------- <snip> --------------------
>>
>> 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' inammissibile; basta pero'
> avere l'accortezza di usare sistematicamente gli operatori di
> casting per aggirare l'ostacolo.
>
> altre implementazioni sono piu' permissive, e consentono di
> mescolare a gogo' POLYGON e MULTIPOLYGON; sicuramente torna
> piu' comodo, ma non e' conforme allo standard.
>
> ciao Sandro
>
>
> _______________________________________________
> [hidden email]
> 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
>

_______________________________________________
[hidden email]
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

[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, <[hidden email]> 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&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:
>
> ---------------- <snip> --------------------
>
>
> 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' inammissibile; basta pero'
avere l'accortezza di usare sistematicamente gli operatori di
casting per aggirare l'ostacolo.

altre implementazioni sono piu' permissive, e consentono di
mescolare a gogo' POLYGON e MULTIPOLYGON; sicuramente torna
piu' comodo, ma non e' conforme allo standard.

ciao Sandro


_______________________________________________
[hidden email]
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
_______________________________________________
[hidden email]
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

[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
_______________________________________________
[hidden email]
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

[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, <[hidden email]> 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 àèìòù
-----------------
_______________________________________________
[hidden email]
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

[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
_______________________________________________
[hidden email]
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