[Gfoss] Risoluzione spaziale dataset
aperi2007
aperi2007 a gmail.com
Gio 16 Gen 2014 16:50:58 CET
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
>> <mailto: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
>> <mailto: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
>> <mailto:giohappy a gmail.com>>
>> To: Andrea Peri <aperi2007 a gmail.com
>> <mailto:aperi2007 a gmail.com>>
>> Cc: gfoss <gfoss a lists.gfoss.it
>> <mailto: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
>> <mailto: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 <mailto: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 <mailto: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
>>> <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
>>>
>>>
>>>
>>>
>>> --
>>> -----------------
>>> Andrea Peri
>>> . . . . . . . . .
>>> qwerty àèìòù
>>> -----------------
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>>
>>
>>
>>
>> --
>> -----------------
>> Andrea Peri
>> . . . . . . . . .
>> qwerty àèìòù
>> -----------------
>>
>>
>>
>>
>> --
>> -----------------
>> Andrea Peri
>> . . . . . . . . .
>> qwerty àèìòù
>> -----------------
>
-------------- parte successiva --------------
Un allegato HTML ? stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20140116/2c4066d8/attachment-0001.html>
Maggiori informazioni sulla lista
Gfoss