[Gfoss] Risoluzione spaziale dataset
Giuseppe Patti
gpatt a tiscali.it
Gio 16 Gen 2014 10:18:48 CET
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/20140116/4ed59686/attachment-0001.html>
Maggiori informazioni sulla lista
Gfoss