<div dir="ltr">
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-size:12pt;font-family:"Times New Roman","serif"">Ciao
Giuseppe, ciao a tutti</span></p>
<p class="MsoNormal"><span style="font-size:12pt;line-height:115%;font-family:"Times New Roman","serif"">Ho letto la discussione e mi sembra che la fonte del problema sia già stato
inquadrato da Andrea; infatti nasce tutto dalla difficoltà di rappresentare l'insieme
infinito dei numeri reali con il double che ha un uno numero di bit finito</span></p><p class="MsoNormal"><span style="font-size:12pt;line-height:115%;font-family:"Times New Roman","serif"">Prendo per esempio il caso del numero che mi hai segnalato 543523.124</span></p>
<p class="MsoNormal"><span style="font-size:12pt;line-height:115%;font-family:"Times New Roman","serif"">Questo numero non è rappresentabile esattamente con il sistema double</span></p>
<p class="MsoNormal"><span style="font-size:12pt;line-height:115%;font-family:"Times New Roman","serif"">I passaggi per rappresentarlo richiede la normalizzazione del numero in
base 2 -><span style> </span>1,03668808746337890625 *
2^19</span></p>
<p class="MsoNormal"><span style="font-size:12pt;line-height:115%;font-family:"Times New Roman","serif"">e la traduzione in binario (segno - esponente - mantissa ) <br></span></p><p class="MsoNormal">
<span style="font-size:12pt;line-height:115%;font-family:"Times New Roman","serif"">0 10000010010 0000100101100100011000111111011111001110110110010001 </span></p>
<p class="MsoNormal"><span style="font-size:12pt;line-height:115%;font-family:"Times New Roman","serif"">Il numero rappresentato è 543523.123999999952502548694611 + un errore che viene
perso.</span></p>
<p class="MsoNormal"><span style="font-size:12pt;line-height:115%;font-family:"Times New Roman","serif"">Se io dovessi memorizzare questo numero così com'è e poi rileggerlo
otterrei sempre lo stesso numero e se in visualizzazione dovessi applicare un
arrotondamento alla 10^-10 comunque otterrei 543523.124. </span></p>
<p class="MsoNormal"><span style="font-size:12pt;line-height:115%;font-family:"Times New Roman","serif"">Quello che stiamo facendo noi però non è la memorizzazione di un numero
inserito ma di un numero ottenuto da un processo di rounding e riposizionato
sulla griglia dei double che com'è detto non è omogenea ma è molto più fitta
quanto più ci si avvicina allo 0 e tanto più rada quando si va verso infinito. </span></p>
<p class="MsoNormal"><span style="font-size:12pt;line-height:115%;font-family:"Times New Roman","serif"">Siamo sicuri che il sistema scelga proprio "0 10000010010 0000100101100100011000111111011111001110110110010001" ?</span></p>
<p class="MsoNormal"><span style="font-size:12pt;line-height:115%;font-family:"Times New Roman","serif"">potrebbe invece scegliere il double successivo (0 10000010010
0000100101100100011000111111011111001110110110010010) che corrisponde al numero
543523.124000000068917870521545 ?</span></p>
<p class="MsoNormal"><span style="font-size:12pt;line-height:115%;font-family:"Times New Roman","serif"">Guarda caso se io dovessi applicare <span style> </span>un
arrotondamento alla 10^-10 per la visualizzazione ottengo proprio 543523.12400000001</span></p>
<p class="MsoNormal"><span style="font-size:12pt;line-height:115%;font-family:"Times New Roman","serif"">Ho fatto la seguente prova:</span></p>
<p class="MsoNormal"><span style="font-size:12pt;line-height:115%;font-family:"Times New Roman","serif"">- creo una tabella postgis con 1 geometria ST_GeomFromText('POINT(543523.124<span style> </span>543523.124)')</span></p>
<p class="MsoNormal"><span style="font-size:12pt;line-height:115%;font-family:"Times New Roman","serif"">la carico in openjump e vedo POINT(543523.124<span style> </span>543523.124) quindi desumo in double sia
contenuto il valore 543523.12399... </span></p>
<p class="MsoNormal"><span style="font-size:12pt;line-height:115%;font-family:"Times New Roman","serif"">applico alla geometria ST_SnapToGrid(geom, 0.001) e ottengo POINT (
543523.1240000001 543523.1240000001 ) quindi il contenuto del double è 543523.12400000006...</span></p>
<p class="MsoNormal"><span style="font-size:12pt;line-height:115%;font-family:"Times New Roman","serif"">Questo significa che o ST_SnapToGrid o le librerie di traduzione da PostGIS
a JTS (utilizzato da Openjump) apportano questo cambio di rappresentazione
interna</span></p>
<p class="MsoNormal"><span style="font-size:12pt;line-height:115%;font-family:"Times New Roman","serif"">Il problema a mio parere può nascere quando si devono far convivere
geometrie che hanno subito uno snap con griglie differenti o con algoritmi
differenti. Se dovessi usare in openjump/qgis.... degli shape che arrivano da
sistemi diversi non eseguo un'arrotonda coordinate potrei avere delle
violazioni di alcune regole topologiche in fase di validazione. Consiglio è
applicare sempre un arrotondamento con il medesimo algoritmo (sia ST_SnapToGrid
o Shapefile Fixer o un altro programma) è vero che avrai delle modifiche minime
della geometria ma andrai a salvaguardare le regole topologiche</span></p>
<p class="MsoNormal"><span style="font-size:12pt;line-height:115%;font-family:"Times New Roman","serif"">Se poi dovessi reimportare questi dati nel sistema con tolleranza XY
diciamo inferiore a 10^-8 (per essere cauti) il problema dovrebbe risolversi da
solo poichè tutte le coordinate saranno ricalcolate in base alla griglia.</span></p>
<p class="MsoNormal"><span style="font-size:12pt;line-height:115%;font-family:"Times New Roman","serif"">L'altra questione relativa all'utilizzo snap superiore a 1; in verità il
problema della rappresentazione non sparisce ma avendo tutto l'esponente
utilizzabile per la memorizzazione del numero intero è trascurabile infatti
inizia ad essere difficili rappresentare interi quando superiamo il 10^10 /
10^15 quindi per il dominio delle coordinate spaziali penso sia trascurabile</span></p>
<p class="MsoNormal"><span style="font-size:12pt;line-height:115%;font-family:"Times New Roman","serif"">Come fare a risolvere questi problemi? Semplice non utilizzare il double
per la memorizzazione come del resto si fa in molti contesti dove gli errori di
rappresentazione non sono ammessi. Pur esistendoci dei tipi di dato sostitutivi
(es Bigdecimal.... ) non credo sia pensabile risolvere definitivamente tale
problema a breve poichè questo implicherebbe abbandonare gli shapefile e
soprattutto aggiornare la maggior parte dei software commerciali e non.</span></p>
<p class="MsoNormal"><span style="font-size:12pt;line-height:115%;font-family:"Times New Roman","serif"">Jody</span></p>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-02-12 9:40 GMT+01:00 Giuseppe Patti <span dir="ltr"><<a href="mailto:gpatt@tiscali.it" target="_blank">gpatt@tiscali.it</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Ciao a tutti,<br>
<br>
Vorrei rianimare la discussione su questo thread (reperibile per
intero qui:
<a href="http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Risoluzione-spaziale-dataset-tt7585941.html" target="_blank">http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Risoluzione-spaziale-dataset-tt7585941.html</a>)
finito poi su un binario morto ma che credo di grande importanza.<br>
<br>
L'occasione mi è data dal rilascio di due nuovi software,
Shapefile Fixer e GeoUML Report Filler da parte dell'amico Jody
Marca (<a href="http://www.jodymarca.com/it/" target="_blank">http://www.jodymarca.com/it/</a>)<br>
<br>
Che potete trovare alla pagina:<br>
<br>
<a href="http://www.jodymarca.com/tools/" target="_blank">http://www.jodymarca.com/tools/</a><br>
<br>
Ai fini di questo thread è in particolare interessante lo
Shapefile Fixer, che si occupa di arrotondamento di coordinate e
di aggiustamento delle geometrie.<br>
<br>
Anche in questo caso però si ripresenta l'inghippo che ha
originato questa discussione: arrotondate le cifre decimali dei
vertici che rappresentano una geometria ad un numero fissato, mi
aspetto che se imposto la precisione a 3 cifre decimali il vertice
543523.1237 diventi 543523.124 ed in effetti questo è quello che
succede. Però se provo ad interrogare quella geometria arrotondata
chiedendone il wkt (ad es. in QGis) mi ritorna una
rappresentazione che è "molto prossima" a quella arrotondata ma
non esattamente arrotondata, del tipo
543523.123999900000000034252. Credo che questo problema sia legato
alla "virgola mobile", infatti lo stesso problema mi si ripresenta
se uso ST_SnapToGrid in Postgis o Spatialite, oppure lo strumento
"Semplifica geometrie" di OpenJump. Ovviamente il problema non si
presenta in ST_SnapToGrid se imposto uno "snap" molto alto
(superiore a 1) che a quel punto taglia tutta la parte decimale.<br>
<br>
Allo scopo ho aperto un ticket su PostGis che trovate qui:<br>
<br>
<a href="http://trac.osgeo.org/postgis/ticket/2611" target="_blank">http://trac.osgeo.org/postgis/ticket/2611</a><br>
<br>
Sarebbe utile, credo, pervenire ad una gestione ragionata e
trasparente (ovvero meno "randomica") di queste situazioni.<br>
<br>
Saluti a tutti!<div><div class="h5"><br>
<br>
<br>
<br>
<br>
On 16/01/2014 16:50, aperi2007 wrote:<br>
</div></div></div><div><div class="h5">
<blockquote type="cite">
<div>Tieni presente che ci sono dei numeri
che in FP64 non sono esprimibili con un numero FINITO di cifre.<br>
<br>
Ad esempio il valore 0.1<br>
e quindi anche 0.01 0.001 0.00001 etc...<br>
puo' sembrare strano , ma non è espirmiile con un numero finito
di cifre e quindi se lo memorizzi in una variabile Double e poi
lo vai a rileggere ti ritorna con tutte e 17 le cifre decimali.<br>
E non è l'unico.<br>
Lo snaptogrid <br>
non puo' bypassare il formato binario e quindi se deve esprimire
un numero che in binario non si esprime deve per forza
approssimarlo.<br>
<br>
A.<br>
<br>
On 16/01/2014 10:18, Giuseppe Patti wrote:<br>
</div>
<blockquote type="cite">
<div>E infatti io avrei usato
ST_SnapToGrid, però se poi vado a chiedere la geometria del
poligono dopo lo snap mi tornano fuori le 17 cifre. Sbaglio io
qualcosa o capisco male il funzionamento di ST_SnapToGrid?<br>
<br>
<br>
On 16/01/2014 09:22, Andrea Peri wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>Aggiungo un dettaglio che forse non è
trascurabile.<br>
<br>
A parte la specifica utente:<br>
</div>
snappare su griglia prefissata.<br>
</div>
<br>
</div>
Se l'obiettivo vero è riprodurre la griglia del noto
software commerciale.<br>
</div>
Occorre stare molto attenti. Perche' la griglia cambia
in base al box di imiego definito per il dataset.<br>
E il processo è irreversibile.<br>
Ovvero lo snap che egli effettua non è dinamico ma
statico al momento del caricamento.<br>
Dopodiche' resta quello.<br>
Se poi si sposta l'archivio su altra piattaforma lo
snap puo' ulteriormente cambiare.<br>
Se poi si passa su uno shapefile, lo snap cambia
ulteriormente perche' a quel punto interviene la
griglia dell' FP64<br>
</div>
<div>E cosi' via.<br>
Per cui non è facile stabilire la griglia esatta da
usare.<br>
</div>
Occorrerebbe tracciare tutti i passaggi pregressi.<br>
</div>
<br>
Evito di partire con il solito pistolotto alla luna che
sarebbe utile che queste cose venissero riportate nel
lineage di una eventuale scheda di metadato , perche'
serve proprio a profilare questo genere di situazioni. La
specifica nazionale prevede altre metodiche che non
incoraggiano questo tipo di informazione e quindi lascio
perdere pure io.<br>
<br>
<br>
</div>
A.<br>
<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">Il giorno 16 gennaio 2014 09:03,
Andrea Peri <span dir="ltr"><<a href="mailto:aperi2007@gmail.com" target="_blank">aperi2007@gmail.com</a>></span>
ha scritto:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>Se la griglia è regolare.<br>
Prendi spatialite, con esso ti fai
generare un dataset che è una griglia
rettangolare che parte da una coordinata
che gli dici te e che ha un delta pari
all'incremento.<br>
Poi carichi tale dataset su qgis e forzi
lo snap di tutti gli altri dataset su di
esso.<br>
<br>
</div>
Oppure altra opzione:<br>
sempre in spatialite:<br>
<br>
</div>
carici hi il dtaaset che devi portare su tale
griglie e poi lanci:<br>
<br>
</div>
update tabella set geometry =
ST_SnapToGrid(.....)<br>
<br>
dove li' dentro ci scrivi punto di partenza e
delta.<br>
<br>
</div>
Dovrebbe funzionare.<br>
<br>
</div>
Io ho usato una strategia simile per troncare
(brutta parola, ma è per tagliare corto) i dati del
nostro DBT ristrutturato su due cifre decimali.<br>
<br>
</div>
A.<br>
<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">Il giorno 16 gennaio 2014
08:52, Giuseppe Patti <span dir="ltr"><<a href="mailto:gpatt@tiscali.it" target="_blank">gpatt@tiscali.it</a>></span>
ha scritto:
<div>
<div><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>Mettiamola così allora: un cliente vi
commissiona un dataset vettoriale in cui i
vertici delle geometrie devono essere
precisamente posizionati su una griglia a
spaziatura omogenea XY pari a 1e^-7,
eventuali cifre dopo la settima decimale
devono essere al limite pari a zero,
eventuali geometrie che in seguito ad
operazioni di processing dovessero
risultare con coordinate differenti devono
essere ricondotte al caso precedente.<br>
<br>
</div>
Come risolveremmo il problema con strumenti
GFoss?<br>
<div>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
---------- Messaggio inoltrato
----------<br>
From: "G. Allegri" <<a href="mailto:giohappy@gmail.com" target="_blank">giohappy@gmail.com</a>><br>
To: Andrea Peri <<a href="mailto:aperi2007@gmail.com" target="_blank">aperi2007@gmail.com</a>><br>
Cc: gfoss <<a href="mailto:gfoss@lists.gfoss.it" target="_blank">gfoss@lists.gfoss.it</a>><br>
Date: Wed, 15 Jan 2014 20:06:25
+0100<br>
Subject: Re: [Gfoss] Risoluzione
spaziale dataset
<div>
<div><br>
<p dir="ltr"> Il problema
degli arrotondamenti investe
qualsiasi problema
geometrico computazionale.
Ci sono librerie come le
CGAL in grado di lavorare
con precisione arbitraria,
ma la maggior parte dei
software implementa le
proprie strategie per
gestire i problemi del
floating point. Non so se la
"portabilità della
precisione" sia un problema
risolvibile, certamente i
software che sfruttano
librerie geometriche comuni
(vedi GEOS) possono
sfruttarne la trasparenza
per gestire la cosa, ad es.
tramite il Precision Model
(usato ad es. dallo
SnapToGrid di PostGIS). </p>
<p dir="ltr">Mi sembra
comunque che le questioni
sono due: </p>
<p dir="ltr">1) come viene
rappresentata una coordinata
nel formato dati scelto</p>
<p dir="ltr">2) come viene
gestita dal software </p>
<p dir="ltr">Il primo credo
non sia un problema, visti i
tanti mezzi che ci sono
(dallo shapefile a PostGIS,
ecc.) . Il secondo... bhè,
finché un sw è chiuso c'è
poco da discutere. </p>
<p dir="ltr">giovanni</p>
<div class="gmail_quote">Il
15/gen/2014 19:34
"aperi2007" <<a href="mailto:aperi2007@gmail.com" target="_blank">aperi2007@gmail.com</a>>
ha scritto:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>Diciamo che tra
parecch softwares si
spostano in maniera
trasparente.<br>
<br>
Un discorso a parte è
il noto software
commerciale , il quale<br>
<br>
UNICO AL MONDO adotta
una riclassificazione
in "quanti" della
coordinata.<br>
<br>
Poiche' lui adotta un
meccanismo che non
trova riscontro in
nessun altro software.<br>
Difficile che con
altri software si
riesca a riprodurre la
sua coordinata.<br>
Oltre tutto , se
prendi due PC con il
medesimo software
commerciale, non è
assolutamente detto
che quando sposti da
uno all'altro la
coordinata ti rimane
invariata.<br>
Dipende da quali altri
dataset sono caricati
nel medesimo DB di
partenza o di
destinazione.<br>
<br>
A.<br>
<br>
<br>
On 15/01/2014 18:29,
Giuseppe Patti wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Sono
d'accordo, ma questo
è un altro aspetto
del problema. Rimane
il nocciolo: se io
devo spostare degli
shape da un sw ad un
altro, è possibile
garantire la
consistenza delle
coordinate? Non
penso sia un
problema peregrino,
ho trovato
discussioni analoghe
con soluzioni
"esoteriche" anche
qui:<br>
<br>
<a href="http://gis.stackexchange.com/questions/68636/spatial-precision-for-editing-in-multiple-gis-clients" target="_blank">http://gis.stackexchange.com/questions/68636/spatial-precision-for-editing-in-multiple-gis-clients</a><br>
<br>
<a href="http://gis.stackexchange.com/questions/76939/qgis-polygon-precision" target="_blank">http://gis.stackexchange.com/questions/76939/qgis-polygon-precision</a><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">Il
giorno 15
gennaio 2014
18:01, Andrea
Peri <span dir="ltr"><<a href="mailto:aperi2007@gmail.com" target="_blank">aperi2007@gmail.com</a>></span>
ha scritto:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>Il noto
software
commerciale
permette di
impostare la
XY resolution
, ma
all'aumentare
della
resolution
diminuisce la
BBOX ammessa.<br>
</div>
E viceversa.<br>
<br>
Per cui ti
crea un bel
problema anche
lui. Perche'
ovviamente o
ammetti una
resolution
veramente
bassa (leggi
scarsa) oppure
non riesci a
spostare il
dataset su
basi dati di
lvello
nazionale
anziche'
locale.<br>
<br>
<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">Il
giorno 15
gennaio 2014
17:44,
Giuseppe Patti
<span dir="ltr"><<a href="mailto:gpatt@tiscali.it" target="_blank">gpatt@tiscali.it</a>></span>
ha scritto:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div dir="ltr">
<div>
<div>Ciao.
Vorrei
approfondire
con voi la
questione
della
risoluzione
spaziale di
dati
vettoriali
nella quale
sono
incappato.<br>
</div>
In particolare
mi riferisco
alla
precisione
delle
coordinate ad
es. di uno
shape, che
continuano a
variare
passando da un
software
all'altro. In
quale modo,
anche
appoggiandosi
ad un DB,
sarebbe
possibile
essere sicuri
di avere
coordinate di
precisione
nota e
costante
settando il
numero di
cifre decimali
alle quali
arrotondare?
Ad esempio un
noto sw
commerciale fa
impostare i
valori di
XY_resolution
e XY_tolerance
creando un
file
geodatabase,
sarebbe
interessante
capire se
esiste la
possibilità di
raggiungere lo
stesso
risultato
anche con
GFOSS.<br>
<br>
</div>
Saluti<br>
</div>
<br>
</div>
_______________________________________________<br>
<a href="mailto:Gfoss@lists.gfoss.it" target="_blank">Gfoss@lists.gfoss.it</a><br>
<a href="http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss" target="_blank">http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss</a><br>
Questa e' una
lista di
discussione
pubblica
aperta a
tutti.<br>
I messaggi di
questa lista
non hanno
relazione
diretta con le
posizioni
dell'Associazione
GFOSS.it.<br>
666 iscritti
al 22.7.2013<span><font color="#888888"><br>
</font></span></blockquote>
</div>
<span><font color="#888888"><br>
<br clear="all">
<br>
-- <br>
-----------------<br>
Andrea Peri<br>
. . . . . . .
. . <br>
qwerty àèìòù<br>
-----------------<br>
</font></span></div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
<a href="mailto:Gfoss@lists.gfoss.it" target="_blank">Gfoss@lists.gfoss.it</a>
<a href="http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss" target="_blank">http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss</a>
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.
666 iscritti al 22.7.2013</pre>
</blockquote>
<br>
</div>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
<br>
_______________________________________________<br>
<a href="mailto:Gfoss@lists.gfoss.it" target="_blank">Gfoss@lists.gfoss.it</a><br>
<a href="http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss" target="_blank">http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss</a><br>
Questa e' una lista di discussione pubblica
aperta a tutti.<br>
I messaggi di questa lista non hanno relazione
diretta con le posizioni dell'Associazione
GFOSS.it.<br>
666 iscritti al 22.7.2013<br>
</blockquote>
</div>
</div>
</div>
<div>
<div><br>
<br clear="all">
<br>
-- <br>
-----------------<br>
Andrea Peri<br>
. . . . . . . . . <br>
qwerty àèìòù<br>
-----------------<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
-----------------<br>
Andrea Peri<br>
. . . . . . . . . <br>
qwerty àèìòù<br>
-----------------<br>
</div>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>