[Gfoss] Export PostGIS - SpatiaLITE

Sab 24 Feb 2018 21:19:08 CET

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, <a.furieri a 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 a lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 796 iscritti al 28/12/2017
>