<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Grazie mille a tutti per le illuminanti
delucidazioni. Mi chiedo solo perché alcune procedure ti chiedano
"certe" precisioni che poi in uno shapefile definito "di consegna"
non possono essere mantenute.....transeat!<br>
<br>
Saluti<br>
<br>
On 12/02/2014 15:04, Jody Marca wrote:<br>
</div>
<blockquote
cite="mid:%3CCAC=PJqnXx8AQs3RXGDpt3ZHAyJnjAww8Hkkce2A3P_EhPzy=1w@mail.gmail.com%3E"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>Solo una precisazione<br>
</div>
io NON sono favorevole ad una migrazione da double ad un
datatype diverso, quello che ho detto era un modo per
risolverle il problema perchè è causato dal formato di
memorizzazione che non consente l'utilizzo di una griglia
omogenea<br>
Sono sfavorevole non tanto per motivi prestazionali, anche
se condivido pienamente quanto scritto da Sandro, ma
perchè si dovrebbero aggiornare tutti gli applicativi ed
abbandonare gli shapefile cosa che ad oggi penso sia pura
fantasia...<br>
</div>
Come ho già detto il mio consiglio, e approccio abituale, è
quello di applicare un'arrotondamento omogeneo su tutto il
dataset dei dati poichè il problema non è marginale. <br>
--> Test: SELECT ST_equals(ST_GeomFromText('POINT(0
543523.124)'), ST_SnapToGrid(ST_GeomFromText('POINT(0
543523.124)'), 0.001) );<br>
Se uso l'operatore ST_Equals passando come primo parametro
il punto POINT(0 543523.124) e come secondo parametro lo
stesso punto dopo lo l'arrotondamento potrei ottenere false;
lo stesso problema potrebbe quindi creare sliver polygon,
reti non connesse, touch che diventano overlap o disjoint...<br>
</div>
</div>
I sistemi commerciali solitamente aggirano il problema con la
valutazione con tolleranza; resta perà da capire che cosa si
intende per tolleranza poichè può essere implementata in n modi
diversi (ma questa è un'altra storia e non vorrei aprire il vaso
di pandora...)<br>
<div>
<div><br>
Jody<br>
<br>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2014-02-12 12:38 GMT+01:00 <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:a.furieri@lqt.it" target="_blank">a.furieri@lqt.it</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On Wed, 12 Feb 2014 12:11:06 +0100, Jody Marca
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Come fare a risolvere questi problemi? Semplice non
utilizzare il<br>
double per la memorizzazione come del resto si fa in
molti contesti<br>
dove gli errori di rappresentazione non sono ammessi.
Pur esistendoci<br>
dei tipi di dato sostitutivi (es Bigdecimal.... ) non
credo sia<br>
pensabile risolvere definitivamente tale problema a
breve poichè<br>
questo implicherebbe abbandonare gli shapefile e
soprattutto<br>
aggiornare la maggior parte dei software commerciali e
non.<br>
<br>
</blockquote>
<br>
</div>
... mi permetto di aggiungere una "piccola" nota a margine
per<br>
quanto riguarda l'efficienza di calcolo.<br>
<br>
moltissimi algoritmi di uso molto frequente in ambito
GeoSpatial<br>
(lunghezze ed aree, minima distanza, intersezioni etc)
richiedono<br>
montagne di calcoli trigonometrici in Floating Point.<br>
<br>
tutti i moderni microprocessori supportano direttamente in
HW<br>
questo tipo di operazioni, e sono in grado di macinare un<br>
numero veramente impressionante di operazioni per secondo;<br>
e tutte le librerie matematiche di base (su qualsiasi
sistema<br>
operativo) sono ottimizzate per spremere anche l'ultima<br>
goccia della potenza di calcolo offerta dall'HW<br>
<br>
per gli ultimi Intel i7 multicore (un processore normalmente<br>
usato per i PC di fascia alta) parliamo di circa 70/100
GigaFLOPS,<br>
cioe' quasi un centinaio di miliardi di operazioni al
secondo.<br>
eppure (notoriamente) molte operazioni di calcolo GIS sono
pur<br>
sempre di una lentezza mortale ;-)<br>
<br>
usare formati alternativi (Decimal, BigDeccimal)
risolverebbe<br>
certamente qualsiasi problema di precisione ed
arrotondamento,<br>
ma al prezzo di un rallentamento mortale della velocita' di<br>
calcolo, visto che occorrerebbe rinunciare a sfruttare il<br>
supporto HW floating point per usare piuttosto delle
routines<br>
completamente implementate via sw e capaci di preservare<br>
inalterata una precisione di calcolo infinita.<br>
<br>
cioe' si tornerebbe sostanzialmente indietro nel tempo alla<br>
situazione tipica degli anni '70 ed '80 quando le CPU non<br>
offrivano nessun supporto HW per il floating point, che<br>
veniva piuttosto implementato tramite emulazione sw; oppure<br>
occorreva spendere un bel po' di soldini per acquistare a<br>
parte un co-processore math in grado di offrire supporto hw<br>
<br>
se la memoria non mi inganna, la differenza nella velocita'<br>
di calcolo tra "full HW" ed emulazione SW era di oltre cento<br>
volte :-D<br>
<br>
siamo veramente sicuri che un miglioramento marginale della<br>
precisione ultra-fine valga la pena di un siffatto handicap<br>
prestazionale ?<br>
<br>
... e mi astengo volutamente da qualsiasi considerazione<br>
relativa agli spazi necessari per l'archiviazione dati, che<br>
ovviamente "gonfierebbero" in modo impressionante.<br>
<br>
ciao Sandro
<div class="HOEnZb">
<div class="h5"><br>
<br>
<br>
_______________________________________________<br>
<a moz-do-not-send="true"
href="mailto:Gfoss@lists.gfoss.it" target="_blank">Gfoss@lists.gfoss.it</a><br>
<a moz-do-not-send="true"
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</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>