<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">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>
</body>
</html>