[Gfoss] Risoluzione spaziale dataset

Mer 12 Feb 2014 12:11:06 CET

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 <gpatt a tiscali.it>:

>  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:
>
> 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:
>
> 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?
>
>
> On 16/01/2014 09:22, Andrea Peri wrote:
>
>     Aggiungo un dettaglio che forse non è trascurabile.
>
> A parte la specifica utente:
>  snappare su griglia prefissata.
>
>  Se l'obiettivo vero è riprodurre la griglia del noto software commerciale.
>  Occorre stare molto attenti. Perche' la griglia cambia in base al box di
> imiego definito per il dataset.
> E il processo è irreversibile.
> Ovvero lo snap che egli effettua non è dinamico ma statico  al momento del
> caricamento.
> Dopodiche' resta quello.
> Se poi si sposta l'archivio su altra piattaforma lo snap puo'
> ulteriormente cambiare.
> Se poi si passa su uno shapefile, lo snap cambia ulteriormente perche' a
> quel punto interviene la griglia dell' FP64
>  E cosi' via.
> Per cui non è facile stabilire la griglia esatta da usare.
>  Occorrerebbe tracciare tutti i passaggi pregressi.
>
> 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.
>
>
>  A.
>
>
>
> Il giorno 16 gennaio 2014 09:03, Andrea Peri <aperi2007 a gmail.com> ha
> scritto:
>
>>    Se la griglia è regolare.
>> 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.
>> Poi carichi tale dataset su qgis e forzi lo snap di tutti gli altri
>> dataset su di esso.
>>
>>  Oppure altra opzione:
>> sempre in spatialite:
>>
>>  carici hi il dtaaset che devi portare su tale griglie e poi lanci:
>>
>>  update tabella set geometry = ST_SnapToGrid(.....)
>>
>> dove li' dentro ci scrivi punto di partenza e delta.
>>
>>  Dovrebbe funzionare.
>>
>>  Io ho usato una strategia simile per troncare (brutta parola, ma è per
>> tagliare corto) i dati del nostro DBT ristrutturato su due cifre decimali.
>>
>>  A.
>>
>>
>>
>> Il giorno 16 gennaio 2014 08:52, Giuseppe Patti <gpatt a tiscali.it> ha
>> scritto:
>>
>>  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.
>>>
>>>  Come risolveremmo il problema con strumenti GFoss?
>>>
>>>
>>>
>>>> ---------- Messaggio inoltrato ----------
>>>> From: "G. Allegri" <giohappy a gmail.com>
>>>> To: Andrea Peri <aperi2007 a gmail.com>
>>>> Cc: gfoss <gfoss a lists.gfoss.it>
>>>> Date: Wed, 15 Jan 2014 20:06:25 +0100
>>>> Subject: Re: [Gfoss] Risoluzione spaziale dataset
>>>>
>>>>  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).
>>>>
>>>> Mi sembra comunque che le questioni sono due:
>>>>
>>>> 1) come viene rappresentata una coordinata nel formato dati scelto
>>>>
>>>> 2) come viene gestita dal software
>>>>
>>>> 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.
>>>>
>>>> giovanni
>>>> Il 15/gen/2014 19:34 "aperi2007" <aperi2007 a gmail.com> ha scritto:
>>>>
>>>>>  Diciamo che tra parecch softwares si spostano in maniera trasparente.
>>>>>
>>>>> Un discorso a parte è il noto software commerciale , il quale
>>>>>
>>>>> UNICO AL MONDO adotta una riclassificazione in "quanti" della
>>>>> coordinata.
>>>>>
>>>>> Poiche' lui adotta un meccanismo che non trova riscontro in nessun
>>>>> altro software.
>>>>> Difficile che con altri software si riesca a riprodurre la sua
>>>>> coordinata.
>>>>> 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.
>>>>> Dipende da quali altri dataset sono caricati nel medesimo DB di
>>>>> partenza o di destinazione.
>>>>>
>>>>> A.
>>>>>
>>>>>
>>>>> On 15/01/2014 18:29, Giuseppe Patti wrote:
>>>>>
>>>>> 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:
>>>>>
>>>>>
>>>>> http://gis.stackexchange.com/questions/68636/spatial-precision-for-editing-in-multiple-gis-clients
>>>>>
>>>>> http://gis.stackexchange.com/questions/76939/qgis-polygon-precision
>>>>>
>>>>>
>>>>> Il giorno 15 gennaio 2014 18:01, Andrea Peri <aperi2007 a gmail.com> ha
>>>>> scritto:
>>>>>
>>>>>>  Il noto software commerciale permette di impostare la XY resolution
>>>>>> , ma all'aumentare della resolution diminuisce la BBOX ammessa.
>>>>>>  E viceversa.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Il giorno 15 gennaio 2014 17:44, Giuseppe Patti <gpatt a tiscali.it>ha scritto:
>>>>>>
>>>>>>>   Ciao. Vorrei approfondire con voi la questione della risoluzione
>>>>>>> spaziale di dati vettoriali nella quale sono incappato.
>>>>>>>  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.
>>>>>>>
>>>>>>>  Saluti
>>>>>>>
>>>>>>>  _______________________________________________
>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> -----------------
>>>>>> Andrea Peri
>>>>>> . . . . . . . . .
>>>>>> qwerty àèìòù
>>>>>> -----------------
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________Gfoss a lists.gfoss.ithttp://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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>>
>>
>> --
>> -----------------
>> Andrea Peri
>> . . . . . . . . .
>> qwerty àèìòù
>> -----------------
>>
>
>
>
> --
> -----------------
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -----------------
>
>
>
>
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20140212/55bb9071/attachment-0001.html>