<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Ciao a tutti,<br>
<br>
Vorrei rianimare la discussione su questo thread (reperibile per
intero qui:
<a class="moz-txt-link-freetext" href="http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Risoluzione-spaziale-dataset-tt7585941.html">http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Risoluzione-spaziale-dataset-tt7585941.html</a>)
finito poi su un binario morto ma che credo di grande importanza.<br>
<br>
L'occasione mi è data dal rilascio di due nuovi software,
Shapefile Fixer e GeoUML Report Filler da parte dell'amico Jody
Marca (<a class="moz-txt-link-freetext" href="http://www.jodymarca.com/it/">http://www.jodymarca.com/it/</a>)<br>
<br>
Che potete trovare alla pagina:<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.jodymarca.com/tools/">http://www.jodymarca.com/tools/</a><br>
<br>
Ai fini di questo thread è in particolare interessante lo
Shapefile Fixer, che si occupa di arrotondamento di coordinate e
di aggiustamento delle geometrie.<br>
<br>
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.<br>
<br>
Allo scopo ho aperto un ticket su PostGis che trovate qui:<br>
<br>
<a class="moz-txt-link-freetext" href="http://trac.osgeo.org/postgis/ticket/2611">http://trac.osgeo.org/postgis/ticket/2611</a><br>
<br>
Sarebbe utile, credo, pervenire ad una gestione ragionata e
trasparente (ovvero meno "randomica") di queste situazioni.<br>
<br>
Saluti a tutti!<br>
<br>
<br>
<br>
<br>
On 16/01/2014 16:50, aperi2007 wrote:<br>
</div>
<blockquote cite="mid:52D7FFE2.2000808@gmail.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Tieni presente che ci sono dei numeri
che in FP64 non sono esprimibili con un numero FINITO di cifre.<br>
<br>
Ad esempio il valore 0.1<br>
e quindi anche 0.01 0.001 0.00001 etc...<br>
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.<br>
E non è l'unico.<br>
Lo snaptogrid <br>
non puo' bypassare il formato binario e quindi se deve esprimire
un numero che in binario non si esprime deve per forza
approssimarlo.<br>
<br>
A.<br>
<br>
On 16/01/2014 10:18, Giuseppe Patti wrote:<br>
</div>
<blockquote cite="mid:52D7A3F8.4070506@tiscali.it" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">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?<br>
<br>
<br>
On 16/01/2014 09:22, Andrea Peri wrote:<br>
</div>
<blockquote
cite="mid:CABqTJk_PObOVmf6LWg5MHsWWVy1J+b8VQx6wLid+gpv=ibv-CA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>Aggiungo un dettaglio che forse non è
trascurabile.<br>
<br>
A parte la specifica utente:<br>
</div>
snappare su griglia prefissata.<br>
</div>
<br>
</div>
Se l'obiettivo vero è riprodurre la griglia del noto
software commerciale.<br>
</div>
Occorre stare molto attenti. Perche' la griglia cambia
in base al box di imiego definito per il dataset.<br>
E il processo è irreversibile.<br>
Ovvero lo snap che egli effettua non è dinamico ma
statico al momento del caricamento.<br>
Dopodiche' resta quello.<br>
Se poi si sposta l'archivio su altra piattaforma lo
snap puo' ulteriormente cambiare.<br>
Se poi si passa su uno shapefile, lo snap cambia
ulteriormente perche' a quel punto interviene la
griglia dell' FP64<br>
</div>
<div>E cosi' via.<br>
Per cui non è facile stabilire la griglia esatta da
usare.<br>
</div>
Occorrerebbe tracciare tutti i passaggi pregressi.<br>
</div>
<br>
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.<br>
<br>
<br>
</div>
A.<br>
<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">Il giorno 16 gennaio 2014 09:03,
Andrea Peri <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:aperi2007@gmail.com" target="_blank">aperi2007@gmail.com</a>></span>
ha scritto:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>Se la griglia è regolare.<br>
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.<br>
Poi carichi tale dataset su qgis e forzi
lo snap di tutti gli altri dataset su di
esso.<br>
<br>
</div>
Oppure altra opzione:<br>
sempre in spatialite:<br>
<br>
</div>
carici hi il dtaaset che devi portare su tale
griglie e poi lanci:<br>
<br>
</div>
update tabella set geometry =
ST_SnapToGrid(.....)<br>
<br>
dove li' dentro ci scrivi punto di partenza e
delta.<br>
<br>
</div>
Dovrebbe funzionare.<br>
<br>
</div>
Io ho usato una strategia simile per troncare
(brutta parola, ma è per tagliare corto) i dati del
nostro DBT ristrutturato su due cifre decimali.<br>
<br>
</div>
A.<br>
<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">Il giorno 16 gennaio 2014
08:52, Giuseppe Patti <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:gpatt@tiscali.it" target="_blank">gpatt@tiscali.it</a>></span>
ha scritto:
<div>
<div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">
<div>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.<br>
<br>
</div>
Come risolveremmo il problema con strumenti
GFoss?<br>
<div>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote"><br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex"> <br>
---------- Messaggio inoltrato
----------<br>
From: "G. Allegri" <<a
moz-do-not-send="true"
href="mailto:giohappy@gmail.com"
target="_blank">giohappy@gmail.com</a>><br>
To: Andrea Peri <<a
moz-do-not-send="true"
href="mailto:aperi2007@gmail.com"
target="_blank">aperi2007@gmail.com</a>><br>
Cc: gfoss <<a
moz-do-not-send="true"
href="mailto:gfoss@lists.gfoss.it"
target="_blank">gfoss@lists.gfoss.it</a>><br>
Date: Wed, 15 Jan 2014 20:06:25
+0100<br>
Subject: Re: [Gfoss] Risoluzione
spaziale dataset
<div>
<div><br>
<p dir="ltr"> 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). </p>
<p dir="ltr">Mi sembra
comunque che le questioni
sono due: </p>
<p dir="ltr">1) come viene
rappresentata una coordinata
nel formato dati scelto</p>
<p dir="ltr">2) come viene
gestita dal software </p>
<p dir="ltr">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. </p>
<p dir="ltr">giovanni</p>
<div class="gmail_quote">Il
15/gen/2014 19:34
"aperi2007" <<a
moz-do-not-send="true"
href="mailto:aperi2007@gmail.com"
target="_blank">aperi2007@gmail.com</a>>
ha scritto:<br
type="attribution">
<blockquote
class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div text="#000000"
bgcolor="#FFFFFF">
<div>Diciamo che tra
parecch softwares si
spostano in maniera
trasparente.<br>
<br>
Un discorso a parte è
il noto software
commerciale , il quale<br>
<br>
UNICO AL MONDO adotta
una riclassificazione
in "quanti" della
coordinata.<br>
<br>
Poiche' lui adotta un
meccanismo che non
trova riscontro in
nessun altro software.<br>
Difficile che con
altri software si
riesca a riprodurre la
sua coordinata.<br>
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.<br>
Dipende da quali altri
dataset sono caricati
nel medesimo DB di
partenza o di
destinazione.<br>
<br>
A.<br>
<br>
<br>
On 15/01/2014 18:29,
Giuseppe Patti wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">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:<br>
<br>
<a
moz-do-not-send="true"
href="http://gis.stackexchange.com/questions/68636/spatial-precision-for-editing-in-multiple-gis-clients"
target="_blank">http://gis.stackexchange.com/questions/68636/spatial-precision-for-editing-in-multiple-gis-clients</a><br>
<br>
<a
moz-do-not-send="true"
href="http://gis.stackexchange.com/questions/76939/qgis-polygon-precision"
target="_blank">http://gis.stackexchange.com/questions/76939/qgis-polygon-precision</a><br>
<div
class="gmail_extra"><br>
<br>
<div
class="gmail_quote">Il
giorno 15
gennaio 2014
18:01, Andrea
Peri <span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:aperi2007@gmail.com" target="_blank">aperi2007@gmail.com</a>></span>
ha scritto:<br>
<blockquote
class="gmail_quote"
style="margin:0
0 0
.8ex;border-left:1px
#ccc
solid;padding-left:1ex">
<div dir="ltr">
<div>Il noto
software
commerciale
permette di
impostare la
XY resolution
, ma
all'aumentare
della
resolution
diminuisce la
BBOX ammessa.<br>
</div>
E viceversa.<br>
<br>
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.<br>
<br>
<br>
</div>
<div
class="gmail_extra"><br>
<br>
<div
class="gmail_quote">Il
giorno 15
gennaio 2014
17:44,
Giuseppe Patti
<span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:gpatt@tiscali.it" target="_blank">gpatt@tiscali.it</a>></span>
ha scritto:<br>
<blockquote
class="gmail_quote"
style="margin:0
0 0
.8ex;border-left:1px
#ccc
solid;padding-left:1ex">
<div>
<div dir="ltr">
<div>
<div>Ciao.
Vorrei
approfondire
con voi la
questione
della
risoluzione
spaziale di
dati
vettoriali
nella quale
sono
incappato.<br>
</div>
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.<br>
<br>
</div>
Saluti<br>
</div>
<br>
</div>
_______________________________________________<br>
<a
moz-do-not-send="true"
href="mailto:Gfoss@lists.gfoss.it" target="_blank">Gfoss@lists.gfoss.it</a><br>
<a
moz-do-not-send="true"
href="http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss"
target="_blank">http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss</a><br>
Questa e' una
lista di
discussione
pubblica
aperta a
tutti.<br>
I messaggi di
questa lista
non hanno
relazione
diretta con le
posizioni
dell'Associazione
GFOSS.it.<br>
666 iscritti
al 22.7.2013<span><font
color="#888888"><br>
</font></span></blockquote>
</div>
<span><font
color="#888888"><br>
<br
clear="all">
<br>
-- <br>
-----------------<br>
Andrea Peri<br>
. . . . . . .
. . <br>
qwerty àèìòù<br>
-----------------<br>
</font></span></div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
<a moz-do-not-send="true" href="mailto:Gfoss@lists.gfoss.it" target="_blank">Gfoss@lists.gfoss.it</a>
<a moz-do-not-send="true" href="http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss" target="_blank">http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss</a>
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</pre>
</blockquote>
<br>
</div>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
<br>
_______________________________________________<br>
<a moz-do-not-send="true"
href="mailto:Gfoss@lists.gfoss.it"
target="_blank">Gfoss@lists.gfoss.it</a><br>
<a moz-do-not-send="true"
href="http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss"
target="_blank">http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss</a><br>
Questa e' una lista di discussione pubblica
aperta a tutti.<br>
I messaggi di questa lista non hanno relazione
diretta con le posizioni dell'Associazione
GFOSS.it.<br>
666 iscritti al 22.7.2013<br>
</blockquote>
</div>
</div>
</div>
<div>
<div class="h5"><br>
<br clear="all">
<br>
-- <br>
-----------------<br>
Andrea Peri<br>
. . . . . . . . . <br>
qwerty àèìòù<br>
-----------------<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
-----------------<br>
Andrea Peri<br>
. . . . . . . . . <br>
qwerty àèìòù<br>
-----------------<br>
</div>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>