[Gfoss] Risoluzione spaziale dataset

Giuseppe Patti gpatt a tiscali.it
Mer 12 Feb 2014 16:25:28 CET


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!

Saluti

On 12/02/2014 15:04, Jody Marca wrote:
> 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 <mailto: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 <mailto: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/4a44028b/attachment.html>


Maggiori informazioni sulla lista Gfoss