Risoluzione spaziale dataset
Locked
 
|
Tieni presente che ci sono dei numeri
che in FP64 non sono esprimibili con un numero FINITO di cifre.
Ad esempio il valore 0.1 e quindi anche 0.01 0.001 0.00001 etc... 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. E non è l'unico. Lo snaptogrid non puo' bypassare il formato binario e quindi se deve esprimire un numero che in binario non si esprime deve per forza approssimarlo. A. On 16/01/2014 10:18, Giuseppe Patti wrote:
_______________________________________________ [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. 666 iscritti al 22.7.2013 |
|
|
In reply to this post by pcav
Cosi' risolvi solo il problema della rappresentazione a video.
Nel momento in cui lo memorizzi in una variabile double ritorna ad avere 17 cifre decimali. La memorizzazione con il numero di cifre voluto come ipotizzato è realizzabile solo con se si implementano variabili che memorizzano in BCD oppure in forma testuale il valore. A. On 16/01/2014 10:32, Paolo Cavallini wrote: > Il 16/01/2014 10:18, Giuseppe Patti ha scritto: >> 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? > Forse sarebbe piu' semplice scrivere un comando che consenta > l'arrotondamento a piacere (l'utente sceglie il N di cifre decimali da > mantenere). > Che ne dite? > Saluti. _______________________________________________ [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. 666 iscritti al 22.7.2013 |
Re: Risoluzione spaziale dataset
|
|
In reply to this post by Giuseppe Patti
Il giorno Thu, 16 Jan 2014 14:58:18 +0100
Giuseppe Patti <[hidden email]> ha scritto: ciao Giuseppe, > Mi permetto di fare un po' di sintesi. > > Giuliano (in Cc) si offre come donatore di codice e sviluppatore. sì, certo :-) con la (solita) precisazione che sono uno "sviluppatore domenicale"; se ho capito bene il thread (e mi viene qualche dubbio perchè ho sentito parlare di Precision Model che, ahimè :-( non so dove stia di casa, forse ho qualche riga di codice che opportunamente adattato può consentire il troncamento desiderato; > Io non sono in grado di metterci mano, ma se serve posso mettere due > eurini .... il mio obiettivo attuale è conoscere ed imparare ... ed ogni occasione è buona; > .... e dare il mio apporto come tester. questo lo davo per scontato :-) :-) :-) sarebbe oltremodo gradita l'attività di tutoring di chiunque abbia voglia di farla :-) anche se quello che ha appena detto Andrea P. circa la precisione in virgola mobile vanifica il mio progetto :-( > Grazie a te, ciao, giuliano _______________________________________________ [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. 666 iscritti al 22.7.2013 |
Re: Risoluzione spaziale dataset
|
|
Il giorno Thu, 16 Jan 2014 18:08:08 +0100
giulianc51 <[hidden email]> ha scritto: > Il giorno Thu, 16 Jan 2014 14:58:18 +0100 > Giuseppe Patti <[hidden email]> ha scritto: > > ........ ciao a tutti, così, per divertimento, ho messo insieme quelle routine di cui parlavo per affrontare l'arrotondamento delle coordinate (snapToGrid); alle prime, sommarie prove riscontro però il problema segnalato da Andrea: arrotondando ad es. a 3 cifre decimali (*) sembra andare tutto bene, ma poi trovo qualche coordinata con la ennesima cifra decimale occupata o con tutti 9 (**); sembra, dico sembra, che il troncamento all'intero funzioni meglio; fosse così si potrebbe scalare all'unità decimale desiderata troncando all'intero, ma non so la reazione di QGIS a trattare con coordinate dell'ordine di 7+7 = 14 cifre ! per cavare un ragno dal buco credo serva la consulenza di un esperto conoscitore della rappresentazione numerica decimale; my 2 cents :-) ciao, giuliano (*) non sono affari miei ma confesso di essere curioso di capire cosa serve, magari in un sistema GaussBoaga, con coordinate dell'ordine dei milioni di km, snappare a 10 microns (1/10**7), ma non sono affari miei :-) (**) credo che il campo numerico rappresentato digitalmente non sia continuo ! _______________________________________________ [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. 666 iscritti al 22.7.2013 |
Re: Risoluzione spaziale dataset
|
|
In reply to this post by Andrea Peri
Ciao a tutti,
Vorrei rianimare la discussione su questo thread (reperibile per intero qui: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Risoluzione-spaziale-dataset-tt7585941.html) finito poi su un binario morto ma che credo di grande importanza. L'occasione mi è data dal rilascio di due nuovi software, Shapefile Fixer e GeoUML Report Filler da parte dell'amico Jody Marca (http://www.jodymarca.com/it/) Che potete trovare alla pagina: http://www.jodymarca.com/tools/ Ai fini di questo thread è in particolare interessante lo Shapefile Fixer, che si occupa di arrotondamento di coordinate e di aggiustamento delle geometrie. 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. Allo scopo ho aperto un ticket su PostGis che trovate qui: http://trac.osgeo.org/postgis/ticket/2611 Sarebbe utile, credo, pervenire ad una gestione ragionata e trasparente (ovvero meno "randomica") di queste situazioni. Saluti a tutti! On 16/01/2014 16:50, aperi2007 wrote:
_______________________________________________ [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. 666 iscritti al 22.7.2013 |
|
Ciao Giuseppe, ciao a tutti 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 Prendo per esempio il caso del numero che mi hai segnalato 543523.124 Questo numero non è rappresentabile esattamente con il sistema double I passaggi per rappresentarlo richiede la normalizzazione del numero in base 2 -> 1,03668808746337890625 * 2^19 e la traduzione in binario (segno - esponente - mantissa ) 0 10000010010 0000100101100100011000111111011111001110110110010001 Il numero rappresentato è 543523.123999999952502548694611 + un errore che viene perso. 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. 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. Siamo sicuri che il sistema scelga proprio "0 10000010010 0000100101100100011000111111011111001110110110010001" ? potrebbe invece scegliere il double successivo (0 10000010010 0000100101100100011000111111011111001110110110010010) che corrisponde al numero 543523.124000000068917870521545 ? Guarda caso se io dovessi applicare un arrotondamento alla 10^-10 per la visualizzazione ottengo proprio 543523.12400000001 Ho fatto la seguente prova: - creo una tabella postgis con 1 geometria ST_GeomFromText('POINT(543523.124 543523.124)') la carico in openjump e vedo POINT(543523.124 543523.124) quindi desumo in double sia contenuto il valore 543523.12399... applico alla geometria ST_SnapToGrid(geom, 0.001) e ottengo POINT ( 543523.1240000001 543523.1240000001 ) quindi il contenuto del double è 543523.12400000006... Questo significa che o ST_SnapToGrid o le librerie di traduzione da PostGIS a JTS (utilizzato da Openjump) apportano questo cambio di rappresentazione interna 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 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. 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 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. Jody 2014-02-12 9:40 GMT+01:00 Giuseppe Patti <[hidden email]>:
_______________________________________________ [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. 666 iscritti al 22.7.2013
Research Assistant - Politecnico di Milano
Member of SpatialDBgroup |
|
|
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 _______________________________________________ [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. 666 iscritti al 22.7.2013 |
|
|
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 omogeneaSono 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... --> 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... Jody 2014-02-12 12:38 GMT+01:00 <[hidden email]>:
_______________________________________________ [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. 666 iscritti al 22.7.2013
Research Assistant - Politecnico di Milano
Member of SpatialDBgroup |
Re: Risoluzione spaziale dataset
|
|
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:
_______________________________________________ [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. 666 iscritti al 22.7.2013 |
| Free forum by Nabble | Edit this page |