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, <a.furi...@lqt.it> 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 _______________________________________________ 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