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.
_______________________________________________
Gfoss@lists.gfoss.it
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
