[Gfoss] Riparare geometria???

[unknown]

Salve a tutti,

sto lavorando su uno shp della vegetazione e devo spezzare dei poligoni, ma non riesco a farlo, mi appare un errore di questo tipo:

La geometria non Ú valida. Riparala prima di tentare di dividerla.


Che devo fare per ripararla?


grazie in anticipo

Emanuela

Emanuela Maurizi, Ph.D.
University of Rome Tre
Department of Sciences
Viale G. Marconi, 446
00146, Rome, Italy
Phone: [phone]
Fax: [phone]
Mobile: [phone]
email: emanuela.maurizi a uniroma3.it
Skype: emanuelamaurizi
-------------- parte successiva --------------
Un allegato HTML ? stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20130228/cec6be75/attachment.html>

[unknown]

Post by unknown
Salve a tutti,
La geometria non Ú valida. Riparala prima di tentare di dividerla.
Che devo fare per ripararla?

Se sono pochi errori, puoi sistemarli a mano. Se molti, usa uno strumento di
correzione, come l'importazione in GRASS, oppure il makevalid (disponibile nel plugin
liblwgeom, o direttamente in PostGIS, il che pero' ti richiede di installare e
configurare PostGIS).
saluti.
- --
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario

[unknown]

On Thu, 28 Feb 2013 10:32:38 +0000

Post by unknown
Salve a tutti,

ciao,

Post by unknown
La geometria non Ú valida. Riparala prima di tentare di dividerla.
Che devo fare per ripararla?

qualche tempo fa mi ero occupato di editing in qgis, in particolare
inquiry e controllo di singole features, vertici duplicati di poligoni,
ecc.) e di qualche tentativo di riparazione; non riuscirerti a mandarmi
in pvt un piccolo campione (shp) dei tuoi problemi, così mi diverto a
dargli uno sguardo da vicino;

Post by unknown
grazie in anticipo
Emanuela
Emanuela Maurizi, Ph.D.
University of Rome Tre
Department of Sciences

ciao,
giuliano

[unknown]

In Qgis puoi provare:

VETTORE => STRUMENTI DI GEOMETRIA => CONTROLLA VALIDITÀ GEOMETRIA

Non dovesse funzionare, scaricati la trial di Autocad Map, e lancia la
routine di riparazione automatica _MAPCLEAN

Infine creati una topologia poligonale: il programma ti segnalerà dove
eventualmente riparare a mano.



-----

--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Riparare-geometria-tp7581112p7581134.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.

[unknown]

Post by unknown
Non dovesse funzionare, scaricati la trial di Autocad Map, e lancia la
routine di riparazione automatica _MAPCLEAN

?!?
E su uno usa linux?
Scherzi a parte: meglio rimanere su tecnologie opensource visto il topic
di questa ml :)

Piuttosto il tuo "non dovesse funzionare" puo' essere un bel feedback da
dare agli sviluppatori di QGIS per capire cosa non funziona in quella
procedura.

[unknown]

Post by unknown

Post by unknown
Non dovesse funzionare, scaricati la trial di Autocad Map, e lancia la
routine di riparazione automatica _MAPCLEAN

?!?
E su uno usa linux?
Scherzi a parte: meglio rimanere su tecnologie opensource visto il topic di
questa ml :)

++++++1
:)
Piuttosto che scaricare un gorilla da 800 libre, totalmente chiuso,
solo per pulire delle geometrie installati PostGIS e valida le
geoemtrie con quello. Magari non ci impeighi 5 minuti ma avrai il non
secondario effetto collaterale di imparae ad usare un strumento
potente, prezioso e aperto

Stefano
---------------------------------------------------
41.95581N 12.52854E


http://www.linkedin.com/in/stefanoiacovella

http://twitter.com/#!/Iacovellas

[unknown]

Post by unknown

Post by unknown

Post by unknown
Non dovesse funzionare, scaricati la trial di Autocad Map, e lancia la
routine di riparazione automatica _MAPCLEAN

?!?
E su uno usa linux?
Scherzi a parte: meglio rimanere su tecnologie opensource visto il topic di
questa ml :)

++++++1
:)
Piuttosto che scaricare un gorilla da 800 libre, totalmente chiuso,
solo per pulire delle geometrie installati PostGIS e valida le
geoemtrie con quello. Magari non ci impeighi 5 minuti ma avrai il non
secondario effetto collaterale di imparae ad usare un strumento
potente, prezioso e aperto

oppure, se vai di fretta, ti scarichi SpatiaLite 4.0.0 che supporta
esattamente la stessa ST_MakeValid() di PostGIS [basata sulla medesima
liblwgeom] e che invece di essere un gorilla da 800 libbre e' un
fringuello che pesa si e no 10 grammi e che ti comincia a volare
in meno di 5 minuti :-D

[1] http://www.gaia-gis.it/gaia-sins/windows-bin-x86/
[2] https://www.gaia-gis.it/fossil/libspatialite/index
[3]
https://www.gaia-gis.it/fossil/libspatialite/wiki?name=liblwgeom-4.0

ciao Sandro

[unknown]

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.

*@ Maurizio*

Massimo rispetto per il software opensource, anzi, invito tutti a venirmi a
trovare qua <http://forum.openoikos.com> ...

Il sottoscritto e' un umile tecnico, e quando un postante ha un problema,
gli offro un ventaglio di N opzioni (in primis gratuite) da cui attingere a
seconda del portafoglio o del tempo necessario a scalare la curva
d'apprendimento.

Cio' detto, grazie per avermi accettato in questa nobile ML, e auguro a
tutti un buon weekend.



-----

--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Riparare-geometria-tp7581112p7581145.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.

[unknown]

Post by unknown
Qualora invece siano in grado di "aggiustare" in automatico una shape
devastata come fa l'impressionante MAPCLEAN suddetto, beh, tanto di
cappello.

Scappellati pure: la funzione MakeValid fa questo.

Post by unknown
Il sottoscritto e' un umile tecnico, e quando un postante ha un problema,
gli offro un ventaglio di N opzioni (in primis gratuite) da cui attingere a
seconda del portafoglio o del tempo necessario a scalare la curva
d'apprendimento.

Questa lista e' dedicata alla promozione del sw libero in ambito geografico, non ti
stupire se qualcuno protesta se offri soluzioni non libere: e' come vantare i meriti
del calcio in una lista per la promozione del rugby (o del balletto classico, fai tu).
Saluti.

- --
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario

[unknown]

Post by unknown

Post by unknown
Qualora invece siano in grado di "aggiustare" in automatico una shape
devastata come fa l'impressionante MAPCLEAN suddetto, beh, tanto di
cappello.

Scappellati pure: la funzione MakeValid fa questo.

E tanto di cappello alla Regione Toscana che ne ha finanziato lo sviluppo.

Soldi spesi bene, contrariamente a quelli che finiscono in licenze d'uso
di software sviluppati da aziende che tengono in ostaggio molte pubbliche
amministrazioni.

--strk;

http://strk.keybit.net

[unknown]

Post by unknown

Post by unknown
Scappellati pure: la funzione MakeValid fa questo.

E tanto di cappello alla Regione Toscana che ne ha finanziato lo sviluppo.

beh, allora continuiamo con questo incensamento collettivo, e soprattutto tanto di
cappello a Sandro Santilli, AKA strk, che con le sue ditine ed ingegno ha scritto
questo codice.
questo, fra le tante cose, mi piace del sw libero: ognuno e' un aiuto per l'altro, e
tutti collaboriamo e ci siamo grati. chi l'ha detto che il mondo e' una gabbia di
lupi affamati che competono per un osso?
saluti.
- --
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario

[unknown]

Post by unknown
Massimo rispetto per il software opensource, anzi, invito tutti a venirmi a
trovare qua <http://forum.openoikos.com> ...
Il sottoscritto e' un umile tecnico, e quando un postante ha un problema,
gli offro un ventaglio di N opzioni (in primis gratuite) da cui attingere a
seconda del portafoglio o del tempo necessario a scalare la curva
d'apprendimento.

Non preoccuparti!
Mi era chiaro che la soluzione era dettata dagli strumenti con cui hai
lavorato in passato.
Volevo farti notare che eri off topic ma senza offendere, e invitarti
anche a prendere contatto con la comunita' di sviluppatori di qgis,
qualora tu avessi trovato dei problemi nella funzione di cui si parla in
questo thread.

Grazie e benvenuto!

Ciao

[unknown]

Post by unknown
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,

[unknown]

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 della 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!




-----

--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Riparare-geometria-tp7581151p7581152.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.

[unknown]

Post by unknown
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 della 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
http://ge.tt/9tNXNpZ/v/0?c
Gentilmente, potresti controllare se e', per usare la tua espressione,
"OGC-compliant"..?
Buona serata!

Certo, nessun problema.
Intanto lo ho provato con OpenJump e come previsto mi segnala che
esiste una self-intersection nel punto di contatto.

allego immagine che mostra l'esito su OpenJump.

Ora eseguo la ST_IsValid e poi provo a correggerla con ST_MakeValid()
e ti faccio avere il risultato.

Nel frattempo, se ti interessa capire meglio,
la spiegazione Ú nel modo diverso di definire nello shapefile questa situazione.

i prodotti esri la descrivono (nello shapefile) come fosse un unico
elemento a forma di banan che pero' si Ú richiusa su se stesso a
ciambella (e nessun hole) e i due estremi diventano il punto di
contatto. L'elemento essenziale Ú se non viene definito alcun "hole".
Mentre i prodotti OGC compliant la descrivono come un poligono pieno
con un hole.

Quando uno shapefile con queste caratteristiche (banana a ciambella
con un puto di contatto) e prodotto da un software esri viene testato
da un software OGC esce sempre una self-intersection.
E' quasi un "marker genetico".

Non Ú un problema di sbagliato o giusto.
Sono due definizioni differenti e quindi bisogna conviverci.
L'importante Ú conoscerle e sapervi porre rimedio.

Infatti se vuoi pubblicare questa geometria su un geoserver o un
mapserver o usarla con uno strumento OGC devi riportarla a una
struttura OGC compliant.
Purtroppo i prodotti OGC (almeno quelli che ho provato io) non
riescono a gestirla finiscono sempre per dare errore perche' la vedono
incompatibile.

L'unico comando che la mastica Ú la ST_MakeValid.

L'importante Ú capire che ogni qualvolta si riapre lo shapefile con un
prodotto esri e lo si risalva esso ritorna alla versione "banana
acciambellata" e si rie' daccapo.
Per questo occorre capire e conoscere, perche' non si finisce mai....

Andrea.
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àÚìòù
-----------------
-------------- parte successiva --------------
Un allegato non testuale ? stato rimosso....
Nome: openjump.gif
Tipo: image/gif
Dimensione: 63170 bytes
Descrizione: non disponibile
URL: <Loading Image...>

[unknown]

Anche con spatialite la ST_IsValid ha confermato che Ú invalida.

Ecco la prassi che ho seguito con spatialite 4.0 per testarla e poi
anche per correggerla.

Penso che in generale possa essere utile conoscerlo.

lancio la console di spatialite con il seguent ecomando (creero' un db
file chiamato temp.sqlite che poi butto via)
spatialite temp.sqlite

dalla console eseguo questi comandi:

.loadshp buco_tangente_contorno buco_tangente_contorno CP1252 25832
geometry pippo MULTIPOLYGON 2d 0 1

select count(*) from buco_tangente_contorno where ST_IsValid(geometry)=0;

(mi ritorna come risultato 1, il che vuol dire che ha trovato una
geometria non-valida)

select ST_IsValid(geometry) from buco_tangente_contorno where
ST_IsValid(geometry)=0;

(mi ritorna il seguente messaggio: GEOS warning: Self-intersection at
or near point 476957.4350220412 5031734.8072026027 0

La funzione ST_IsValid() quando incontra una invalidita' come extra
aiuto (prodotto dalla geos sottostante)
segnala la coordinata (o un punto vicino ad essa) dove Ú localizzata
l'invalidita'.

Per risolverla si ricorre alla ST_MakeValid.
nel seguente modo:

aggiungo una ulteriore colonna geometrica alla tabella (Su spatialite
e postgis questo Ú possibile e aiuta tantissimo).
In questa colonna aggiunta collochero' la geometria corretta.

In generale andrebbe messa questa una collection con questo comando,

select AddGeometryColumn(
'buco_tangente_contorno','geom_corretta',25832,'GEOMETRYCOLLECTION','XY',0);

in questo caso particolare si sa' gia' che arriverà una multipolygon,
per cui va bene anche questa:

select AddGeometryColumn(
'buco_tangente_contorno','geom_corretta',25832,'MULTIPOLYGON','XY',0);

poi si aggiorna correggendo la geometria con un update:

update buco_tangente_contorno set geom_corretta = ST_MakeValid(geometry);

La funzione makevalid correggera la geometria e la collochera' nella
colonna indicata.

A questo punto se vado a conteggiare nuovamente le geometrie invalide
su questa colonna geometrica:

select count(*) from buco_tangente_contorno where ST_IsValid(geom_corretta)=0;

ottengo come risultato "0" perche' ora le geometrie sono corrette.

Se voglio la posso esportare con questo comando stando attento a
prendere la geometria dalla colonna giusta:

.dumpshp buco_tangente_contorno geom_corretta
nuovo_buco_tangente_contorno CP1252 POLYGON

[unknown]

Ecco lo shapefile corretto.

http://tinyurl.com/acjkk55

Saluti,

[unknown]

Piatto ricco mi ci ficco ! :-) (tra banane e ciambelle)

Interessantissima discussione! (quasi quanto quella sui metadati ;-))

Mi piacerebbe contribuire con la mia esperienza che ha prodotto il seguente
test.
A differenza di Andrea, il quale ha utilizzato Spatialite, io ho testato il
tutto con PostGIS.
Devo dire che il risultato finale mi ha sorpreso !!

Per prima cosa ho importato sia lo SHP di Andrea (corretto) che quello di
Novarese in PostGIS.
Da quello di Novarese ho creato una nuova tabella avente come geometria il
risultato
di ST_MakeValid, con la seguente query:

CREATE TABLE valid_banana (id serial);
SELECT AddGeometryColumn('','valid_banana','geom',32632,'MULTIPOLYGON',2);
INSERT INTO valid_banana VALUES (
1,
ST_MakeValid((select geom from buco_tangente_contorno))
)

Il mio DB adesso contiene tre tabelle:
1. buco_tangente_contorno (SHP Novarese)
2. nuovo_buco_tangente_contorno (SHP corretto di Andrea)
3. valid_banana (Tabella creata da ST_MakeValid con PostGIS, scusate non ho
resistito per il nome)

Lanciando ST_isValid() per il 2 e il 3 ovviamente il risultato Ú un bel
True, mentre la 1 da False.

DopodichÚ importo tutto in QGIS (e qui viene il bello) e noto una
discrepanza tra la geometria ottenuta da Andrea
e la mia che potete vedere nell'immagini allegate (in [a] differenza tra 2
e 3, in [b] confronto tra 1 e 3)

Da cosa dipende ? Entrambe sono OGC-Compilant ma perchÚ così diverse ?

Inoltre lanciando il tool "Check geometry validity" ottengo una differenza
di errori tra la 2 e la 3, che
potete vedere nell'altre immagini allegate ([c], [d], [e] rispettivamente
per lo SHP 1, 2, 3), ma credo dipenda dalla non corrispondenza tra le due
geometrie.

Allego inoltre, lo SHP esportato da PostGIS da me validato [f], in più
altri due SHP (puntuali) esportati
dal tool Check geometry validity rispettivamente per la tabella 2 e 3 con
gli errori trovati. ((lo SHP [g] riguarda la tabella
2 mentre lo SHP [h] la tabella 3)

Infine, FYI in QGIS e molto probabilmente nella prossima versione, dovrebbe
essere integrato
un tool per il controllo della Topologia, che oltre a mostrare gli errori
(le rules sono pari o superiori a quelli di ArcGIS),
permetterà la correzzione automatica delle geometrie. Allego un'immagine
[i] solo per mostrare come sia lo SHP da me
creato (PostGIS) che quello di Andrea (Spatialite) presentano ulteriori
incongruenze geometriche.

Spero di non essere stato tropp dispersivo !

Grazie ancora per lo stimolo !

Saluti,

-SL

Test eseguito con le seguenti librerie:
GEOS: 3.3.3
PostGIS 2.1.0 (trunk)
QGIS (trunk)

[a] - Loading Image...
[b] - Loading Image...
[c] - Loading Image...
[d] - Loading Image...
[e] - Loading Image...
[f] - http://lrssvt.ns0.it/img/makevalid/makeValidPostGIS.zip
[g] - http://lrssvt.ns0.it/img/makevalid/invalid_nuovo_buco_tangente.zip
[h] - http://lrssvt.ns0.it/img/makevalid/invalid_valid_banana.zip
[i] - Loading Image...

Post by unknown
Ecco lo shapefile corretto.
http://tinyurl.com/acjkk55
Saluti,
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àÚìòù
-----------------
_______________________________________________
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.
638 iscritti al 28.2.2013

--
Salvatore Larosa
linkedIn: http://linkedin.com/in/larosasalvatore
twitter: @lrssvt
skype: s.larosa
IRC: lrssvt on freenode

[unknown]

Nello zip makeValidPostGIS.zip manca "valid_banana.shx"
Puoi aggiungercelo ?

Post by unknown
Piatto ricco mi ci ficco ! :-) (tra banane e ciambelle)
Interessantissima discussione! (quasi quanto quella sui metadati ;-))
Mi piacerebbe contribuire con la mia esperienza che ha prodotto il
seguente test.
A differenza di Andrea, il quale ha utilizzato Spatialite, io ho
testato il tutto con PostGIS.
Devo dire che il risultato finale mi ha sorpreso !!
Per prima cosa ho importato sia lo SHP di Andrea (corretto) che quello
di Novarese in PostGIS.
Da quello di Novarese ho creato una nuova tabella avente come
geometria il risultato
CREATE TABLE valid_banana (id serial);
SELECT AddGeometryColumn('','valid_banana','geom',32632,'MULTIPOLYGON',2);
INSERT INTO valid_banana VALUES (
1,
ST_MakeValid((select geom from buco_tangente_contorno))
)
1. buco_tangente_contorno (SHP Novarese)
2. nuovo_buco_tangente_contorno (SHP corretto di Andrea)
3. valid_banana (Tabella creata da ST_MakeValid con PostGIS, scusate
non ho resistito per il nome)
Lanciando ST_isValid() per il 2 e il 3 ovviamente il risultato Ú un
bel True, mentre la 1 da False.
DopodichÚ importo tutto in QGIS (e qui viene il bello) e noto una
discrepanza tra la geometria ottenuta da Andrea
e la mia che potete vedere nell'immagini allegate (in [a] differenza
tra 2 e 3, in [b] confronto tra 1 e 3)
Da cosa dipende ? Entrambe sono OGC-Compilant ma perchÚ così diverse ?
Inoltre lanciando il tool "Check geometry validity" ottengo una
differenza di errori tra la 2 e la 3, che
potete vedere nell'altre immagini allegate ([c], [d], [e]
rispettivamente per lo SHP 1, 2, 3), ma credo dipenda dalla non
corrispondenza tra le due geometrie.
Allego inoltre, lo SHP esportato da PostGIS da me validato [f], in più
altri due SHP (puntuali) esportati
dal tool Check geometry validity rispettivamente per la tabella 2 e 3
con gli errori trovati. ((lo SHP [g] riguarda la tabella
2 mentre lo SHP [h] la tabella 3)
Infine, FYI in QGIS e molto probabilmente nella prossima versione,
dovrebbe essere integrato
un tool per il controllo della Topologia, che oltre a mostrare gli
errori (le rules sono pari o superiori a quelli di ArcGIS),
permetterà la correzzione automatica delle geometrie. Allego
un'immagine [i] solo per mostrare come sia lo SHP da me
creato (PostGIS) che quello di Andrea (Spatialite) presentano
ulteriori incongruenze geometriche.
Spero di non essere stato tropp dispersivo !
Grazie ancora per lo stimolo !
Saluti,
-SL
GEOS: 3.3.3
PostGIS 2.1.0 (trunk)
QGIS (trunk)
[a] - http://lrssvt.ns0.it/img/makevalid/2vs3.png
[b] - http://lrssvt.ns0.it/img/makevalid/1vs3.png
[c] - http://lrssvt.ns0.it/img/makevalid/geomValidityQGIS1.png
[d] - http://lrssvt.ns0.it/img/makevalid/geomValidityQGIS2.png
[e] - http://lrssvt.ns0.it/img/makevalid/geomValidityQGIS3.png
[f] - http://lrssvt.ns0.it/img/makevalid/makeValidPostGIS.zip
[g] - http://lrssvt.ns0.it/img/makevalid/invalid_nuovo_buco_tangente.zip
[h] - http://lrssvt.ns0.it/img/makevalid/invalid_valid_banana.zip
[i] - http://lrssvt.ns0.it/img/makevalid/topologyChecker.png
Ecco lo shapefile corretto.
http://tinyurl.com/acjkk55
Saluti,
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àÚìòù
-----------------
_______________________________________________
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.
638 iscritti al 28.2.2013
--
Salvatore Larosa
linkedIn: http://linkedin.com/in/larosasalvatore
skype: s.larosa
IRC: lrssvt on freenode
--
Salvatore Larosa
linkedIn: http://linkedin.com/in/larosasalvatore
skype: s.larosa
IRC: lrssvt on freenode

-------------- parte successiva --------------
Un allegato HTML ? stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20130302/05562e52/attachment-0001.html>

[unknown]

Ciao,

Post by unknown
Nello zip makeValidPostGIS.zip manca "valid_banana.shx"
Puoi aggiungercelo ?

E lo sapevo, questo Ú uno dei motivi per cui odio tale formato ! :-)

Inserito ! (dovresti riscaricare l'archivio)

Saluti!

-SL

Post by unknown
Piatto ricco mi ci ficco ! :-) (tra banane e ciambelle)
Interessantissima discussione! (quasi quanto quella sui metadati ;-))
Mi piacerebbe contribuire con la mia esperienza che ha prodotto il
seguente test.
A differenza di Andrea, il quale ha utilizzato Spatialite, io ho testato
il tutto con PostGIS.
Devo dire che il risultato finale mi ha sorpreso !!
Per prima cosa ho importato sia lo SHP di Andrea (corretto) che quello di
Novarese in PostGIS.
Da quello di Novarese ho creato una nuova tabella avente come geometria il
risultato
CREATE TABLE valid_banana (id serial);
SELECT AddGeometryColumn('','valid_banana','geom',32632,'MULTIPOLYGON',2);
INSERT INTO valid_banana VALUES (
1,
ST_MakeValid((select geom from buco_tangente_contorno))
)
1. buco_tangente_contorno (SHP Novarese)
2. nuovo_buco_tangente_contorno (SHP corretto di Andrea)
3. valid_banana (Tabella creata da ST_MakeValid con PostGIS, scusate non
ho resistito per il nome)
Lanciando ST_isValid() per il 2 e il 3 ovviamente il risultato Ú un bel
True, mentre la 1 da False.
DopodichÚ importo tutto in QGIS (e qui viene il bello) e noto una
discrepanza tra la geometria ottenuta da Andrea
e la mia che potete vedere nell'immagini allegate (in [a] differenza tra 2
e 3, in [b] confronto tra 1 e 3)
Da cosa dipende ? Entrambe sono OGC-Compilant ma perchÚ così diverse ?
Inoltre lanciando il tool "Check geometry validity" ottengo una differenza
di errori tra la 2 e la 3, che
potete vedere nell'altre immagini allegate ([c], [d], [e] rispettivamente
per lo SHP 1, 2, 3), ma credo dipenda dalla non corrispondenza tra le due
geometrie.
Allego inoltre, lo SHP esportato da PostGIS da me validato [f], in più
altri due SHP (puntuali) esportati
dal tool Check geometry validity rispettivamente per la tabella 2 e 3 con
gli errori trovati. ((lo SHP [g] riguarda la tabella
2 mentre lo SHP [h] la tabella 3)
Infine, FYI in QGIS e molto probabilmente nella prossima versione,
dovrebbe essere integrato
un tool per il controllo della Topologia, che oltre a mostrare gli errori
(le rules sono pari o superiori a quelli di ArcGIS),
permetterà la correzzione automatica delle geometrie. Allego un'immagine
[i] solo per mostrare come sia lo SHP da me
creato (PostGIS) che quello di Andrea (Spatialite) presentano ulteriori
incongruenze geometriche.
Spero di non essere stato tropp dispersivo !
Grazie ancora per lo stimolo !
Saluti,
-SL
GEOS: 3.3.3
PostGIS 2.1.0 (trunk)
QGIS (trunk)
[a] - http://lrssvt.ns0.it/img/makevalid/2vs3.png
[b] - http://lrssvt.ns0.it/img/makevalid/1vs3.png
[c] - http://lrssvt.ns0.it/img/makevalid/geomValidityQGIS1.png
[d] - http://lrssvt.ns0.it/img/makevalid/geomValidityQGIS2.png
[e] - http://lrssvt.ns0.it/img/makevalid/geomValidityQGIS3.png
[f] - http://lrssvt.ns0.it/img/makevalid/makeValidPostGIS.zip
[g] - http://lrssvt.ns0.it/img/makevalid/invalid_nuovo_buco_tangente.zip
[h] - http://lrssvt.ns0.it/img/makevalid/invalid_valid_banana.zip
[i] - http://lrssvt.ns0.it/img/makevalid/topologyChecker.png

Post by unknown
Ecco lo shapefile corretto.
http://tinyurl.com/acjkk55
Saluti,
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àÚìòù
-----------------
_______________________________________________
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.
638 iscritti al 28.2.2013

--
Salvatore Larosa
linkedIn: http://linkedin.com/in/larosasalvatore
skype: s.larosa
IRC: lrssvt on freenode
--
Salvatore Larosa
linkedIn: http://linkedin.com/in/larosasalvatore
skype: s.larosa
IRC: lrssvt on freenode

[unknown]

ricevuto e controllato.

Sembra essere imputabile a una differenza di precisione nel calcolo
della posizione del vertice.

Sulle prime pensavo che la differenza di precisione potesse essere
imputata alla differente versione della libreria geos.
Anche perche' la console spatialite4.0 che ho usato io impiegava
geos-3.4.0-dev, mentre la tua versione di postgis impiegava la
geos-3.3.3.

Pero' guardando il risultato delle due geometrie a video , si vede
chiaramente che il risultato piu' corretto Ú quello di postgis, mentre
spatialite4.0 ha spostato il vertice di qualche micron.
Per cui riterrei piu' probabile che sia una perdita di precisione che
avviene a livello di spatialite4.0.

Ipotesi: spatialite4.0 invoca la st_makevalid() nella libwgeom, la
quale esegue e ritorna il risultato, nel prendere e trattare il
risultato la spatialite4.0 perde qualche bit di precisione e questo
probvoca quel leggerissimo spostamento.

Sarà certamente interessante vedere i risultati di Furieri.
Infatti questo leggerissimo spostamento che apparentemente potrebbe
non essere signifi cativo in realta' lo Ú.
Perche' in casi molto sfortunati , ma tutt'altro che improbabili
potrebbe a sua volta generare una altra invalidita'.

Altresi' sara' interessante verificare lo stesso risultanto anche in
qgis quando nella libreria sextante sar'a stato implementato la
medesima funzione ST_MakeValid di libwgeom. Anche li' Ú importante che
il risultato finale sia esattamente il medesimo di postgis.

Grazie per la segnalazione,

Andrea.

Post by unknown
Ciao,

Post by unknown
Nello zip makeValidPostGIS.zip manca "valid_banana.shx"
Puoi aggiungercelo ?

E lo sapevo, questo Ú uno dei motivi per cui odio tale formato ! :-)
Inserito ! (dovresti riscaricare l'archivio)
Saluti!
-SL

Post by unknown
Piatto ricco mi ci ficco ! :-) (tra banane e ciambelle)
Interessantissima discussione! (quasi quanto quella sui metadati ;-))
Mi piacerebbe contribuire con la mia esperienza che ha prodotto il
seguente test.
A differenza di Andrea, il quale ha utilizzato Spatialite, io ho testato
il tutto con PostGIS.
Devo dire che il risultato finale mi ha sorpreso !!
Per prima cosa ho importato sia lo SHP di Andrea (corretto) che quello di
Novarese in PostGIS.
Da quello di Novarese ho creato una nuova tabella avente come geometria il
risultato
CREATE TABLE valid_banana (id serial);
SELECT AddGeometryColumn('','valid_banana','geom',32632,'MULTIPOLYGON',2);
INSERT INTO valid_banana VALUES (
1,
ST_MakeValid((select geom from buco_tangente_contorno))
)
1. buco_tangente_contorno (SHP Novarese)
2. nuovo_buco_tangente_contorno (SHP corretto di Andrea)
3. valid_banana (Tabella creata da ST_MakeValid con PostGIS, scusate non
ho resistito per il nome)
Lanciando ST_isValid() per il 2 e il 3 ovviamente il risultato Ú un bel
True, mentre la 1 da False.
DopodichÚ importo tutto in QGIS (e qui viene il bello) e noto una
discrepanza tra la geometria ottenuta da Andrea
e la mia che potete vedere nell'immagini allegate (in [a] differenza tra 2
e 3, in [b] confronto tra 1 e 3)
Da cosa dipende ? Entrambe sono OGC-Compilant ma perchÚ così diverse ?
Inoltre lanciando il tool "Check geometry validity" ottengo una differenza
di errori tra la 2 e la 3, che
potete vedere nell'altre immagini allegate ([c], [d], [e] rispettivamente
per lo SHP 1, 2, 3), ma credo dipenda dalla non corrispondenza tra le due
geometrie.
Allego inoltre, lo SHP esportato da PostGIS da me validato [f], in più
altri due SHP (puntuali) esportati
dal tool Check geometry validity rispettivamente per la tabella 2 e 3 con
gli errori trovati. ((lo SHP [g] riguarda la tabella
2 mentre lo SHP [h] la tabella 3)
Infine, FYI in QGIS e molto probabilmente nella prossima versione,
dovrebbe essere integrato
un tool per il controllo della Topologia, che oltre a mostrare gli errori
(le rules sono pari o superiori a quelli di ArcGIS),
permetterà la correzzione automatica delle geometrie. Allego un'immagine
[i] solo per mostrare come sia lo SHP da me
creato (PostGIS) che quello di Andrea (Spatialite) presentano ulteriori
incongruenze geometriche.
Spero di non essere stato tropp dispersivo !
Grazie ancora per lo stimolo !
Saluti,
-SL
GEOS: 3.3.3
PostGIS 2.1.0 (trunk)
QGIS (trunk)
[a] - http://lrssvt.ns0.it/img/makevalid/2vs3.png
[b] - http://lrssvt.ns0.it/img/makevalid/1vs3.png
[c] - http://lrssvt.ns0.it/img/makevalid/geomValidityQGIS1.png
[d] - http://lrssvt.ns0.it/img/makevalid/geomValidityQGIS2.png
[e] - http://lrssvt.ns0.it/img/makevalid/geomValidityQGIS3.png
[f] - http://lrssvt.ns0.it/img/makevalid/makeValidPostGIS.zip
[g] - http://lrssvt.ns0.it/img/makevalid/invalid_nuovo_buco_tangente.zip
[h] - http://lrssvt.ns0.it/img/makevalid/invalid_valid_banana.zip
[i] - http://lrssvt.ns0.it/img/makevalid/topologyChecker.png

Post by unknown
Ecco lo shapefile corretto.
http://tinyurl.com/acjkk55
Saluti,
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àÚìòù
-----------------
_______________________________________________
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.
638 iscritti al 28.2.2013

--
Salvatore Larosa
linkedIn: http://linkedin.com/in/larosasalvatore
skype: s.larosa
IRC: lrssvt on freenode
--
Salvatore Larosa
linkedIn: http://linkedin.com/in/larosasalvatore
skype: s.larosa
IRC: lrssvt on freenode

--
Salvatore Larosa
linkedIn: http://linkedin.com/in/larosasalvatore
skype: s.larosa
IRC: lrssvt on freenode

[unknown]

Questo messaggio potrebbe essere inappropriato. Clicca per visualizzarlo

[unknown]

On Sat, 02 Mar 2013 12:40:46 +0100

Post by unknown
ricevuto e controllato.
Sembra essere imputabile a una differenza di precisione nel calcolo
della posizione del vertice.
.....

eccoli qua; in effetti accade qualcosa di abbastanza strano, ma ...
......
la ST_MakeValid() ha costruito un "grosso poligono" con un unico
exterior
ring ininterrotto, ma che pero' presenta "una bocca aperta" nella
zona
di intersezione.
in piu' ci sono due microscopici poligonetti di 4 vertici cadauno
(in pratica,
due micro-striscioline che sembrano piu' un linestring
avanti-indietro che un
polygon) che vanno a tappare "la bocca aperta".

Ú esattamente quello che avviene eseguendo il comando "da parti
multiple a parti singole";

Ú come ci fossero due cerchi tangenti in 3 punti !!! che il sistema
risolve come hai descritto tu;

l'ipotesi di Peri che possa essere addebitato a qualche arrotondamento
mi sembra abbastanza pertinente;

ciao Sandro

ciao,
giuliano

[unknown]

Beh....non sono convinto al 100% sulla storia dei decimali.....

Io noto invece che il discostamento potrebbe essere addebitato ad una
diversa
definizione di Sistema di Riferimento.

Andrea usa EPSG:25832 per importare in SpatiaLite, mentre io uso EPSG:32632
(quest'ultimo dovrebbe essere lo stesso di quello usato da Novarese per
esportare lo SHP utilizzato come testcase)

Perciò, l'utilizzo di un diverso ellisoide (GRS80 per il primo e WGS84 per
il secondo) ha portato
a questa discrepanza. Trasformando quello di Andrea in 32632 (o il mio in
25832) le geometrie
coincidono perfettamente.

GRS-80 (1979): 6 378 137, 6 356 752,3141, 298,257222101 [1]
WGS-84 (1984): 6 378 137, 6 356 752,3142, 298,257223563 [2]

Le "microscopiche" differenze tra i due ellisoidi credo svelino l'arcano !

Saluti,

-SL

[1] - http://spatialreference.org/ref/epsg/25832/html/
[2] - http://spatialreference.org/ref/epsg/32632/html/


Il giorno 02 marzo 2013 14:58, giuliano su Tiscali <giulianc a tiscali.it> ha

Post by unknown
On Sat, 02 Mar 2013 12:40:46 +0100

Post by unknown
ricevuto e controllato.
Sembra essere imputabile a una differenza di precisione nel calcolo
della posizione del vertice.
.....

eccoli qua; in effetti accade qualcosa di abbastanza strano, ma ...
......
la ST_MakeValid() ha costruito un "grosso poligono" con un unico
exterior
ring ininterrotto, ma che pero' presenta "una bocca aperta" nella
zona
di intersezione.
in piu' ci sono due microscopici poligonetti di 4 vertici cadauno
(in pratica,
due micro-striscioline che sembrano piu' un linestring
avanti-indietro che un
polygon) che vanno a tappare "la bocca aperta".

Ú esattamente quello che avviene eseguendo il comando "da parti
multiple a parti singole";
Ú come ci fossero due cerchi tangenti in 3 punti !!! che il sistema
risolve come hai descritto tu;
l'ipotesi di Peri che possa essere addebitato a qualche arrotondamento
mi sembra abbastanza pertinente;

ciao Sandro

ciao,
giuliano
_______________________________________________
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.

Post by unknown
638 iscritti al 28.2.2013

--
Salvatore Larosa
linkedIn: http://linkedin.com/in/larosasalvatore
twitter: @lrssvt
skype: s.larosa
IRC: lrssvt on freenode
-------------- parte successiva --------------
Un allegato HTML ? stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20130302/773181ba/attachment.html>

[unknown]

On Sat, 2 Mar 2013 15:35:44 +0100

Post by unknown
Beh....non sono convinto al 100% sulla storia dei decimali.....
Io noto invece che il discostamento potrebbe essere addebitato ad una
diversa
definizione di Sistema di Riferimento.
.....

credo sempre problema di arrotondamento di tratti, ma tu hai dato una
indicazione di dove andare a cercare e quel terreno Ú ancora tabù per me
in questo momento :-)))))

Post by unknown
Saluti,
-SL

grazie, ciao,
giuliano

PS: vedo che nessuno ha dato peso alla mia indicazione circa la
"stranezza" del multipoligono; non voglio insistere, ma credo anche lì
ci sia da cercare..... ;-)

[unknown]

Questo thread meriterebbe la stesura di un piccolo manualetto. Sarebbe un
piccolo tesoro.

Complimenti



-----
Andrea Borruso

----------------------------------------------------
email: aborruso a tin.it
website: http://blog.spaziogis.it
feed: http://feeds2.feedburner.com/Tanto
38° 7' 48" N, 13° 21' 9" E
----------------------------------------------------
--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Riparare-geometria-tp7581156p7581164.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.

[unknown]

Post by unknown
DopodichÚ importo tutto in QGIS (e qui viene il bello) e noto una
discrepanza tra la geometria ottenuta da Andrea
e la mia che potete vedere nell'immagini allegate (in [a] differenza
tra 2 e 3, in [b] confronto tra 1 e 3)
Da cosa dipende ? Entrambe sono OGC-Compilant ma perchÚ così diverse ?

Brutto segno.
NOn dovrebbe succedere.
Sia Postgis che Spatialite fanno uso della LibWGEom e la MakeValid
risiede li' dentro.

A onor del vero vedo che te usi postgis 2.1.0.

Quindi forse stai usando una libwgeom piu' recente di quella che
probabilmente usa spatialite 4.0.

Quindi, puo' darsi che una successiva evoluzione apportata a tale
libreria e in particolare alla libwgeom puo' aver modificato il modo di
correggere di una detemrinata tipologia di geometria invalida. Oppure il
problema potrebbe risiedere nella (eventuale) differente versione di
libreria Geos utilizzata.

Infatti spatialite 4.0 usa una versione piu' recente di geos rispetto a
quella che stai usando te con postgis 2.1.0.

Pero' queste sono tutte congetture.

Io in realta' sospetto che la risposta sia in una terza opzione:

Forse la spatialite 4.0 , su questo tipo di errore (invalidita'
geometrica) , anziche' appoggiarsi alla libwgeom preferisce agire di
propria iniziativa e correggere a modo suo, ripiegando sulla
ST_MakeValid della Libwgeom solo nei casi di geometria piu' complesse.
Ovviamente dal mio punto di vista piu' si standardizza un comportamento
e meglio Ú.
Per cui se questa Ú la risposta converrebbe che la spatialite4.0
correggesse nel medesimo modo di ST_MakeValid() di libwgeom.

Furieri puoi darci un chiarimento su questo ?

Grazie,

Andrea.

[unknown]

Post by unknown
Forse la spatialite 4.0 , su questo tipo di errore (invalidita'
geometrica) , anziche' appoggiarsi alla libwgeom preferisce agire di
propria iniziativa e correggere a modo suo, ripiegando sulla
ST_MakeValid della Libwgeom solo nei casi di geometria piu'
complesse.

Niet, nulla di tutto questo.
quando si chiama ST_MakeValid() splite passa direttamente tutta la
geometria tal quale a liblwgeom senza metterci ne sale ne pepe
e senza nessunissimo passaggio intermedio.

Post by unknown
Furieri puoi darci un chiarimento su questo ?

metto su un testbed e vi faccio sapere ASAP

ciao Sandro

[unknown]

Fra buchi e banane, ragazzi, lasciate che Vi dica una cosa: siete troppo
forti.

Lo scrivente e' iscritto a 15 forum in giro per il mondo, ma Vi giuro,
questo e' il primo di livello addirittura accademico.

Fino all'altroieri "credevo" di sapere, invece al Vostro cospetto abbasso le
orecchie, ed imparo.

Certo, mi sara' difficile trovare un'applicazione pratica di tali
affascinanti teorie, ma metto comunque in saccoccia e porto a casa.

Se mi permettete un piccolo appunto, ho notato che fate un abuso pleonastico
di anglicismi: capisco il gergo tecnico, ma se scriveste "conforme" invece
di "compliant", Vi ammirerei decisamente di piu'...

Auguro un buon weekend, pardon, fine settimana a tutti.



-----

--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Riparare-geometria-tp7581156p7581158.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.

[unknown]

Post by unknown
Se mi permettete un piccolo appunto, ho notato che fate un abuso pleonastico
di anglicismi: capisco il gergo tecnico, ma se scriveste "conforme" invece
di "compliant" ...

Concordo al 100%.

Ciao,
Marco

[unknown]

Alessandro,

Ho provato a caricare in spatialite la geometria di Salvatore (valid_banana)
usando la solita:

.loadshp salvatore-larosa/valid_banana valid_banana CP1252 25832
geometry pippo MULTIPOLYGON 2d 0 1


E poi ho confrontato l'ewkt di entrambe quella corretta da spatialite
e quella che era stata corretta da postgis.

In entrambe compare tutti e tre le componenti da te evidenziate.

Ignorando quella piu' grande, ma concentrando l'atteznione su le due
piu' piccole (4 vertici ciascuna) vedo che

nella geometria corretta da spatialite4.0

Ú cosi' definita:

MULTIPOLYGON(((476959.6811853445 5031863.489812068,
476957.4350220412 5031734.807202603,
476957.4350220412 5031734.807202602,
476959.6811853445 5031863.489812068)),
....
,
((476957.4350220412 5031992.172421534,
476957.4350220412 5031992.172421533,
476959.6811853445 5031863.489812068,
476957.4350220412 5031992.172421534)))

e quella importata (banana_valida) Ú cosi definita:

MULTIPOLYGON(((476959.6811853445 5031863.489812068,
476957.4350220412 5031734.807202603,
476957.4350220412 5031734.807202602,
476959.6811853445 5031863.489812068)),
....
,
((476957.4350220412 5031992.172421534,
476957.4350220412 5031992.172421533,
476959.6811853445 5031863.489812068,
476957.4350220412 5031992.172421534)))

SONO UGUALI !

Mettiamo per un attimo da parte il perche' crea questi due poligoni.
L'importante Ú che siano validi (e in effetti lo sono).

Ma il problema piu' piccante Ú come mai se guardo lo shapefile di
Salvatore su QGIS, e ingrandisco fino al limite vedo che la geoemtria
di spatialite e quella di salvatore si discostano, mentre se carico
quella di salvatore su spalite4.0 e confronto i vertici (con ewkt che
mi produce fino all'ultimo decimale) vedo che sono uguali ?

Per rispondere a questa domanda, ho provato a usare su qgis, non lo
shapefile esportato da splite, ma bensi direttamente splite.

E ho scoperto l'arcano !

La geometria valid_banana di Salvatore una volta caricata su splite4.0
(poi convertito in splite3.0 per poterlo vedere su qgis) si Ú spostata
. :))

Quindi a questo punto l'ipotesi piu' probabile Ú che sia la procedura
di esportazione/importazione di shapefiles di spatialite4 che perda
qualche decimale.

Sicuramente avviene con l'importazione, visto che confrontando lo
shapefile con la sua importazione su splite tramite qgis si osserva
questo spostamento.

vedi immagine allegata.

Ed Ú quindi per questo che quando Salvatore Ú andato a confrontare lo
shapefile di postgis con quello che avevo esportato da splite ha
rilevato qualche decimale di differenza.
:))

Andrea.
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àÚìòù
-----------------
-------------- parte successiva --------------
Un allegato non testuale ? stato rimosso....
Nome: img1.gif
Tipo: image/gif
Dimensione: 12977 bytes
Descrizione: non disponibile
URL: <Loading Image...>

[unknown]

Il trucco c'e' ma non si vede: mistero risolto :-D

Post by unknown
Alessandro,
Ho provato a caricare in spatialite la geometria di Salvatore
(valid_banana)
.loadshp salvatore-larosa/valid_banana valid_banana CP1252 25832
geometry pippo MULTIPOLYGON 2d 0 1

ok, ti ho pedinato fedelmente passo per passo ed ho riprodotto
il testcase.

<snip>

Post by unknown
nella geometria corretta da spatialite4.0
MULTIPOLYGON(((476959.6811853445 5031863.489812068,
476957.4350220412 5031734.807202603,
476957.4350220412 5031734.807202602,
476959.6811853445 5031863.489812068)),
....
,
((476957.4350220412 5031992.172421534,
476957.4350220412 5031992.172421533,
476959.6811853445 5031863.489812068,
476957.4350220412 5031992.172421534)))
MULTIPOLYGON(((476959.6811853445 5031863.489812068,
476957.4350220412 5031734.807202603,
476957.4350220412 5031734.807202602,
476959.6811853445 5031863.489812068)),
....
,
((476957.4350220412 5031992.172421534,
476957.4350220412 5031992.172421533,
476959.6811853445 5031863.489812068,
476957.4350220412 5031992.172421534)))
SONO UGUALI !

"sembrano uguali" ... ma non lo sono affatto ... suspense ... :-)

Post by unknown
Ma il problema piu' piccante Ú come mai se guardo lo shapefile di
Salvatore su QGIS, e ingrandisco fino al limite vedo che la geoemtria
di spatialite e quella di salvatore si discostano, mentre se carico
quella di salvatore su spalite4.0 e confronto i vertici (con ewkt che
mi produce fino all'ultimo decimale) vedo che sono uguali ?
Per rispondere a questa domanda, ho provato a usare su qgis, non lo
shapefile esportato da splite, ma bensi direttamente splite.
E ho scoperto l'arcano !
La geometria valid_banana di Salvatore una volta caricata su
splite4.0
(poi convertito in splite3.0 per poterlo vedere su qgis) si Ú spostata
. :))
Quindi a questo punto l'ipotesi piu' probabile Ú che sia la procedura
di esportazione/importazione di shapefiles di spatialite4 che perda
qualche decimale.

no: e' PostGIS che si fuma qualche decimale; ecco spiegato perche' non
si ha una sovrapposizione perfetta :-D

EWKT = formato text = per quanti decimali possa utilizzare, qualcosina
perde di sicuro

invece spatialite effettua un'importazione *binaria*, senza nessuna
conversione: ergo non puo' perdere precisione, non ci sono
arrotondamenti
possibili. legge un DOUBLE e scrive esattamente il valore che ha letto.

contro-prova "stile San Tommaso"
=====================================================
476959.6811853445 5031863.489812068,
476957.4350220412 5031734.807202603,
476957.4350220412 5031734.807202602,
476959.6811853445 5031863.489812068

questi sono i primi valori "text" dell'EWKT di PostGIS
... invece questo e' quel che vedo da splite dopo avere
inserito nel mezzo una banale printf con formato "%1.16f"
(i.e. stampami ben 16 posizioni decimali):

476959.6811853445800000 5031863.4898120686000000
476957.4350220412600000 5031734.8072026037000000
476957.4350220412000000 5031734.8072026027000000
476959.6811853445800000 5031863.4898120686000000

come puoi facilmente verificare, PostGIS quando ha convertito da
binario a text si e' regolarmente "mangiato" l'ultimo decimale.

stiamo usando una scala metrica; quindi in pratica stiamo parlando
di micro-differenze di ordine "atomico" (circa un angstrom)
assolutamente insignificanti per qualsiasi scopo fisico, ma
probabilmente rilevanti per scopi topologici (dove si richiede
una coerenza ultra-paranoica, altrimenti tutto crolla).

comunque, alla fine siamo arrivati ad un punto fermo; l'importer
PostGIS basato su EWKT introduce dei nano-shifts nelle coordinate.
scoperta decisamente interessante; buono a sapersi.

ciao Sandro

[unknown]

Daccordo.

L'importer di postgis probabilmente introduce uno shift, però anche il
tuo lo introduce.

Altrimenti non mi spiegherei perche' lo shapefile e lo sqlite su qgis
presentano la differenza che mostravo.

Ti metto a disposizione lo sqlite con dentro la geometria di Salvatore.

http://tinyurl.com/a9dh622

In esso ho caricato lo shapefile di Salvatore con il seguente comando,
.loadshp salvatore-larosa/valid_banana valid_banana CP1252 25832
geometry pippo MULTIPOLYGON 2d 0 1

Cosi' facendo mi disinteresso di quale sia il prodotto che ha generato
lo shapefile di Salvatore, lo prendo per buono e lo carico in
spatialite.

Dopodiche' l'unic altra operazione che faccio Ú convertire lo splite4
in uno splite3 per leggerlo con qgis.

Poi passo a confrontare a video lo shapefile di Salvatroe con lo splite.
Se l'importatore di splite non introducesse nessuna alterazione dovrei
vedere i medesimi risultati esatti.

Invece vedo delle microdifferenze.

In questo discorso postgis non viene toccato.

Andrea.

Post by unknown
Il trucco c'e' ma non si vede: mistero risolto :-D

Post by unknown
Alessandro,
Ho provato a caricare in spatialite la geometria di Salvatore
(valid_banana)
.loadshp salvatore-larosa/valid_banana valid_banana CP1252 25832
geometry pippo MULTIPOLYGON 2d 0 1

ok, ti ho pedinato fedelmente passo per passo ed ho riprodotto
il testcase.
<snip>

Post by unknown
nella geometria corretta da spatialite4.0
MULTIPOLYGON(((476959.6811853445 5031863.489812068,
476957.4350220412 5031734.807202603,
476957.4350220412 5031734.807202602,
476959.6811853445 5031863.489812068)),
....
,
((476957.4350220412 5031992.172421534,
476957.4350220412 5031992.172421533,
476959.6811853445 5031863.489812068,
476957.4350220412 5031992.172421534)))
MULTIPOLYGON(((476959.6811853445 5031863.489812068,
476957.4350220412 5031734.807202603,
476957.4350220412 5031734.807202602,
476959.6811853445 5031863.489812068)),
....
,
((476957.4350220412 5031992.172421534,
476957.4350220412 5031992.172421533,
476959.6811853445 5031863.489812068,
476957.4350220412 5031992.172421534)))
SONO UGUALI !

"sembrano uguali" ... ma non lo sono affatto ... suspense ... :-)

Post by unknown
Ma il problema piu' piccante Ú come mai se guardo lo shapefile di
Salvatore su QGIS, e ingrandisco fino al limite vedo che la geoemtria
di spatialite e quella di salvatore si discostano, mentre se carico
quella di salvatore su spalite4.0 e confronto i vertici (con ewkt che
mi produce fino all'ultimo decimale) vedo che sono uguali ?
Per rispondere a questa domanda, ho provato a usare su qgis, non lo
shapefile esportato da splite, ma bensi direttamente splite.
E ho scoperto l'arcano !
La geometria valid_banana di Salvatore una volta caricata su splite4.0
(poi convertito in splite3.0 per poterlo vedere su qgis) si Ú spostata
. :))
Quindi a questo punto l'ipotesi piu' probabile Ú che sia la procedura
di esportazione/importazione di shapefiles di spatialite4 che perda
qualche decimale.

no: e' PostGIS che si fuma qualche decimale; ecco spiegato perche' non
si ha una sovrapposizione perfetta :-D
EWKT = formato text = per quanti decimali possa utilizzare, qualcosina
perde di sicuro
invece spatialite effettua un'importazione *binaria*, senza nessuna
conversione: ergo non puo' perdere precisione, non ci sono arrotondamenti
possibili. legge un DOUBLE e scrive esattamente il valore che ha letto.
contro-prova "stile San Tommaso"
=====================================================
476959.6811853445 5031863.489812068,
476957.4350220412 5031734.807202603,
476957.4350220412 5031734.807202602,
476959.6811853445 5031863.489812068
questi sono i primi valori "text" dell'EWKT di PostGIS
... invece questo e' quel che vedo da splite dopo avere
inserito nel mezzo una banale printf con formato "%1.16f"
476959.6811853445800000 5031863.4898120686000000
476957.4350220412600000 5031734.8072026037000000
476957.4350220412000000 5031734.8072026027000000
476959.6811853445800000 5031863.4898120686000000
come puoi facilmente verificare, PostGIS quando ha convertito da
binario a text si e' regolarmente "mangiato" l'ultimo decimale.
stiamo usando una scala metrica; quindi in pratica stiamo parlando
di micro-differenze di ordine "atomico" (circa un angstrom)
assolutamente insignificanti per qualsiasi scopo fisico, ma
probabilmente rilevanti per scopi topologici (dove si richiede
una coerenza ultra-paranoica, altrimenti tutto crolla).
comunque, alla fine siamo arrivati ad un punto fermo; l'importer
PostGIS basato su EWKT introduce dei nano-shifts nelle coordinate.
scoperta decisamente interessante; buono a sapersi.
ciao Sandro
--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

[unknown]

Post by unknown
Daccordo.
L'importer di postgis probabilmente introduce uno shift, però anche il
tuo lo introduce.
Altrimenti non mi spiegherei perche' lo shapefile e lo sqlite su qgis
presentano la differenza che mostravo.
Ti metto a disposizione lo sqlite con dentro la geometria di
Salvatore.
http://tinyurl.com/a9dh622
In esso ho caricato lo shapefile di Salvatore con il seguente
comando,
.loadshp salvatore-larosa/valid_banana valid_banana CP1252 25832
geometry pippo MULTIPOLYGON 2d 0 1
Cosi' facendo mi disinteresso di quale sia il prodotto che ha
generato
lo shapefile di Salvatore, lo prendo per buono e lo carico in
spatialite.
Dopodiche' l'unic altra operazione che faccio Ú convertire lo splite4
in uno splite3 per leggerlo con qgis.
Poi passo a confrontare a video lo shapefile di Salvatroe con lo splite.
Se l'importatore di splite non introducesse nessuna alterazione dovrei
vedere i medesimi risultati esatti.
Invece vedo delle microdifferenze.
In questo discorso postgis non viene toccato.

Andrea,

non riesco a replicare il problema in nessun modo:
- mi sono installato l'ultimissimo QGIS 1.9.0 "nightly build" su WinXP
- apro lo SHP "valid_banana" che ci ha spedito Salvatore
[makeValidPostGIS.zip]
- poi apro lo sqlite che mi hai inviato tu [test-import.zip]

ma li vedo sempre esattamente sovrapposti anche zoommando a fattori di
scala ultra-esagerati; ho provato a spostarli sotto-sopra, le linee si
coprono perfettamente in tutti i casi, senza nessuno scostamento.
perche' vediamo risultati cosi' differenti ? non capisco ...

[1] Loading Image...
[2] Loading Image...

ciao Sandro

[unknown]

Post by unknown
Perciò, l'utilizzo di un diverso ellisoide (GRS80 per il primo e WGS84 per
il secondo) ha portato
a questa discrepanza. Trasformando quello di Andrea in 32632 (o il mio in
25832) le geometrie
coincidono perfettamente.
GRS-80 (1979): 6 378 137, 6 356 752,3141, 298,257222101 [1]
WGS-84 (1984): 6 378 137, 6 356 752,3142, 298,257223563 [2]
Le "microscopiche" differenze tra i due ellisoidi credo svelino l'arcano !
Saluti,

Bingo !

Hai perfettamente ragione.

A riprova, ho ripercorso tutti i passi usando 32632 al posto di 25832
e ora lo shapefile corretto da spatialite d esportato in shapefile
collima esattamente con quello tuo.

Eccolo qui.
http://tinyurl.com/anhaao9

Una volta di piu' si riconferma tanto per cambiare quanto sia
importante un metadato fatto bene ad accompagnare un dataset.
Quanto in esso sia importante la parte di indicazione del sistema di
riferimento,
ma anche quanto sia importante la parte DataQuality -> Lineage ->
ProcessStep + Source-Step
in cui si puo' dettagliare per filo e per segno i passi con cui un
archivio Ú stato prodotto, corretto , esportato, etc....

Questo aiuta a identificare discrepanze altrimenti non facilmente spiegabili.

Questo di oggi mi pare un caso di uso emblematico e assolutamente realistico.

Sicuramente una giornata profiqua.

Saluti,