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 àèìòù
-----------------
