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 <aperi2...@gmail.com
<mailto:aperi2...@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 <gp...@tiscali.it
<mailto:gp...@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" <gioha...@gmail.com
<mailto:gioha...@gmail.com>>
To: Andrea Peri <aperi2...@gmail.com
<mailto:aperi2...@gmail.com>>
Cc: gfoss <gfoss@lists.gfoss.it <mailto:gfoss@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" <aperi2...@gmail.com
<mailto:aperi2...@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
<aperi2...@gmail.com <mailto:aperi2...@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
<gp...@tiscali.it <mailto:gp...@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@lists.gfoss.it
<mailto:Gfoss@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@lists.gfoss.it <mailto:Gfoss@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@lists.gfoss.it <mailto:Gfoss@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 àèìòù
-----------------
_______________________________________________
Gfoss@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
