Gfoss -- Geographic Free and Open Source Software - Italian mailing list

Riparare geometria???

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Andrea Peri

Riparare geometria???

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

E poi ho confrontato l'ewkt di entrambe quella corretta da spatialite
e quella che era stata corretta da postgis.

In entrambe compare tutti e tre le componenti da te evidenziate.

Ignorando quella piu' grande, ma concentrando l'atteznione su le due
piu' piccole (4 vertici ciascuna) vedo che

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 !

Mettiamo per un attimo da parte il perche' crea questi due poligoni.
L'importante è che siano validi (e in effetti lo sono).

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.

Sicuramente avviene con l'importazione, visto che confrontando lo
shapefile con la sua importazione su splite tramite qgis si osserva
questo spostamento.

vedi immagine allegata.

Ed è quindi per questo che quando Salvatore è andato a confrontare lo
shapefile di postgis con quello che avevo esportato da splite ha
rilevato qualche decimale di differenza.
:))

Andrea.

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

_______________________________________________
[hidden email]
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

img1.gif (17K) Download Attachment

a.furieri

Re: Riparare geometria???

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.

_______________________________________________
[hidden email]
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

Andrea Peri

Re: Riparare geometria???

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, <[hidden email]> 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 àèìòù
-----------------
_______________________________________________
[hidden email]
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

a.furieri

Re: Riparare geometria???

On Sat, 2 Mar 2013 14:47:08 +0100, Andrea Peri wrote:

> 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,

non riesco a replicare il problema in nessun modo:
- mi sono installato l'ultimissimo QGIS 1.9.0 "nightly build" su WinXP
- apro lo SHP "valid_banana" che ci ha spedito Salvatore
[makeValidPostGIS.zip]
- poi apro lo sqlite che mi hai inviato tu [test-import.zip]

ma li vedo sempre esattamente sovrapposti anche zoommando a fattori di
scala ultra-esagerati; ho provato a spostarli sotto-sopra, le linee si
coprono perfettamente in tutti i casi, senza nessuno scostamento.
perche' vediamo risultati cosi' differenti ? non capisco ...

[1] http://www.gaia-gis.it/mkvld/full-extent.png
[2] http://www.gaia-gis.it/mkvld/max-zoom.png

ciao Sandro

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

_______________________________________________
[hidden email]
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