[Gfoss] Riparare geometria???

[a.furieri a lqt.it]

Il trucco c'e' ma non si vede: mistero risolto :-D


On Sat, 2 Mar 2013 13:39:58 +0100, Andrea Peri wrote:
> Alessandro,
>
> Ho provato a caricare in spatialite la geometria di Salvatore 
> (valid_banana)
> usando la solita:
>
> .loadshp salvatore-larosa/valid_banana valid_banana CP1252 25832
> geometry pippo MULTIPOLYGON 2d 0 1
>

ok, ti ho pedinato fedelmente passo per passo ed ho riprodotto
il testcase.

<snip>
> nella geometria corretta da spatialite4.0
>
> è cosi' definita:
>
> MULTIPOLYGON(((476959.6811853445 5031863.489812068,
> 476957.4350220412 5031734.807202603,
> 476957.4350220412 5031734.807202602,
> 476959.6811853445 5031863.489812068)),
> ....
> ,
> ((476957.4350220412 5031992.172421534,
> 476957.4350220412 5031992.172421533,
> 476959.6811853445 5031863.489812068,
> 476957.4350220412 5031992.172421534)))
>
> e quella importata (banana_valida) è cosi definita:
>
> MULTIPOLYGON(((476959.6811853445 5031863.489812068,
> 476957.4350220412 5031734.807202603,
> 476957.4350220412 5031734.807202602,
> 476959.6811853445 5031863.489812068)),
> ....
> ,
> ((476957.4350220412 5031992.172421534,
> 476957.4350220412 5031992.172421533,
> 476959.6811853445 5031863.489812068,
> 476957.4350220412 5031992.172421534)))
>
> SONO UGUALI !
>

"sembrano uguali" ... ma non lo sono affatto ... suspense ... :-)


> Ma il problema piu' piccante è come mai se guardo lo shapefile di
> Salvatore su QGIS, e ingrandisco fino al limite vedo che la geoemtria
> di spatialite e quella di salvatore si discostano, mentre se carico
> quella di salvatore su spalite4.0 e confronto i vertici (con ewkt che
> mi produce fino all'ultimo decimale) vedo che sono uguali ?
>
> Per rispondere a questa domanda, ho provato a usare su qgis, non lo
> shapefile esportato da splite, ma bensi direttamente splite.
>
> E ho scoperto l'arcano !
>
> La geometria valid_banana di Salvatore una volta caricata su 
> splite4.0
> (poi convertito in splite3.0 per poterlo vedere su qgis) si è 
> spostata
> . :))
>
> Quindi a questo punto l'ipotesi piu' probabile è che sia la procedura
> di esportazione/importazione di shapefiles di spatialite4 che perda
> qualche decimale.
>

no: e' PostGIS che si fuma qualche decimale; ecco spiegato perche' non
si ha una sovrapposizione perfetta :-D

EWKT = formato text = per quanti decimali possa utilizzare, qualcosina
        perde di sicuro

invece spatialite effettua un'importazione *binaria*, senza nessuna
conversione: ergo non puo' perdere precisione, non ci sono 
arrotondamenti
possibili. legge un DOUBLE e scrive esattamente il valore che ha letto.

contro-prova "stile San Tommaso"
=====================================================
476959.6811853445 5031863.489812068,
476957.4350220412 5031734.807202603,
476957.4350220412 5031734.807202602,
476959.6811853445 5031863.489812068

questi sono i primi valori "text" dell'EWKT di PostGIS
... invece questo e' quel che vedo da splite dopo avere
inserito nel mezzo una banale printf con formato "%1.16f"
(i.e. stampami ben 16 posizioni decimali):

476959.6811853445800000 5031863.4898120686000000
476957.4350220412600000 5031734.8072026037000000
476957.4350220412000000 5031734.8072026027000000
476959.6811853445800000 5031863.4898120686000000

come puoi facilmente verificare, PostGIS quando ha convertito da
binario a text si e' regolarmente "mangiato" l'ultimo decimale.

stiamo usando una scala metrica; quindi in pratica stiamo parlando
di micro-differenze di ordine "atomico" (circa un angstrom)
assolutamente insignificanti per qualsiasi scopo fisico, ma
probabilmente rilevanti per scopi topologici (dove si richiede
una coerenza ultra-paranoica, altrimenti tutto crolla).

comunque, alla fine siamo arrivati ad un punto fermo; l'importer
PostGIS basato su EWKT introduce dei nano-shifts nelle coordinate.
scoperta decisamente interessante; buono a sapersi.

ciao Sandro



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