[Gfoss] Riparare geometria???
a.furieri a lqt.it
a.furieri a lqt.it
Sab 2 Mar 2013 12:40:46 CET
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.
Maggiori informazioni sulla lista
Gfoss