[Gfoss] Risoluzione spaziale dataset

[Jody Marca]

Solo una precisazione
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
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...
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.
--> Test: SELECT ST_equals(ST_GeomFromText('POINT(0  543523.124)'),
ST_SnapToGrid(ST_GeomFromText('POINT(0  543523.124)'), 0.001)  );
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...
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...)

Jody



2014-02-12 12:38 GMT+01:00 <a.furieri a lqt.it>:

> On Wed, 12 Feb 2014 12:11:06 +0100, Jody Marca wrote:
>
>> 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.
>>
>>
> ... mi permetto di aggiungere una "piccola" nota a margine per
> quanto riguarda l'efficienza di calcolo.
>
> moltissimi algoritmi di uso molto frequente in ambito GeoSpatial
> (lunghezze ed aree, minima distanza, intersezioni etc) richiedono
> montagne di calcoli trigonometrici in Floating Point.
>
> tutti i moderni microprocessori supportano direttamente in HW
> questo tipo di operazioni, e sono in grado di macinare un
> numero veramente impressionante di operazioni per secondo;
> e tutte le librerie matematiche di base (su qualsiasi sistema
> operativo) sono ottimizzate per spremere anche l'ultima
> goccia della potenza di calcolo offerta dall'HW
>
> per gli ultimi Intel i7 multicore (un processore normalmente
> usato per i PC di fascia alta) parliamo di circa 70/100 GigaFLOPS,
> cioe' quasi un centinaio di miliardi di operazioni al secondo.
> eppure (notoriamente) molte operazioni di calcolo GIS sono pur
> sempre di una lentezza mortale ;-)
>
> usare formati alternativi (Decimal, BigDeccimal) risolverebbe
> certamente qualsiasi problema di precisione ed arrotondamento,
> ma al prezzo di un rallentamento mortale della velocita' di
> calcolo, visto che occorrerebbe rinunciare a sfruttare il
> supporto HW floating point per usare piuttosto delle routines
> completamente implementate via sw e capaci di preservare
> inalterata una precisione di calcolo infinita.
>
> cioe' si tornerebbe sostanzialmente indietro nel tempo alla
> situazione tipica degli anni '70 ed '80 quando le CPU non
> offrivano nessun supporto HW per il floating point, che
> veniva piuttosto implementato tramite emulazione sw; oppure
> occorreva spendere un bel po' di soldini per acquistare a
> parte un co-processore math in grado di offrire supporto hw
>
> se la memoria non mi inganna, la differenza nella velocita'
> di calcolo tra "full HW" ed emulazione SW era di oltre cento
> volte :-D
>
> siamo veramente sicuri che un miglioramento marginale della
> precisione ultra-fine valga la pena di un siffatto handicap
> prestazionale ?
>
> ... e mi astengo volutamente da qualsiasi considerazione
> relativa agli spazi necessari per l'archiviazione dati, che
> ovviamente "gonfierebbero" in modo impressionante.
>
> ciao Sandro
>
>
>
> _______________________________________________
> Gfoss a 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.
> 666 iscritti al 22.7.2013
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20140212/87b962a0/attachment-0001.html>