Mi rispondo da solo dicendo che devo applicare il tutto nel post esportazione in SpatiaLite.
A questa però non sono arrivato... Un'altra cosa che non mi è chiara, e l'ho verificata anche in PostGIS: come > è possibile che da una intersezione di due vettori MultiPolygon ne venga > fuori uno che è sia Polygon che MultiPolygon? E' il caso della > cuas09_select che ho intersecato con il vettore ambito; entrambi i dati li > trovate nel db che ho condiviso qualche settimana fa e che ricondivido qui: > https://drive.google.com/open?id=1WGJuUutyBO3_wqkQkth-flQTn5E-CAFe Il giorno 24 febbraio 2018 19:01, Massimiliano Moraca < massimilianomor...@gmail.com> ha scritto: > Buonasera a tutti, vi scrivo dopo un po' per aggiornarvi. > Senza fare alcuna modifica al db esportato da PostGIS ed usando un > semplice drag&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 <aperi2...@gmail.com> ha > scritto: > >> Infatti. >> Il drag-drop usa il driver gdal ma lo usa in modo semplificato. >> La piu' grande differenza che io ho riscontrato e' quando ho una tabella >> con piu' campi geometrici. >> Il driver spatialite le intercetta tutte e le distingue. Ovvero ti mostra >> la lista con tutti i campi geometrici tra cui scegliere. >> Il dragndrop analizza la tabella e si colloca sul primo campo geometrico >> che incontra. >> >> Altra differenza. Il driver spatialite controlla se le statistiche della >> tabella sono riempite e se rileva che non sono valorizzate le valorizza >> prima di usare la geometria. >> Questo a volte provoca dei ritardi di reazione, ma solo la prima volta, >> poi e' piu' veloce e le statistiche aiutano. >> >> Il driver drag-drop ignora la cosa. Se sono presenti bene, altrimenti >> ciccia. >> >> A. >> >> >> Il giorno 7 febbraio 2018 21:51, Totò Fiandaca <pigrecoinfin...@gmail.com >> > ha scritto: >> >>> controlla bene, la tabella comuni_ambito che aveva inizialmente 23 >>> righe, dopo dragAndDrop risultano 22. >>> >>> meglio seguire la procedura descritta e non usare il dragAndDrop che, >>> credo, non passi per ogr. >>> >>> notte >>> >>> Il giorno 7 febbraio 2018 21:45, Massimiliano Moraca < >>> massimilianomor...@gmail.com> ha scritto: >>> >>>> Salvatore ho fatto come hai indicato ed effettivamente vengono caricati >>>> tutti i layer in maniera corretta(perchè dici che spariscono le geometrie, >>>> a me sono comparse tutte). Quindi potrei bypassare il problema facendo >>>> così? O devo per forza seguire le procedure che sono state indicate nei >>>> vari interventi? >>>> Alla fine ho effettuato questa esportazione per comodità(devo portarmi >>>> appresso solo due file: progetto qgis e db al posto dei tanti shp) di >>>> esportazione in questa fase di raccolta dati; poi tutto sarà a dimora su >>>> PostGIS. >>>> >>>> Il giorno 7 febbraio 2018 21:36, Totò Fiandaca < >>>> pigrecoinfin...@gmail.com> ha scritto: >>>> >>>>> aggiungo, solo ai fini di aver un quadro più completo, che aggiungendo >>>>> il database spatialite (creato con la procedura esposta in questo thread) >>>>> non con il provider spatialite ma con il dragAndDrop tutte le tabelle >>>>> vengono lette da QGIS; alcune stranezze riscontrate: scomparsa di >>>>> poligoni; >>>>> geometrie definite multipoligono vengono lette come poligoni. >>>>> >>>>> notte >>>>> >>>>> Il giorno 7 febbraio 2018 21:25, Massimiliano Moraca < >>>>> massimilianomor...@gmail.com> ha scritto: >>>>> >>>>>> Grazie a tutti per le risposte. >>>>>> Ancora non ho avuto modo di applicare le indicazioni che mi avete >>>>>> dato, spero di farlo questo fine settimana. Vi tengo aggiornati. >>>>>> >>>>>> Il giorno 7 febbraio 2018 18:48, Andrea Peri <aperi2...@gmail.com> >>>>>> ha scritto: >>>>>> >>>>>>> Grazie a te che scrivendo articoli crei una base di letture da cui >>>>>>> un nuovo >>>>>>> utente può partire per navigare in questo complicato universo. >>>>>>> >>>>>>> Il 07 Feb 2018 18:25, "Totò Fiandaca" <pigrecoinfin...@gmail.com> ha >>>>>>> scritto: >>>>>>> >>>>>>> > Vorrei esprimere la mia gratitudine a Andrea Peri e Alessandro >>>>>>> Furieri per >>>>>>> > le spiegazioni, chiare ed efficaci. >>>>>>> > >>>>>>> > Ho fatto delle prove sul db messo a disposizione da Massimiliano, >>>>>>> seguendo >>>>>>> > i consigli di Furieri, tutto funziona alla perfezione. >>>>>>> > >>>>>>> > grazie >>>>>>> > >>>>>>> > forse scriverò un articolo su questo thread. >>>>>>> > >>>>>>> > saluti >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > Il giorno 7 febbraio 2018 12:53, <a.furi...@lqt.it> ha scritto: >>>>>>> > >>>>>>> > > On Wed, 7 Feb 2018 12:06:06 +0100, Totò Fiandaca wrote: >>>>>>> > > >>>>>>> > >> correggetemi se dico fesserie: >>>>>>> > >> >>>>>>> > >> una soluzione sarebbe quella di aggiungere un altro campo >>>>>>> geometry (es: >>>>>>> > >> geom, definirlo per bene) alle tabelle e popolarle con la >>>>>>> geometria con >>>>>>> > un >>>>>>> > >> UPDATE. >>>>>>> > >> >>>>>>> > >> credo funzioni. >>>>>>> > >> >>>>>>> > >> >>>>>>> > > si, dovrebbe funzionare, ma il percorso da seguire per >>>>>>> > > fare un lavoro ben fatto e' un po' piu' complesso: >>>>>>> > > >>>>>>> > > - per prima cosa occorre verificare cosa contiene >>>>>>> > > esattamente il dataset; basta eseguire la seguente >>>>>>> > > query SQL: >>>>>>> > > >>>>>>> > > SELECT Count(*), GeometryType(geom), Srid(geom), >>>>>>> CoordDimension(geom) >>>>>>> > > FROM table >>>>>>> > > GROUP BY 2, 3, 4; >>>>>>> > > >>>>>>> > > n.b. chi usa spatialite_gui puo' usare direttamente >>>>>>> > > il tool "check geometries" dal menu associato a quella >>>>>>> > > particolare colonna-geometria. >>>>>>> > > >>>>>>> > > - a questo punto tutto dipende dai risultati della >>>>>>> > > query precedente. >>>>>>> > > >>>>>>> > > caso #1 >>>>>>> > > =============== >>>>>>> > > nel resultset appare una singola riga. >>>>>>> > > basta creare la seconda colonna-geometria con gli >>>>>>> > > argomenti appropriati, p.es. >>>>>>> > > >>>>>>> > > SELECT AddGeometryColumn('table', 'geom2', srid, 'POINT', 'XY'); >>>>>>> > > >>>>>>> > > a questo punto si procede direttamente al popolamento >>>>>>> > > della nuova colonna-geometria: >>>>>>> > > >>>>>>> > > UPDATE table SET geom2 = geom; >>>>>>> > > >>>>>>> > > >>>>>>> > > caso #2 >>>>>>> > > =============== >>>>>>> > > nel resultset appaiono un paio di righe, ma >>>>>>> > > tutte con il medesimo modello dimensionale e >>>>>>> > > con tipi geometrici compatibili, uno di tipo >>>>>>> > > single-part e l'altro di tipo multi-part >>>>>>> > > (p.es. POINT e MULTIPOINT, oppure POLYGON >>>>>>> > > e MULTIPOLYGON). >>>>>>> > > >>>>>>> > > a questo punto occorre creare la seconda >>>>>>> > > colonna-geometria stando ben attenti a >>>>>>> > > specificare il MultiType: >>>>>>> > > >>>>>>> > > SELECT AddGeometryColumn('table', 'geom2', srid, 'MULTIPOLYGON', >>>>>>> 'XY'); >>>>>>> > > >>>>>>> > > infine si procede al popolamento della >>>>>>> > > seconda colonna-geometria applicando un >>>>>>> > > opportuno operatore di cast, tale da >>>>>>> > > forzare il geometry-type per uniformare >>>>>>> > > tutte le geometrie al caso multi-part: >>>>>>> > > >>>>>>> > > UPDATE table SET geom2 = CastToMultiPolygon(geom); >>>>>>> > > >>>>>>> > > >>>>>>> > > caso #3 >>>>>>> > > =============== >>>>>>> > > nel resultset appaiono svariate righe, con >>>>>>> > > geometry-type incompatibili (p.es. POINT, >>>>>>> > > LINESTRING e MULTIPOLYGON). >>>>>>> > > >>>>>>> > > in questo caso non e' possibile procedere >>>>>>> > > ad una conversione diretta, andranno create >>>>>>> > > tante colonne-geometria quanti sono i >>>>>>> > > geometry-types, e durante la fase di popolamento >>>>>>> > > le geometrie andranno opportunamente filtrate >>>>>>> > > in base al tipo. >>>>>>> > > >>>>>>> > > ciao Sandro >>>>>>> > > >>>>>>> > > >>>>>>> > > poi, il provider spatialite di QGIS vedrebbe due colonne >>>>>>> geometriche >>>>>>> > dello >>>>>>> > >> stesso strato. >>>>>>> > >> >>>>>>> > >> _______________________________________________ >>>>>>> > > Gfoss@lists.gfoss.it >>>>>>> > > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss >>>>>>> > > Questa e' una lista di discussione pubblica aperta a tutti. >>>>>>> > > I messaggi di questa lista non hanno relazione diretta con le >>>>>>> posizioni >>>>>>> > > dell'Associazione GFOSS.it. >>>>>>> > > 796 iscritti al 28/12/2017 >>>>>>> > > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > -- >>>>>>> > *Ing. Salvatore Fiandaca* >>>>>>> > *mobile*.:+39 327.493.8955 >>>>>>> > *m*: *pigrecoinfin...@gmail.com <pigrecoinfin...@gmail.com>* >>>>>>> > *C.F*.: FNDSVT71E29Z103G >>>>>>> > *P.IVA*: 06597870820 >>>>>>> > *membro QGIS Italia - http://qgis.it/ <http://qgis.it/>* >>>>>>> > *socio GFOSS.it - *http://gfoss.it/ >>>>>>> > *blog:* >>>>>>> > * https://pigrecoinfinito.wordpress.com/ >>>>>>> > <https://pigrecoinfinito.wordpress.com/> FB: Co-admin >>>>>>> > - https://www.facebook.com/qgis.it/ <https://www.facebook.com/qgis >>>>>>> .it/>** >>>>>>> > <https://www.facebook.com/qgis.it/> * >>>>>>> > *FB: moderatore - **https://www.facebook.com/groups/GisItalia/ >>>>>>> > <https://www.facebook.com/groups/GisItalia/>** >>>>>>> > <https://www.facebook.com/groups/GisItalia/> * >>>>>>> > *TW: <http://goog_95411464>**https://twitter.com/totofiandaca >>>>>>> > <https://twitter.com/totofiandaca>* >>>>>>> > >>>>>>> > 43°51'0.54"N 10°34'27.62"E - EPSG:4326 >>>>>>> > >>>>>>> > “Se la conoscenza deve essere aperta a tutti, >>>>>>> > perchè mai limitarne l’accesso?” >>>>>>> > R. Stallman >>>>>>> > >>>>>>> > Questo documento, allegati inclusi, contiene informazioni di >>>>>>> proprietà di >>>>>>> > FIANDACA SALVATORE e deve essere utilizzato esclusivamente dal >>>>>>> destinatario >>>>>>> > in relazione alle finalità per le quali è stato ricevuto. E' >>>>>>> vietata >>>>>>> > qualsiasi forma di riproduzione o divulgazione senza l'esplicito >>>>>>> consenso >>>>>>> > di FIANDACA SALVATORE. Qualora fosse stato ricevuto per errore si >>>>>>> prega di >>>>>>> > informare tempestivamente il mittente e distruggere la copia in >>>>>>> proprio >>>>>>> > possesso. >>>>>>> > _______________________________________________ >>>>>>> > Gfoss@lists.gfoss.it >>>>>>> > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss >>>>>>> > Questa e' una lista di discussione pubblica aperta a tutti. >>>>>>> > I messaggi di questa lista non hanno relazione diretta con le >>>>>>> posizioni >>>>>>> > dell'Associazione GFOSS.it. >>>>>>> > 796 iscritti al 28/12/2017 >>>>>>> _______________________________________________ >>>>>>> Gfoss@lists.gfoss.it >>>>>>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss >>>>>>> Questa e' una lista di discussione pubblica aperta a tutti. >>>>>>> I messaggi di questa lista non hanno relazione diretta con le >>>>>>> posizioni dell'Associazione GFOSS.it. >>>>>>> 796 iscritti al 28/12/2017 >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Ing. Salvatore Fiandaca* >>>>> *mobile*.:+39 327.493.8955 <+39%20327%20493%208955> >>>>> *m*: *pigrecoinfin...@gmail.com <pigrecoinfin...@gmail.com>* >>>>> *C.F*.: FNDSVT71E29Z103G >>>>> *P.IVA*: 06597870820 >>>>> *membro QGIS Italia - http://qgis.it/ <http://qgis.it/>* >>>>> *socio GFOSS.it - *http://gfoss.it/ >>>>> *blog:* >>>>> * https://pigrecoinfinito.wordpress.com/ >>>>> <https://pigrecoinfinito.wordpress.com/> FB: Co-admin >>>>> - https://www.facebook.com/qgis.it/ <https://www.facebook.com/qgis.it/>** >>>>> <https://www.facebook.com/qgis.it/> * >>>>> *FB: moderatore - **https://www.facebook.com/groups/GisItalia/ >>>>> <https://www.facebook.com/groups/GisItalia/>** >>>>> <https://www.facebook.com/groups/GisItalia/> * >>>>> *TW: <http://goog_95411464>**https://twitter.com/totofiandaca >>>>> <https://twitter.com/totofiandaca>* >>>>> >>>>> 43°51'0.54"N 10°34'27.62"E - EPSG:4326 >>>>> >>>>> “Se la conoscenza deve essere aperta a tutti, >>>>> perchè mai limitarne l’accesso?” >>>>> R. Stallman >>>>> >>>>> Questo documento, allegati inclusi, contiene informazioni di proprietà >>>>> di FIANDACA SALVATORE e deve essere utilizzato esclusivamente dal >>>>> destinatario in relazione alle finalità per le quali è stato ricevuto. E' >>>>> vietata qualsiasi forma di riproduzione o divulgazione senza l'esplicito >>>>> consenso di FIANDACA SALVATORE. Qualora fosse stato ricevuto per >>>>> errore si prega di informare tempestivamente il mittente e distruggere la >>>>> copia in proprio possesso. >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> *Ing. Salvatore Fiandaca* >>> *mobile*.:+39 327.493.8955 <+39%20327%20493%208955> >>> *m*: *pigrecoinfin...@gmail.com <pigrecoinfin...@gmail.com>* >>> *C.F*.: FNDSVT71E29Z103G >>> *P.IVA*: 06597870820 >>> *membro QGIS Italia - http://qgis.it/ <http://qgis.it/>* >>> *socio GFOSS.it - *http://gfoss.it/ >>> *blog:* >>> * https://pigrecoinfinito.wordpress.com/ >>> <https://pigrecoinfinito.wordpress.com/> FB: Co-admin >>> - https://www.facebook.com/qgis.it/ <https://www.facebook.com/qgis.it/>** >>> <https://www.facebook.com/qgis.it/> * >>> *FB: moderatore - **https://www.facebook.com/groups/GisItalia/ >>> <https://www.facebook.com/groups/GisItalia/>** >>> <https://www.facebook.com/groups/GisItalia/> * >>> *TW: <http://goog_95411464>**https://twitter.com/totofiandaca >>> <https://twitter.com/totofiandaca>* >>> >>> 43°51'0.54"N 10°34'27.62"E - EPSG:4326 >>> >>> “Se la conoscenza deve essere aperta a tutti, >>> perchè mai limitarne l’accesso?” >>> R. Stallman >>> >>> Questo documento, allegati inclusi, contiene informazioni di proprietà >>> di FIANDACA SALVATORE e deve essere utilizzato esclusivamente dal >>> destinatario in relazione alle finalità per le quali è stato ricevuto. E' >>> vietata qualsiasi forma di riproduzione o divulgazione senza l'esplicito >>> consenso di FIANDACA SALVATORE. Qualora fosse stato ricevuto per errore >>> si prega di informare tempestivamente il mittente e distruggere la copia in >>> proprio possesso. >>> >>> >>> >> >> >> -- >> ----------------- >> Andrea Peri >> . . . . . . . . . >> qwerty àèìòù >> ----------------- >> > > _______________________________________________ Gfoss@lists.gfoss.it http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017