[Gfoss] Risoluzione spaziale dataset
Giuseppe Patti
gpatt a tiscali.it
Mer 12 Feb 2014 09:40:22 CET
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
>>> <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/20140212/ad480800/attachment-0001.html>
Maggiori informazioni sulla lista
Gfoss