Riparare geometria???

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Riparare geometria???

Andrea Peri
Ecco lo shapefile corretto.

http://tinyurl.com/acjkk55

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
Reply | Threaded
Open this post in threaded view
|

Riparare geometria???

Salvatore Larosa
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] - 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

Il giorno 01 marzo 2013 22:06, Andrea Peri <[hidden email]> ha scritto:
Ecco lo shapefile corretto.

http://tinyurl.com/acjkk55

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



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


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


_______________________________________________
[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
Reply | Threaded
Open this post in threaded view
|

Re: Riparare geometria???

Novarese
In reply to this post by Andrea Peri
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.
Reply | Threaded
Open this post in threaded view
|

Re: Riparare geometria???

Andrea Peri
In reply to this post by Salvatore Larosa
Nello zip makeValidPostGIS.zip manca "valid_banana.shx"
Puoi aggiungercelo ?

On 02/03/2013 02:44, Salvatore Larosa wrote:
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] - 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

Il giorno 01 marzo 2013 22:06, Andrea Peri <[hidden email]> ha scritto:
Ecco lo shapefile corretto.

http://tinyurl.com/acjkk55

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



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


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



_______________________________________________
[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
Reply | Threaded
Open this post in threaded view
|

Re: Riparare geometria???

Andrea Peri
In reply to this post by Salvatore Larosa
On 02/03/2013 02:44, Salvatore Larosa wrote:
> 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.

_______________________________________________
[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
Reply | Threaded
Open this post in threaded view
|

Re: Riparare geometria???

a.furieri
On Sat, 02 Mar 2013 10:03:32 +0100, aperi2007 wrote:
> 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.


> Furieri puoi darci un chiarimento su questo ?
>

metto su un testbed e vi faccio sapere ASAP

ciao Sandro

--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

_______________________________________________
[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
Reply | Threaded
Open this post in threaded view
|

Re: Riparare geometria???

Salvatore Larosa
In reply to this post by Andrea Peri
Ciao,

Il giorno 02 marzo 2013 09:51, aperi2007 <[hidden email]> ha scritto:
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


 

On 02/03/2013 02:44, Salvatore Larosa wrote:
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] - 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

Il giorno 01 marzo 2013 22:06, Andrea Peri <[hidden email]> ha scritto:
Ecco lo shapefile corretto.

http://tinyurl.com/acjkk55

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



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


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





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

_______________________________________________
[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
Reply | Threaded
Open this post in threaded view
|

Re: Riparare geometria???

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

Complimenti
Andrea Borruso

----------------------------------------------------
twitter: https://twitter.com/aborruso
website: https://medium.com/tantotanto
38° 7' 48" N, 13° 21' 9" E
----------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: Riparare geometria???

Andrea Peri
In reply to this post by Salvatore Larosa
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.

Il 02 marzo 2013 10:23, Salvatore Larosa <[hidden email]> ha scritto:

> Ciao,
>
> Il giorno 02 marzo 2013 09:51, aperi2007 <[hidden email]> ha scritto:
>
>> 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
>
>
>
>>
>>
>> On 02/03/2013 02:44, Salvatore Larosa wrote:
>>
>> 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] - 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
>>
>> Il giorno 01 marzo 2013 22:06, Andrea Peri <[hidden email]> ha
>> scritto:
>>>
>>> Ecco lo shapefile corretto.
>>>
>>> http://tinyurl.com/acjkk55
>>>
>>> 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
>>
>>
>>
>>
>> --
>> Salvatore Larosa
>> linkedIn: http://linkedin.com/in/larosasalvatore
>> twitter: @lrssvt
>> skype: s.larosa
>> IRC: lrssvt on freenode
>>
>>
>> --
>> Salvatore Larosa
>> linkedIn: http://linkedin.com/in/larosasalvatore
>> twitter: @lrssvt
>> skype: s.larosa
>> IRC: lrssvt on freenode
>>
>>
>
>
>
> --
> Salvatore Larosa
> linkedIn: http://linkedin.com/in/larosasalvatore
> twitter: @lrssvt
> skype: s.larosa
> IRC: lrssvt on freenode



--
-----------------
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
Reply | Threaded
Open this post in threaded view
|

Re: Riparare geometria???

a.furieri
On Sat, 2 Mar 2013 11:15:12 +0100, Andrea Peri wrote:

> 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.
>

certamente possibile, ma veramente dura da spiegare.
a livello di codice splite (come immagino tutti gli altri) si limita
semplicemente a trasferire dei valori double (gia' presenti nello SHP
di input come tali, non ci sono conversioni di sorta).
visto che si tratta di dati nativi C, dovrebbero rispecchiare
esattamente
il contenuto dei registri di CPU. vedo scarsissimi margini per
eventuali
arrotondamenti o troncamenti di bit a causa del sw (al limite, posso
sospettare qualche interferenza dovuta alle librerie di run-time, che
possono essere molto verosimilmente differenti).


> Sarà certamente interessante vedere i risultati di Furieri.
>

eccoli qua; in effetti accade qualcosa di abbastanza strano, ma non
riesco
ad identificarne la causa.

a) http://www.gaia-gis.it/mkvld/st_makevalid0.png
    questo e' il risultato della ST_MakeValid() di splite.
    ci aspetteremmo di trovare un unico Polygon, con un exterior ring e
    con un unico interior ring; invece si sono 3 Polygons, ciascuno con
    il proprio exterior ring e senza nessun "buco"

b) http://www.gaia-gis.it/mkvld/st_makevalid1.png
    http://www.gaia-gis.it/mkvld/st_makevalid2.png
    se ora andiamo a visualizzare il micro-dettaglio nella zona
dell'intersezione,
    ecco che scopriamo cosa e' successo (ho "sfogliato" ciascun poligono
tramite
    elemgeom per evidenziare meglio le entita' individuali).
    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".

c) http://www.gaia-gis.it/mkvld/st_difference.png
    a questo punto, giusto per cercare di capire meglio, mi sono
costruito due
    Polygons distinti, uno per ciascun Ring; e poi ho sottratto quello
piu'
    piccolo da quello piu' grande tramite ST_Difference()
    ed ecco che anche in questo caso viene fuori un unico exterior ring
    senza alcun buco, e con "la bocca aperta" sull'intersezione.
    cioe' esattamente coerente con il "poligono grosso" che viene
costruito
    anche dalla ST_MakeValid(), solo che nel caso della ST_Difference()
    le due micro-striscioline sono sparite del tutto.

d) http://www.gaia-gis.it/mkvld/invalid.png
    giusto per verifica finale, mi sono quindi preparato una geometria
    sicuramente invalida ma elementarmente semplice e piu' facile da
    verificare.
    POLYGON((0 0, 10 0, 10 10, 0 10, 0 5, 4 9, 8 5, 4 1, 0 5, 0 0))

    http://www.gaia-gis.it/mkvld/st_makevalid3.png
    in questo caso la ST_MakeValid() lavora secondo le attese
    POLYGON((0 5, 0 10, 10 10, 10 0, 0 0, 0 5), (0 5, 4 1, 8 5, 4 9, 0
5))

    quindi immagino che sia corretto concludere che nel caso "due
cerchi"
    l'alto numero di vertici "quasi sovrapposti" finisca in qualche modo
    per mandare in confusione la ST_MakeValid() nella zona "bocca
aperta",
    ma e' tutto da verificare.

e) escluderei comunque nel modo piu' assoluto che la GEOS 4.0-trunk
abbia
    nulla di strano; ho verificato con la 3.3.7 "stable", e produce
esattamente
    i medesimi risultati della 4.0-trunk

ciao Sandro




--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

_______________________________________________
[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
Reply | Threaded
Open this post in threaded view
|

Re: Riparare geometria???

Marco Curreli
In reply to this post by Novarese
On 23:01 Fri 01 Mar     , Novarese wrote:
> 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

_______________________________________________
[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
Reply | Threaded
Open this post in threaded view
|

Re: Riparare geometria???

giuliano su Tiscali
In reply to this post by a.furieri
On Sat, 02 Mar 2013 12:40:46 +0100
[hidden email] wrote:

> On Sat, 2 Mar 2013 11:15:12 +0100, Andrea Peri wrote:
> > 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

_______________________________________________
[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
Reply | Threaded
Open this post in threaded view
|

Re: Riparare geometria???

Salvatore Larosa
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 <[hidden email]> ha scritto:
>
> On Sat, 02 Mar 2013 12:40:46 +0100
> [hidden email] wrote:
>
> > On Sat, 2 Mar 2013 11:15:12 +0100, Andrea Peri wrote:
> > > 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
>
> _______________________________________________
> [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




--
Salvatore Larosa
linkedIn: http://linkedin.com/in/larosasalvatore
twitter: @lrssvt
skype: s.larosa
IRC: lrssvt on freenode
_______________________________________________
[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
Reply | Threaded
Open this post in threaded view
|

Re: Riparare geometria???

giuliano su Tiscali
On Sat, 2 Mar 2013 15:35:44 +0100
Salvatore Larosa <[hidden email]> wrote:

> 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 :-)))))

 
> 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..... ;-)
_______________________________________________
[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