Riparare geometria???

[Andrea Peri]

>Un momento, signori: "validazione" e' una cosa, "riparazione" e' un'altra.
>
>Se Postgis e/o Spatialite, come fa Qgis, si limitano a dire "Ehi, ho trovato
>1000 errori, qui e la', mettili a posto, e rifatti vivo", allora non credo
>sia una soluzione accettabile per Emanuela.
>
>Qualora invece siano in grado di "aggiustare" in automatico una shape
>devastata come fa l'impressionante MAPCLEAN suddetto, beh, tanto di
>cappello.


La funzione ST_MakeValid è stata inserita nella libreria LibWGeom resa
nel compempo "indipendente da postgis", nel senso che si puo' usare
senza avere installato un intero postgres/postgis.
Successivamente tale libreria libwgeom è stata inserita nel rilascio
di spatialite 4.0 e roba di questi giorni viene inserita anche nel
plugin sextante di qgis.

Per cui si puo' usare fin da suibito postgis 2.0 oppure spatialite 4.0
per validare (nel senso di riparare e riportarsi a una geometria
valida) una geometria altrimenti non valida.

Una delle constraint forti nella funzione ST_MakeValid è
"non perdere alcun vertice".
Questo perche' ogni vertice "costa" e una funzione di rende una
geometria valida rimuovendo vertici non sempre va bene.

Questo ha comportato che spesso la correzione di una geometria porta a
una geometria di altro tipo:

esempio:
ci puo' essere il classico poligono col fiocchetto, la sua correzione
comporta la suddivisione di tale geometrie in due parti.
La ST_MakeValid() in questo caso per correggere una geometria di tipo
POLYGON genera una MultiPolygon.

Questo perche' non si vuole generare due records distinti.

La ragione di questa scelta è che due records distinti potrebbero
avere una collisione sulla chiave primaria o su un qualche campo
univoco.
Per cui si preferisce generare una MultiPolygon.

In altre situazioni la correzione di una polygon puo' portare alla
nasciat di una "collection", ad esmepio perche' ci si trova di fronte
a un
poligono con una linea interna (il classico caso dell' hole che per
cause "esterne" è stato collassato in una linea o addirittura in un
punto.

Per cui a seguito della ST_MAkeValid() si deve sempre pensare di
appoggiare il risultato su una tabella terza avente la polygon e poi
fare un nuovo passaggio elbirativo che estragga i contenuti nel senso
che si desidera.

Se si lavora con postgis si puo' anche fare tutto in una sola passata,
su spatialite serve una tabella temporanea su cui appoggiare i
risultati della ST_MakeValid .
Poi si da' una occhiata ai risultati con una "select distinct
st_geometrytype" e si decide come spacchettarli.

Alla fine si ottiene tutte  le geoetrie ripulite e pronte a essere
sostituite con un update nella tabella originale (o in altra se si
vuole conservare quelle originali).

Un caso a parte è il caso del famoso caso del "buco che tocca il contorno".
Infatti esiste un differente interpretazione tra ESRI e
rest-of-the-world su come si traccia un poligono avente un bco in
touch sul contorno.
Questa differente interpretzione fa si che per un qualsiasi sistema
OGC compliant (copreso autocad-map credo) questo caso è una
invalidita', mentre per esri no.

Questo porta a una situazione assurda, per cui uno shapefile in cui ci
sono poligoni di questo tipo se veogno "editati con prodotti esri
vengono ricondotti a questa situazione esri-compliant, e diventano
invalidi per ogni altro software.

Essendo invalidi finiscono per non essere usabili in altri contesti.

Uno dei grandi meriti di ST_MAkeValid è che riporta questa situazione
a essere OGC-compliant.

Per cui se ci sono poligoni con tale situazione la st_makevalid li
rende compliant con OGC.

Poiche nel corso della vita di uno shapefile la possibilita' che venga
rieditato da prodotti esri è elevata, essendo il software piu' usato e
piu' diffuso, il poter sempre riportare un oligono a essere OGC
complinat è una cosa assolutamente fondamentale.

Per cui , la ST_MakeValid è certamente di aiuto.
E come dicevo presto sara' accessibile anche su sextante.

Saluti,

--
-----------------
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.
638 iscritti al 28.2.2013

[Novarese]

Ottima info, grazie.

Senti, appena hai un attimo libero, mi faresti la seguente cortesia?

Intrigato dalla faccenda della "ciambella col buco tangente all'intradosso", ho disegnato un cerchio circoscritto alla shape Istat del mio Comune, a cui ho sottratto un secondo cerchio tangente al suo quadrante est, e passante per il suo centro.

Ho infine esportato tutto come shape poligonale in EPSG:32632, che ti allego:
http://ge.tt/9tNXNpZ/v/0?c

Gentilmente, potresti controllare se e', per usare la tua espressione, "OGC-compliant"..?

Buona serata!