[Gfoss] Export PostGIS - SpatiaLITE

[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, <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