[Gfoss] Riparare geometria???

[Andrea Peri]

Daccordo.

L'importer di postgis probabilmente introduce uno shift, però anche il
tuo lo introduce.

Altrimenti non mi spiegherei perche' lo shapefile e lo sqlite su qgis
presentano la differenza che mostravo.

Ti metto a disposizione lo sqlite con dentro la geometria di Salvatore.

http://tinyurl.com/a9dh622

In esso ho caricato lo shapefile di Salvatore con il seguente comando,
.loadshp salvatore-larosa/valid_banana valid_banana CP1252 25832
geometry pippo MULTIPOLYGON 2d 0 1

Cosi' facendo mi disinteresso di quale sia il prodotto che ha generato
lo shapefile di Salvatore, lo prendo per buono e lo carico in
spatialite.

Dopodiche' l'unic altra operazione che faccio è convertire lo splite4
in uno splite3 per leggerlo con qgis.

Poi passo a confrontare a video lo shapefile di Salvatroe con lo splite.
Se l'importatore di splite non introducesse nessuna alterazione dovrei
vedere i medesimi risultati esatti.

Invece vedo delle microdifferenze.

In questo discorso postgis non viene toccato.

Andrea.

Il 02 marzo 2013 14:24,  <a.furieri a lqt.it> ha scritto:
> 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.
>



-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------