Riparare geometria???
Locked
 
|
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 |
|
|
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. -- 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 |
|
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. |
|
|
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) _______________________________________________ [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 |
|
|
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 |
|
|
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 |
|
|
In reply to this post by Andrea Peri
Ciao,
Il giorno 02 marzo 2013 09:51, aperi2007 <[hidden email]> ha scritto:
E lo sapevo, questo è uno dei motivi per cui odio tale formato ! :-) Inserito ! (dovresti riscaricare l'archivio) Saluti! -SL
-- 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 |
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 ---------------------------------------------------- |
|
|
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 |
|
|
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 |
|
|
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 |
Re: Riparare geometria???
|
|
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 |
|
|
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 |
Re: Riparare geometria???
|
|
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 |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |