Ecco lo shapefile corretto.
Saluti,
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
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:
- buco_tangente_contorno (SHP Novarese)
- nuovo_buco_tangente_contorno (SHP corretto di Andrea)
- 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 aperi2007@gmail.com ha scritto:
Ecco lo shapefile corretto.
Saluti,
–
Andrea Peri
. . . . . . . . .
qwerty àèìòù
Gfoss@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
–
Salvatore Larosa
linkedIn: http://linkedin.com/in/larosasalvatore
twitter: @lrssvt
skype: s.larosa
IRC: lrssvt on freenode
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.
Nello zip makeValidPostGIS.zip manca "valid_banana.shx"
Puoi aggiungercelo ?
On 02/03/2013 02:44, Salvatore Larosa wrote:
Piatto ricco mi ci ficco !
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.pngIl giorno 01 marzo 2013 22:06, Andrea Peri <aperi2007@gmail.com> ha scritto:
Ecco lo shapefile corretto.
Saluti,
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
Gfoss@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--
Salvatore Larosa
linkedIn: http://linkedin.com/in/larosasalvatore
twitter: @lrssvt
skype: s.larosa
IRC: lrssvt on freenode
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.
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.
Ciao,
Il giorno 02 marzo 2013 09:51, aperi2007 <aperi2007@gmail.com> 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 !
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:
- buco_tangente_contorno (SHP Novarese)
- nuovo_buco_tangente_contorno (SHP corretto di Andrea)
- 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.pngIl giorno 01 marzo 2013 22:06, Andrea Peri aperi2007@gmail.com ha scritto:
Ecco lo shapefile corretto.
Saluti,
–
Andrea Peri
. . . . . . . . .
qwerty àèìòù
Gfoss@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–
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
Questo thread meriterebbe la stesura di un piccolo manualetto. Sarebbe un
piccolo tesoro.
Complimenti
-----
Andrea Borruso
----------------------------------------------------
email: aborruso@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.
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 <lrssvtml@gmail.com> ha scritto:
Ciao,
Il giorno 02 marzo 2013 09:51, aperi2007 <aperi2007@gmail.com> 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 !
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.pngIl giorno 01 marzo 2013 22:06, Andrea Peri <aperi2007@gmail.com> ha
scritto:Ecco lo shapefile corretto.
Saluti,
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
Gfoss@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--
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 àèìòù
-----------------
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.
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
On Sat, 02 Mar 2013 12:40:46 +0100
a.furieri@lqt.it 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
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@tiscali.it> ha scritto:
On Sat, 02 Mar 2013 12:40:46 +0100
a.furieri@lqt.it 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
Gfoss@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
On Sat, 2 Mar 2013 15:35:44 +0100
Salvatore Larosa <lrssvtml@gmail.com> 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..... 