[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